Il HotSpot JVM garantisce la coerenza di Object.hashCode() durante il riallocamento degli oggetti calcolando il valore una sola volta—tipicamente dall'indirizzo di memoria iniziale—e memorizzandolo nel campo del segnale dell'intestazione dell'oggetto prima che qualsiasi ciclo di garbage collection possa muovere l'oggetto. Questo campo del segnale contiene un campo hash dedicato accanto a un flag di bit che indica che l'hash è stato materializzato, assicurando che le invocazioni successive recuperino il valore memorizzato piuttosto che ricalcolarlo. Di conseguenza, anche quando i collector come G1 o ZGC evacuano l'oggetto a un nuovo indirizzo, l'hash di identità rimane stabile perché è scollegato dal puntatore fisico e memorizzato nei metadati dell'intestazione immutabile.
Un'applicazione web distribuita ha utilizzato IdentityHashMap per tenere traccia degli oggetti Session attivi su più nodi dell'applicazione, facendo affidamento su System.identityHashCode() per il routing dell'affinità della cache durante le operazioni di bilanciamento del carico. Durante il traffico massimo, il collector a bassa latenza ZGC ha effettuato frequenti riallocazioni concorrenti di oggetti della giovane generazione per mantenere obiettivi di pause ridotti. Se l'hash di identità fosse cambiato al movimento, l'affinità della sessione si sarebbe interrotta, causando richieste a spillare tra i nodi e violando le garanzie di coerenza.
Un approccio prevedeva la generazione di istanze UUID per ogni Session al momento della creazione e il mantenimento di una separata ConcurrentHashMap<UUID, Session>. Pro: Completa indipendenza dal ciclo di vita dell'oggetto JVM e meccaniche di riallocazione. Contro: Aggiunge sedici byte di overhead per ogni oggetto sessione e introduce pressione allocativa dalla generazione di UUID, saturando potenzialmente il tasso di allocazione durante il traffico di picco.
Il team ha considerato di fissare gli oggetti sessione in memoria utilizzando riferimenti critici JNI per prevenire la riallocazione da parte del GC. Pro: Garantisce indirizzi di memoria stabili e quindi hash di identità stabili derivati dagli indirizzi. Contro: Fissa intere regioni della heap in ZGC, causando frammentazione e sconfiggendo le capacità di riallocazione concorrente del collector, portando a tempi di pausa inaccettabili.
La soluzione scelta ha sfruttato la garanzia specificata nel JVM che gli hash di identità rimangano costanti, combinata con l'implementazione di caching del campo del segnale di HotSpot. Pro: Zero overhead di memoria aggiuntiva, nessun costo di allocazione e piena compatibilità con collector aggressivi come ZGC. Contro: Richiede fiducia nei dettagli dell'implementazione del JVM, sebbene codificati nella specifica.
L'applicazione ha mantenuto un'affinità di sessione perfetta attraverso milioni di cicli di ZGC senza fissazioni o identificatori ausiliari, raggiungendo tempi di pausa sotto il millisecondo pur preservando l'integrità di IdentityHashMap.
Restituisce sempre System.identityHashCode() l'indirizzo di memoria attuale dell'oggetto come intero?
No. Anche se il calcolo iniziale può utilizzare l'indirizzo di memoria come entropia, il risultato è immediatamente memorizzato nell'intestazione dell'oggetto e non cambia più. Ciò significa che l'intero restituito non riflette la posizione attuale dell'oggetto dopo il movimento del GC, e gli sviluppatori non dovrebbero trattarlo come un puntatore o una sonda dell'indirizzo di memoria.
L'hash di identità può essere negativo e come gestiscono questa situazione le collezioni?
Sì, qualsiasi valore intero a trenta due bit è valido, inclusi i numeri negativi. IdentityHashMap gestisce gli hash negativi attraverso operazioni di mascheramento come (h ^ (h >>> 16)) & (length-1), evitando Math.abs() che fallisce su Integer.MIN_VALUE a causa del sovraccarico del complemento a due.
È garantito che l'hash di identità sia unico tra tutti gli oggetti?
No. Lo spazio intero a trenta due bit è più piccolo dello spazio potenziale degli indirizzi della heap, quindi le collisioni sono possibili. HotSpot utilizza uno schema xor-shift di Marsaglia o hashing basato su indirizzo che distribuisce bene i valori, ma l'unicità non è garantita, rendendo IdentityHashMap dipendente dall'uguaglianza di riferimento per la disambiguazione, non solo dagli hash.