StringBuilder vs StringBuffer: 10 diferencias principales en Java

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

StringBuilder vs StringBuffer: ¿cuál elegir y por qué es importante?

\n\n

Si alguna vez has escrito código en Java que trabaja activamente con cadenas (por ejemplo, construyendo una consulta SQL, generando JSON o simplemente concatenando decenas de fragmentos de texto), seguramente te has enfrentado al dilema: ¿StringBuilder o StringBuffer? En Stack Overflow, esta pregunta ha acumulado cientos de miles de visitas, y no es para menos. A simple vista, las clases son como gemelos: ambas extienden AbstractStringBuilder, ambas usan un arreglo mutable de caracteres, ambas tienen métodos append(), insert(), delete(). Pero el diablo, como siempre, está en los detalles.

\n\n

En este artículo no solo enumeraremos las diferencias. Las analizaremos con ejemplos reales, exploraremos el interior de la JVM y responderemos las preguntas que seguramente te harán en una entrevista. ¡Allá vamos!

\n\n

1. La diferencia principal: sincronización

\n\n

Este es el punto más importante, la razón de toda la discusión. StringBuffer es seguro para hilos (thread-safe). Casi todos sus métodos públicos están sincronizados con la palabra clave synchronized. StringBuilder no está sincronizado. Eso es todo.

\n\n

Veamos el código (versión simplificada del JDK real):

\n\n

// StringBuffer (Java 17)\npublic synchronized StringBuffer append(String str) {\n    toStringCache = null;\n    super.append(str);\n    return this;\n}\n\n// StringBuilder\npublic StringBuilder append(String str) {\n    super.append(str);\n    return this;\n}\n

\n\n

Una sola línea synchronized marca toda la diferencia. Pero esa línea lo cambia todo: rendimiento, ámbito de aplicación, incluso la arquitectura de la aplicación.

\n\n

¿Cuándo usar StringBuffer?

Estás escribiendo una aplicación multihilo.
La misma instancia de StringBuffer se usa desde varios hilos sin sincronización externa.
Ejemplo: un logger que recopila mensajes de diferentes hilos en un solo búfer.

\n\n

¿Cuándo usar StringBuilder?

Código de un solo hilo (90% de los casos).
Variables locales dentro de un método.
Bucles con concatenación de cadenas (el compilador sugerirá StringBuilder por sí mismo).

\n\n

2. Rendimiento: ¿quién es más rápido?

\n\n

Aquí todo es predecible: StringBuilder es más rápido que StringBuffer. ¿Cuánto? Depende de la carga, pero en promedio es de 2 a 5 veces más rápido. Vamos a comprobarlo con un benchmark simple.

\n\n

public class PerformanceTest {\n    private static final int ITERATIONS = 10_000_000;\n\n    public static void main(String[] args) {\n        // StringBuilder\n        long start = System.nanoTime();\n        StringBuilder sb = new StringBuilder();\n        for (int i = 0; i < ITERATIONS; i++) {\n            sb.append("a");\n        }\n        long sbTime = System.nanoTime() - start;\n\n        // StringBuffer\n        start = System.nanoTime();\n        StringBuffer sbf = new StringBuffer();\n        for (int i = 0; i < ITERATIONS; i++) {\n            sbf.append("a");\n        }\n        long sbfTime = System.nanoTime() - start;\n\n        System.out.println("StringBuilder: " + sbTime / 1_000_000 + " ms");\n        System.out.println("StringBuffer:  " + sbfTime / 1_000_000 + " ms");\n        System.out.println("Buffer es " + (sbfTime / (double) sbTime) + " veces más lento");\n    }\n}\n

\n\n

En mi portátil (Intel i7, 16GB RAM, Java 17) el resultado es consistente: StringBuilder ~180 ms, StringBuffer ~620 ms. La diferencia es de casi 3.5 veces. Y si añadimos trabajo real (análisis, formato), la brecha puede aumentar. ¿Por qué? Porque cada llamada a synchronized implica verificar el monitor, adquirir el bloqueo y liberarlo. En código de un solo hilo, esto es una pérdida de tiempo pura.

\n\n

\n Importante: Si tu método garantiza