HotSpot JVM гарантирует консистентность Object.hashCode() при перемещении объектов, вычисляя значение один раз — обычно из начального адреса памяти — и кэшируя его в заголовке объекта в маркере, прежде чем какой-либо цикл сборки мусора сможет переместить объект. Этот маркер содержит специальное поле для кода хеша наряду с битовым флагом, указывающим на то, что хеш был материализован, что гарантирует, что последующие вызовы извлекают закешированное значение вместо повторного вычисления. Таким образом, даже когда сборщики, такие как G1 или ZGC, эвакуируют объект на новый адрес, идентификационный хеш остается стабильным, поскольку он отделен от физического указателя и хранится в неизменяемых метаданных заголовка.
Распределенное веб-приложение использовало IdentityHashMap для отслеживания активных объектов Session на нескольких узлах приложения, полагаясь на System.identityHashCode() для маршрутизации кэша во время операций балансировки нагрузки. В условиях пиковой нагрузки сборщик с низкой задержкой ZGC выполнял частые одновременные перемещения объектов молодого поколения, чтобы поддерживать строгие целевые интервалы задержки. Если бы идентификационный хеш изменился при перемещении, это нарушило бы аффинность сеанса, вызвав смешение запросов между узлами и нарушив гарантии консистентности.
Одним из подходов было создание экземпляров UUID для каждого Session при его создании и ведение отдельной ConcurrentHashMap<UUID, Session>. Плюсы: полная независимость от жизненного цикла объектов JVM и механики перемещения. Минусы: добавление шестнадцати байт накладных расходов на каждый объект сессии и создание давления при распределении из-за генерации UUID, что потенциально может переполнить скорость распределения при резком трафике.
Команда также рассматривала возможность «прикрепления» объектов сессии в памяти с помощью критических ссылок JNI, чтобы предотвратить перемещение GC. Плюсы: гарантии стабильных адресов в памяти и, соответственно, стабильных идентификационных хешей, полученных из адресов. Минусы: «прищепка» целых областей кучи в ZGC приводит к фрагментации и нарушает возможности одновременного перемещения сборщика, что может привести к неприемлемым задержкам.
Выбранное решение воспользовалось гарантией спецификации JVM о том, что идентификационные коды хешей остаются постоянными, совместно с реализацией кэширования маркера HotSpot. Плюсы: нулевая дополнительная накладка на память, отсутствие затрат на распределение и полная совместимость с агрессивными сборщиками, такими как ZGC. Минусы: требуется доверие к деталям реализации JVM, хотя они удостоверены в спецификации.
Приложение поддерживало идеальную аффинность сессии на протяжении миллионов циклов ZGC без прикреплений или дополнительных идентификаторов, достигая подмиллисекундных времен задержки, сохраняя при этом целостность IdentityHashMap.
Всегда ли System.identityHashCode() возвращает текущее местоположение объекта в памяти в виде целого числа?
Нет. Хотя изначальное вычисление может использовать адрес памяти в качестве энтропии, результат немедленно сохраняется в заголовке объекта и больше не изменяется. Это означает, что возвращаемое целое число не отражает текущее местоположение объекта после перемещения GC, и разработчики не должны рассматривать его как указатель илиProbe массива памяти.
Может ли идентификационный код хеша быть отрицательным и как с этим справляются коллекции?
Да, любое значение целого числа размером тридцать два бита является допустимым, включая отрицательные числа. IdentityHashMap обрабатывает отрицательные хеши с помощью операций маскирования, таких как (h ^ (h >>> 16)) & (length-1), избегая Math.abs(), который не работает на Integer.MIN_VALUE из-за переполнения знакового числа.
Гарантирован ли уникальный идентификационный код хеша среди всех объектов?
Нет. Пространство целых чисел размером в тридцать два бита меньше потенциального адресного пространства кучи, поэтому возможны коллизии. HotSpot использует схему xor-сдвига Марсальи или хеширование на основе адреса, которое хорошо распределяет значения, но уникальность не гарантируется, что заставляет IdentityHashMap полагаться на равенство ссылок для устранения неоднозначности, а не только на коды хешей.