La HotSpot JVM garantit la cohérence de Object.hashCode() lors du déplacement d'objets en calculant la valeur une fois – généralement à partir de l'adresse mémoire initiale – et en la mettant en cache dans le mot de marque de l'en-tête de l'objet avant qu'un cycle de garbage collection ne puisse déplacer l'objet. Ce mot de marque contient un champ de code hash dédié ainsi qu'un drapeau indiquant que le hash a été matérialisé, garantissant que les invocations suivantes récupèrent la valeur mise en cache au lieu de la recalculer. Par conséquent, même lorsque des collecteurs comme G1 ou ZGC évacuent l'objet vers une nouvelle adresse, le hash d'identité reste stable car il est détaché du pointeur physique et stocké dans les métadonnées d'en-tête immuables.
Une application web distribuée a utilisé IdentityHashMap pour suivre les objets Session actifs à travers plusieurs nœuds d'application, s'appuyant sur System.identityHashCode() pour le routage d'affinité de cache lors des opérations de répartition de charge. Lors des pics de trafic, le collecteur à faible latence ZGC a effectué de fréquents déplacements concurrents d'objets de la jeune génération pour maintenir des cibles de temps d'arrêt serrées. Si le hash d'identité avait changé lors du mouvement, l'affinité de session aurait été rompue, provoquant un déversement des requêtes entre les nœuds et violant les garanties de cohérence.
Une des approches impliquait de générer des instances de UUID pour chaque Session lors de leur création et de maintenir un ConcurrentHashMap<UUID, Session> séparé. Avantages : complète indépendance du cycle de vie des objets JVM et des mécanismes de relocation. Inconvénients : ajoute seize octets de surcharge par objet session et introduit une pression d'allocation due à la génération de UUID, saturant potentiellement le taux d'allocation lors d'un trafic de pointe.
L'équipe a envisagé de fixer les objets de session en mémoire à l'aide de références critiques JNI pour empêcher le déplacement GC. Avantages : garantit des adresses mémoire stables et donc des hashes d'identité stables dérivés des adresses. Inconvénients : fixe des régions entières de tas dans ZGC, provoquant une fragmentation et contrecarrant les capacités de déplacement concurrent du collecteur, ce qui entraîne des temps d'arrêt inacceptables.
La solution choisie s'est appuyée sur la garantie de la spécification JVM selon laquelle les codes de hash d'identité restent constants, combinée à l'implémentation de mise en cache dans le mot de marque de HotSpot. Avantages : aucune surcharge mémoire supplémentaire, aucun coût d'allocation, et pleine compatibilité avec des collecteurs agressifs comme ZGC. Inconvénients : nécessite de faire confiance aux détails d'implémentation de la JVM, bien que codifiés dans la spécification.
L'application a maintenu une parfaite affinité de session à travers des millions de cycles ZGC sans verrouillage ni identifiants auxiliaires, atteignant des temps d'arrêt en dessous de la milliseconde tout en préservant l'intégrité de IdentityHashMap.
Est-ce que System.identityHashCode() renvoie toujours l'emplacement mémoire actuel de l'objet sous forme d'entier ?
Non. Bien que le calcul initial puisse utiliser l'adresse mémoire comme source d'entropie, le résultat est immédiatement stocké dans l'en-tête de l'objet et ne change jamais par la suite. Cela signifie que l'entier renvoyé ne reflète pas l'emplacement actuel de l'objet après le mouvement GC, et les développeurs ne devraient pas le traiter comme un pointeur ou une sonde d'adresse mémoire.
Le code de hash d'identité peut-il être négatif, et comment les collections gèrent-elles cela ?
Oui, toute valeur entière de trente-deux bits est valide, y compris les nombres négatifs. IdentityHashMap gère les hashs négatifs par des opérations de masquage comme (h ^ (h >>> 16)) & (length-1), évitant Math.abs() qui échoue sur Integer.MIN_VALUE en raison du débordement du complément à deux.
Le code de hash d'identité est-il garanti comme étant unique parmi tous les objets ?
Non. L'espace entier de trente-deux bits est plus petit que l'espace potentiel d'adresses dans le tas, donc des collisions sont possibles. HotSpot utilise un schéma de xor-shift de Marsaglia ou un hachage basé sur les adresses qui distribue bien les valeurs, mais l'unicité n'est pas garantie, ce qui fait que IdentityHashMap s'appuie sur l'égalité des références pour la désambiguïsation, et pas seulement sur les codes de hash.