Storia della domanda
Prima di Java 8 aggiornamento 20, gli sviluppatori che cercavano di ridurre il consumo dell'heap a causa di istanze duplicate di String dovevano fare affidamento esclusivamente su String.intern(). Questo metodo collocava le stringhe nella generazione permanente (in seguito Metaspace), richiedendo chiamate esplicite all'API e potenzialmente causando pressione sulla memoria nel pool di intern. Con JEP 192, il garbage collector G1 ha introdotto la deduplicazione automatica delle String, un'ottimizzazione trasparente che mira al problema onnipresente degli array di caratteri ridondanti nelle applicazioni aziendali.
Il problema
Nelle applicazioni Java intensive in termini di dati, come quelle che analizzano XML, JSON o set di risultati di database, gli oggetti String spesso costituiscono il 25-50% dell'heap attivo. Una porzione significativa di queste stringhe è identica carattere per carattere, ma risiede in distinti array di char[] (o byte[] dopo Java 9 String Compatte) di supporto. Senza un intervento, questi array duplicati sprecano memoria e aumentano la frequenza della GC. La sfida era eliminare questa ridondanza senza introdurre ulteriori pause stop-the-world o richiedere modifiche al codice.
La soluzione
G1 esegue la deduplicazione in modo opportunistico durante la sua esistente pausa di evacuazione (quando i thread sono già fermi). Quando abilitato tramite -XX:+UseStringDeduplication, il collector scansiona gli oggetti nella giovane generazione. Per ogni String che ha sopravvissuto ad almeno -XX:StringDeduplicationAgeThreshold raccolte di rifiuti (predefinite 3), G1 calcola un hash del suo array di supporto. Consulta quindi una tabella di deduplicazione. Se esiste un array identico, G1 utilizza un'operazione di compare-and-swap (CAS) per reindirizzare il campo value della String all'array esistente, consentendo il recupero del duplicato nel ciclo successivo. Questo sfrutta la pausa esistente, aggiungendo solo un marginale overhead CPU.
// Nessuna modifica al codice richiesta; le flag JVM abilitano l'ottimizzazione: // -XX:+UseG1GC -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=3 public class DeduplicationExample { public static void main(String[] args) { // Queste due stringhe condividono lo stesso array di supporto dopo la deduplicazione String a = new String("FinancialInstrument".toCharArray()); String b = new String("FinancialInstrument".toCharArray()); // Dopo sufficienti cicli GC e pause di evacuazione, // a.value == b.value (uguaglianza di riferimento array interno) } }
Una piattaforma di trading ad alta frequenza che elabora messaggi del protocollo FIX ha sperimentato tempi di pausa G1 superiori a 200 ms. Il profiling ha rivelato che il 30% dell'heap di 64 GB era consumato da oggetti String che rappresentavano tag standard (ad es., "55", "150", "EUR/USD") e valori simili a enum analizzati dai flussi di byte in arrivo. Ogni istanza di messaggio creava nuove istanze di String tramite new String(byte[], Charset), con conseguente milioni di array di supporto duplicati al minuto.
Sono state valutate diverse soluzioni. String.intern() è stata scartata perché richiedeva cambiamenti invasivi in oltre 50 tipi di messaggi e rischiava di saturare il Metaspace con riferimenti permanenti che non sarebbero mai stati raccolti. È stato prototipato un cache basato su WeakHashMap, ma ha introdotto complessi overhed di concorrenza e logica di pulizia delle voci obsolete che, paradossalmente, ha aumentato la pressione della GC a causa dell'ulteriore elaborazione delle WeakReference.
Il team ha infine abilitato la Deduplicazione delle Stringhe G1 con la soglia di età predefinita di 3. Questo approccio trasparente non ha richiesto alcuna modifica al codice e ha operato durante le pause di evacuazione esistenti, evitando nuove fasi di stop-the-world.
Il risultato è stata una riduzione del 22% dell'uso dell'heap e una diminuzione dei tempi di pausa del 95° percentile a meno di 50 ms. L'overhead CPU misurato è stato di circa l'1.5% durante le ore di punta del mercato, un compromesso accettabile per i risparmi di memoria e il miglioramento della latenza.
Come interagisce la deduplicazione delle Stringhe con Strings Compatte di Java 9, che memorizzano testo Latin-1 come byte[] invece di char[]?
Risposta. La Deduplicazione delle Stringhe è stata aggiornata per operare su array byte[] quando Compact Strings è abilitato (il predefinito da Java 9). La logica di deduplicazione controlla il campo coder (LATIN1 o UTF16) e calcola l'hash dell'array corrispondente byte[] o char[] di supporto di conseguenza. La tabella di deduplicazione memorizza voci chiave sia dall'hash sia dal tipo di array, assicurando che le stringhe Latin-1 vengano deduplicate rispetto ad altre stringhe Latin-1 e le stringhe UTF-16 a larghezza completa rispetto ai loro simili. I candidati spesso credono erroneamente che la funzione sia stata deprecata con Compact Strings, ma rimane completamente compatibile.
Perché la JVM impone una soglia di età (predefinita 3 GC) prima che una String diventi idonea per la deduplicazione?
Risposta. La soglia di età impedisce al sistema di sprecare cicli CPU deduplicando stringhe effimere a breve termine che probabilmente moriranno nella successiva raccolta giovane. Richiedendo che la String sopravviva a diversi cicli di evacuazione G1 (promovendola dalle regioni Eden a Survivor e infine verso Tenured), l'euristica garantisce che solo le stringhe "mature"—quelle con un'alta probabilità di sopravvivenza a lungo termine—siano elaborate. Questo ammortizza il costo del calcolo dell'hash e della ricerca della tabella sulla vita attesa dell'oggetto.
La deduplicazione delle Stringhe influisce sull'immutabilità o sulla stabilità di hashCode dell'istanza di String?
Risposta. No. Il processo di deduplicazione è strettamente un dettaglio di implementazione della mutazione di riferimento del campo value. Poiché l'array di sostituzione contiene byte o caratteri identici, lo stato logico della String e l'hashCode rimangono invariati. L'hashCode è memorizzato in un campo transitorio all'interno dell'oggetto String stesso, e poiché il contenuto è identico, il valore memorizzato rimane valido. Il contratto equals è preservato perché l'uguaglianza del contenuto implica che l'uguaglianza di riferimento dell'archivio di supporto è irrilevante per il contratto API. L'operazione è atomica dalla prospettiva dell'applicazione, mantenendo la garanzia di immutabilità della String.