¿A través de qué optimización específica **G1** consolida transparentemente las matrices de respaldo **String** duplicadas durante los ciclos rutinarios de recolección de basura sin extender las duraciones de pausa total?

Respuesta a la pregunta.

Historia de la pregunta

Antes de Java 8 actualización 20, los desarrolladores que buscaban reducir el consumo de heap por instancias duplicadas de String tenían que depender exclusivamente de String.intern(). Este método colocaba cadenas en la generación permanente (más tarde Metaspace), requiriendo llamadas explícitas a la API y potencialmente causando presión de memoria en el pool de intern. Con JEP 192, el recolector de basura G1 introdujo la Deduplicación de Strings automática, una optimización transparente que aborda el problema omnipresente de las matrices de caracteres redundantes en aplicaciones empresariales.

El problema

En aplicaciones Java intensivas en datos, como aquellas que analizan XML, JSON o conjuntos de resultados de bases de datos, los objetos String suelen representar el 25-50% del heap activo. Una porción significativa de estos strings son idénticos carácter por carácter, pero residen en distintas matrices char[] (o byte[] tras Java 9 Compact Strings) de respaldo. Sin intervención, estas matrices duplicadas desperdician memoria y aumentan la frecuencia de la recolección de basura. El reto era eliminar esta redundancia sin introducir pausas adicionales de detención total o requerir modificaciones en el código.

La solución

G1 lleva a cabo la deduplicación de manera oportunista durante su pausa de evacuación existente (cuando los hilos ya están detenidos). Cuando se habilita mediante -XX:+UseStringDeduplication, el recolector escanea objetos en la joven generación. Para cada String que ha sobrevivido al menos -XX:StringDeduplicationAgeThreshold ciclos de recolección de basura (por defecto 3), G1 calcula un hash de su matriz de respaldo. Luego consulta una tabla de deduplicación. Si existe una matriz idéntica, G1 utiliza una operación de compare-and-swap (CAS) para redirigir el campo value del String a la matriz existente, permitiendo que la duplicada sea recuperada en el siguiente ciclo. Esto aprovecha la pausa existente, añadiendo solo un marginal costo de CPU.

// No se requieren cambios de código; las flags de la JVM habilitan la optimización:
// -XX:+UseG1GC -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=3
public class DeduplicationExample {
    public static void main(String[] args) {
        // Estas dos cadenas comparten la misma matriz de respaldo después de la deduplicación
        String a = new String("FinancialInstrument".toCharArray());
        String b = new String("FinancialInstrument".toCharArray());
        
        // Después de suficientes ciclos de GC y pausas de evacuación,
        // a.value == b.value (igualdad de referencia de matriz interna)
    }
}

Situación de la vida real

Una plataforma de trading de alta frecuencia que procesa mensajes del protocolo FIX experimentó tiempos de pausa severos en G1 que superaban los 200 ms. El perfilado reveló que el 30% del heap de 64GB estaba consumido por objetos String que representaban etiquetas estándar (por ejemplo, "55", "150", "EUR/USD") y valores tipo enum analizados de flujos de bytes entrantes. Cada instancia de mensaje creaba nuevas instancias de String a través de new String(byte[], Charset), resultando en millones de matrices de respaldo duplicadas por minuto.

Se evaluaron varias soluciones. String.intern() fue rechazado porque requería cambios invasivos en más de 50 tipos de mensajes y arriesgaba saturar el Metaspace con referencias permanentes que nunca serían recolectadas por basura. Se prototipó una caché basada en WeakHashMap, pero introdujo una sobrecarga de concurrencia compleja y lógica de limpieza de entradas obsoletas que, paradójicamente, aumentó la presión de GC debido al procesamiento adicional de WeakReference.

El equipo finalmente habilitó la Deduplicación de Strings de G1 con el umbral de edad por defecto de 3. Este enfoque transparente no requirió ningún cambio en el código y operó durante las pausas de evacuación existentes, evitando nuevas fases de detención total.

El resultado fue una reducción del 22% en el uso de heap y una disminución en los tiempos de pausa en el percentil 95 a menos de 50 ms. La sobrecarga de CPU medida fue de aproximadamente 1.5% durante las horas pico del mercado, un compromiso aceptable por los ahorros de memoria y la mejora en latencia.

Lo que los candidatos a menudo pasan por alto

¿Cómo interactúa la deduplicación de Strings con los Compact Strings de Java 9, que almacenan texto Latin-1 como byte[] en lugar de char[]?

Respuesta. La Deduplicación de Strings fue actualizada para operar sobre matrices byte[] cuando los Compact Strings están habilitados (lo predeterminado desde Java 9). La lógica de deduplicación inspecciona el campo coder (LATIN1 o UTF16) y hashea la correspondiente matriz de byte[] o char[] de respaldo en consecuencia. La tabla de deduplicación almacena entradas indexadas por tanto el hash como el tipo de matriz, asegurando que las cadenas Latin-1 se deduplican contra otras cadenas Latin-1, y las cadenas UTF-16 de ancho completo contra sus pares. Los candidatos a menudo creen erróneamente que la función fue deprecada con los Compact Strings, pero sigue siendo completamente compatible.

¿Por qué la JVM impone un umbral de edad (por defecto 3 GCs) antes de que un String sea elegible para deduplicación?

Respuesta. El umbral de edad evita que el sistema desperdicie ciclos de CPU deduplicando cadenas efímeras de corta duración que probablemente desaparecerán en la próxima recolección joven. Al requerir que el String sobreviva a varios ciclos de evacuación de G1 (promoviéndolo de regiones Eden a Survivor y eventualmente hacia Tenured), la heurística garantiza que solo las cadenas "maduras" — aquellas con una alta probabilidad de supervivencia a largo plazo — sean procesadas. Esto amortiza el costo del cálculo de hash y búsqueda en la tabla sobre la vida útil esperada del objeto.

¿La deduplicación de Strings afecta la inmutabilidad o la estabilidad del hashCode de la instancia de String?

Respuesta. No. El proceso de deduplicación es estrictamente un detalle de implementación de la mutación de referencia del campo value. Dado que la matriz de reemplazo contiene bytes o caracteres idénticos, el estado lógico del String y el hashCode permanecen sin cambios. El hashCode se almacena en un campo transient dentro del objeto String mismo, y como el contenido es idéntico, el valor almacenado permanece válido. Se preserva el contrato de equals porque la igualdad de contenido implica que la igualdad de referencia del almacenamiento de respaldo es irrelevante para el contrato de la API. La operación es atómica desde la perspectiva de la aplicación, manteniendo la garantía de inmutabilidad del String.