Stringbuffer
Hola:
Esta clase almacena y concatena string con el método append ,alguien sabe como vaciar un stringbuffer sin hacerlo null a??
- Inicie sesión o regístrese para enviar comentarios
Hola:
Esta clase almacena y concatena string con el método append ,alguien sabe como vaciar un stringbuffer sin hacerlo null a??
me autorepondo ya salio
me autorepondo ya salio
Y cual fue la respuesta?
Y cual fue la respuesta?
Supongo que encontraste el método "delete".
Por cierto, es mejor utilizar StringBuilder por que no es sincronizado y consume menos recursos.
La mayoría de las veces estos se usan dentro de un método donde solo ese ejecuta un hilo a la vez y es un desperdicio de recursos revisar si el hilo actual tiene el lock del objeto por cada invocación.
O sease, utiliza StringBuilder en vez de StringBuffer
opciones
Puedes hacer una de las siguientes:
Y como dice Oscar, si vas a usar un StringBuffer dentro de un solo hilo, mejor usa StringBuilder, que tiene mucho mejor desempeño (pero no es thread-safe).
Que pasa si?
Que pasa si yo por ejemplo para vaciar un StringBuffer (en un ciclo "for" por ejemplo) hago algo como esto;
Digo a lo mejor el ejemplo es muy vago, pero a lo que voy es que si las referencias a el montoFormato que se crea se pierden y luego en un momento pasa el recolector de basura no me llene la memoria, o es mejor darle el metodo montoFormato.delete(0, montoFormato.length()) ??
saludos y gracias
GC
Estás creando un nuevo StringBuilder en cada iteración, que luego se desecha, y en algún momento se lo lleva el GC, pero no hay manera de saber cuándo será eso. Incluso si llamas System.gc() eso no garantiza que se haga la recolección en ese momento. De modo que sí, es más óptimo hacerle delete a la misma instancia.
Y por cierto, eso de
no sólo es innecesario sino que degrada el desempeño y prácticamente anula las ventajas de usar un StringBuilder. La clase ya tiene un método que acepta un
de modo que no es necesario concatenarlo, y además se supone que estás usando un StringBuilder precisamente para evitar concatenaciones con +, porque eso genere que se hagan varios strings, etc.
A partir de Java 5 para lo que quieres hacer tienes los métodos String.format y PrintStream.printf, que operan de manera muy similar:
Ok
Jajaja ok ok entendido lo de que es mejor borrar el objeto, en cuanto a lo de los append, era solo ejemplo, no se me ocurrio nada en el momento de escribir el post, jajaja por eso no me imagine que tenia un append(int), lo estaba escribiendo a mano y pues dije vamos a poner dinero jajaja pero de todos modos gracias por tu explicacion, si me imaginaba que se perdia la referencia al objeto y por eso era candidato para el GC, pero no sabia si era mas eficiente eso o darle el delete, puesto que me imaginaba que al darle el delete, tambien esas referencias se pierden pero bueno de todos modos muchas gracias.
Saludos
casos
En general si vas a concatenar varios datos pero siempre igual (siempre van todos en el mismo orden) creo que es mejor ya usar String.format para obtener una cadena y ya.
Pero si estás armando una cadena que tal vez tenga o no tenga algunos datos (por ejemplo si estás armando la descripción en español de un número, conversión "15.25" a "quince pesos con veinticinco centavos") y vas a agregar distintas cosas (o no agregarlas) segun varias condiciones, lo mejor es usar un StringBuilder y al final convertirlo en cadena y devolverlo.
1.-Escribir ... stringBuilde
1.-Escribir
Es idéntico a escribir:
Así que por favor, no.
2.-Sobre tu ejemplo, sí, las referencias se crean y se pierden ( nota lo que dice Enrique, el gc determina cuando) , pero en ese caso ( casi ) sería mejor escribir:
Que hace lo mismo que:
Pero evita aquello de ""+i.
3.-Definitivamente es mucho mejor no crear el builder cada vez y simplemente limpiarlo
Que si bien crea la misma cantidad de objetos strings, al menos crea 9 veces menos instancias de StringBuilder.
4.-Algo que durante muchísimos años fue tachado de tabú y prohibido en Java, desde la v1.5 ya no es tan malo y es la concatenación de Strings.
Lo siguiente
Ya no es tan malo como antes( < 1.5 ) . El compilador de detectar esto y crea:
En automático.
6.-Para incluir una variable, como ya vimos antes, el compilador utiliza un StringBuilder:
Es igual a:
Con lo cual ya no es taaaaaan condenable como antes.
Saludos.