El HotSpot JVM garantiza la consistencia de Object.hashCode() a través de la reubicación de objetos al calcular el valor una vez—típicamente desde la dirección de memoria inicial—y almacenándolo en la palabra de marca del encabezado del objeto antes de que cualquier ciclo de recolección de basura pueda mover el objeto. Esta palabra de marca contiene un campo de código hash dedicado junto con un indicador de bits que indica que el hash ha sido materializado, asegurando que las invocaciones posteriores recuperen el valor almacenado en caché en lugar de recalcularlo. Por lo tanto, incluso cuando recolectores como G1 o ZGC evacuan el objeto a una nueva dirección, el hash de identidad permanece estable porque está desprendido del puntero físico y se almacena en los metadatos inmutables del encabezado.
Una aplicación web distribuida utilizó IdentityHashMap para rastrear objetos Session activos a través de múltiples nodos de aplicación, confiando en System.identityHashCode() para el enrutamiento de afinidad de caché durante las operaciones de balanceo de carga. Durante el tráfico máximo, el recolector de baja latencia ZGC realizó frecuentes reubicaciones concurrentes de objetos de younger generations para mantener objetivos de tiempo de pausa ajustados. Si el hash de identidad hubiera cambiado al moverse, la afinidad de sesión se habría roto, causando que las solicitudes se filtraran entre nodos y violaran las garantías de consistencia.
Un enfoque involucró la generación de instancias de UUID para cada Session al crear y mantener un ConcurrentHashMap<UUID, Session> separado. Pros: Independencia total del ciclo de vida del objeto JVM y de la mecánica de reubicación. Contras: Añade dieciséis bytes de sobrecarga por objeto de sesión e introduce presión de asignación por la generación de UUID, lo que podría saturar la tasa de asignación durante el tráfico intenso.
El equipo consideró fijar los objetos de sesión en memoria utilizando referencias críticas de JNI para evitar la reubicación de GC. Pros: Garantiza direcciones de memoria estables y, por lo tanto, hashes de identidad estables derivados de direcciones. Contras: Fija regiones enteras de la heap en ZGC, causando fragmentación y derrotando las capacidades de reubicación concurrente del recolector, lo que lleva a tiempos de pausa inaceptables.
La solución elegida aprovechó la garantía de la especificación del JVM de que los códigos hash de identidad permanecen constantes, combinada con la implementación de almacenamiento en caché de la palabra de marca de HotSpot. Pros: Cero sobrecarga de memoria adicional, sin costo de asignación y completa compatibilidad con recolectores agresivos como ZGC. Contras: Requiere confianza en los detalles de implementación del JVM, aunque está codificado en la especificación.
La aplicación mantuvo una afinidad de sesión perfecta a través de millones de ciclos de ZGC sin fijación ni identificadores auxiliares, logrando tiempos de pausa por debajo de un milisegundo mientras preservaba la integridad de IdentityHashMap.
¿Devuelve siempre System.identityHashCode() la dirección de memoria actual del objeto como un entero?
No. Si bien el cálculo inicial puede usar la dirección de memoria como entropía, el resultado se almacena inmediatamente en el encabezado del objeto y nunca cambia después. Esto significa que el entero devuelto no refleja la ubicación actual del objeto después del movimiento de GC, y los desarrolladores no deben tratarlo como un puntero o una sonda de dirección de memoria.
¿Puede el código hash de identidad ser negativo y cómo manejan esto las colecciones?
Sí, cualquier valor entero de treinta y dos bits es válido, incluidos los números negativos. IdentityHashMap maneja hashes negativos a través de operaciones de enmascaramiento como (h ^ (h >>> 16)) & (length-1), evitando Math.abs() que falla en Integer.MIN_VALUE debido al desbordamiento en complemento a dos.
¿Está garantizado que el código hash de identidad sea único entre todos los objetos?
No. El espacio de enteros de treinta y dos bits es más pequeño que el posible espacio de direcciones de heap, por lo que son posibles colisiones. HotSpot utiliza un esquema de xor-shift de Marsaglia o hashing basado en dirección que distribuye bien los valores, pero la unicidad no está garantizada, lo que hace que IdentityHashMap dependa de la igualdad de referencia para desambiguación, no solo de códigos hash.