De HotSpot JVM garandeert de consistentie van Object.hashCode() over objectverplaatsing door de waarde eenmaal te berekenen - meestal vanaf het initiële geheugensadres - en deze op te slaan in het markwoords van de objectheader voordat een garbage collection-cyclus het object kan verplaatsen. Dit markwoord bevat een speciaal veld voor de hashcode naast een bitflag dat aangeeft dat de hash is gecreëerd, wat ervoor zorgt dat volgende aanroepen de opgeslagen waarde ophalen in plaats van deze opnieuw te berekenen. Als gevolg daarvan blijft de identiteitshash stabiel, zelfs wanneer verzamelaars zoals G1 of ZGC het object naar een nieuw adres evacueren, omdat het is losgekoppeld van de fysieke pointer en is opgeslagen in de onveranderlijke headermetadata.
Een gedistribueerde webtoepassing gebruikt IdentityHashMap om actieve Session-objecten over meerdere applicatienodes bij te houden, waarbij gebruik wordt gemaakt van System.identityHashCode() voor cache-affiniteitroutering tijdens loadbalanceringsoperaties. Tijdens piekverkeer voerde de ZGC low-latency collector frequente gelijktijdige verplaatsingen van jonge generatieobjecten uit om strakke pauzetijd-doelstellingen te behouden. Als de identiteitshash was veranderd bij verplaatsing, zou de sessieaffiniteit breken, waardoor verzoeken door nodes heen zouden bloeden en consistentiegaranties zouden worden geschonden.
Een benadering bestond uit het genereren van UUID-instanties voor elke Session bij creatie en het bijhouden van een aparte ConcurrentHashMap<UUID, Session>. Voordelen: Volledige onafhankelijkheid van de levenscyclus van JVM-objecten en verplaatsingsmechanica. Nadelen: Voegt zestien bytes overhead toe per sessieobject en introduceert allocatiedruk door UUID-generatie, wat mogelijk de allocatiesnelheid tijdens piekverkeer verzadigt.
Het team overwoog om sessieobjecten in het geheugen vast te pinnen met behulp van JNI-kritieke referenties om GC-verplaatsing te voorkomen. Voordelen: Garandeert stabiele geheugenslocaties en dus stabiele identiteitshashes afgeleid van adressen. Nadelen: Pind de volledige heapregionen in ZGC, wat fragmentatie veroorzaakt en de gelijktijdige verplaatsingscapaciteiten van de collector tenietdoet, wat leidt tot onaanvaardbare pauzetijden.
De gekozen oplossing maakte gebruik van de garantie in de JVM-specificatie dat identiteitshashcodes constant blijven, gecombineerd met de cachingimplementatie van het markwoord van HotSpot. Voordelen: Geen extra geheugenovertolligheid, geen allocatiekosten, en volledige compatibiliteit met agressieve verzamelaars zoals ZGC. Nadelen: Vereist vertrouwen in de implementatiedetails van de JVM, hoewel gecodificeerd in de specificatie.
De toepassing handhaafde perfecte sessieaffiniteit gedurende miljoenen ZGC-cycli zonder vastpinnen of aanvullende identificatoren, en bereikte pauzetijden van minder dan een milliseconde terwijl de integriteit van IdentityHashMap werd behouden.
Geeft System.identityHashCode() altijd het huidige geheugensadres van het object terug als een integer?
Nee. Hoewel de initiële berekening mogelijk het geheugensadres als entropie gebruikt, wordt het resultaat onmiddellijk opgeslagen in de objectheader en verandert het daarna nooit meer. Dit betekent dat de geretourneerde integer de huidige locatie van het object na GC-verplaatsing niet weerspiegelt, en ontwikkelaars zouden het niet als een pointer of geheugenadresprobe moeten beschouwen.
Kan de identiteitshashcode negatief zijn, en hoe gaan verzamelingen hiermee om?
Ja, elke waarde van dertig twee-bits integer is geldig, inclusief negatieve getallen. IdentityHashMap behandelt negatieve hashes via maskerbewerkingen zoals (h ^ (h >>> 16)) & (length-1), wat Math.abs() vermijdt dat faalt bij Integer.MIN_VALUE door overflow van de twee's complement.
Is de identiteitshashcode gegarandeerd uniek tussen alle objecten?
Nee. De ruimte van dertig twee-bits integers is kleiner dan de potentiële heap-adresruimte, dus botsingen zijn mogelijk. HotSpot gebruikt een Marsaglia's xor-shift-schema of adresgebaseerde hashing die waarden goed verdeelt, maar uniciteit is niet gegarandeerd, waardoor IdentityHashMap vertrouwt op referentiegelijkheid voor verduidelijking, niet slechts op hashcodes.