java - textos - html etiqueta text

¿StringBuffer es obsoleto?

Question

En el libro "Java efectiva", Josh Bloch dice que

StringBuffer está en gran parte obsoleto y debe ser reemplazado por la implementación no sincronizada ''StringBuilder''

.

Pero en mi experiencia, todavía he visto un uso generalizado de la clase StringBuffer. ¿Por qué la clase StringBuffer ahora está obsoleta y por qué debería preferirse StringBuilder a StringBuffer, excepto por el aumento del rendimiento debido a la falta de sincronización?

Answer 1

¿Por qué la clase StringBuffer ahora es obsoleta?

Debido a que sus operaciones están sincronizadas, lo que agrega sobrecarga y rara vez es útil.

La razón por la que todavía ve que StringBuffer usa ampliamente es simplemente inercia: todavía hay innumerables tutoriales de ejemplos de código que nunca se actualizaron para usar StringBuilder , y la gente aún aprende prácticas obsoletas (no solo esta) de esas fuentes. E incluso las personas que saben mejor a menudo recurren a viejos hábitos.

Answer 2

Creo que obsoleto es una exageración.

StringBuffer está sincronizado. StringBuilder no lo es.

En muchos (tal vez la mayoría) de los casos, no le importará la seguridad de los hilos de algo que se usa para construir cadenas. Deberías usar StringBuilder en estos casos. Sin embargo, en algunos casos, es posible que desee asegurarse de que las acciones en el objeto sean seguras para subprocesos. StringBuffer sigue siendo útil en esos casos.

Answer 3

No solo no es necesaria la sincronización en la mayoría de los casos, sino que en realidad le da información errónea a los lectores de su código si, a pesar de eso, la usa: a saber, se podría hacer creer al lector que, en realidad, no es necesaria la sincronización.

El uso de un StringBuilder lugar anuncia el hecho de que no se espera un acceso entre subprocesos.

De hecho, el envío de datos a través de subprocesos casi siempre debe hacerse a través de canales de comunicación bien definidos, no simplemente accediendo a un búfer de cadena sincronizado. Así que, de una manera, recomendaría usar siempre una solución diferente, incluso cuando un StringBuffer parece apropiado a primera vista.

Answer 4

No todos leen tanto como tú :-)

Sólo estoy bromeando a medias. La gente copia código y patrones todo el tiempo. Muchas personas no se mantienen en contacto con los cambios de API.

¿Por qué es obsoleto StringBuffer? Porque en la gran mayoría de los casos, su comportamiento sincronizado no es necesario. No puedo pensar en un momento en que lo haya necesitado. A pesar de que la sincronización no es ahora el problema de rendimiento que alguna vez fue, tiene poco sentido pagar ese impuesto en escenarios donde no es necesario.

Answer 5

Es obsoleto, ya que el nuevo código en Java 1.5 generalmente debe usar StringBuilder . Es muy raro que realmente necesite crear cadenas de manera segura para subprocesos, ¿por qué pagar el costo de sincronización?

Sospecho que el código que ves usando StringBuffer cae principalmente en cubos de:

• Escrito antes de Java 1.5
• Escrito para mantener la compatibilidad con JDK anteriores.
• Escrito por personas que no saben sobre StringBuilder
• Autogenerado por herramientas que no conocen StringBuilder