2015-06-03 4 views
1

Я хотел бы иметь возможность получить тот же идентификатор, который используется в дампах кучи Java (созданных с помощью jmap или JMX и т. Д.). Это позволяет идентифицировать живой объект в неподвижном приложении по сравнению с более старым снимком памяти (дампом кучи) того же приложения.Как получить идентификатор объекта, используемый в куче кучи

Я уже проверил немного, и это obvioulsy не hashCode, ни уникальный идентификатор JDI (который вы можете видеть в своих отладчиках).

От проверки кода в sun.jvm.hotspot.utilities Я предполагаю, что это адрес объектов в памяти. Но также мои тесты с sun.misc.Unsafe не привели к тому же значению id, что и в кучих кучи. (см. здесь для некоторых Небезопасное объяснение: http://zeroturnaround.com/rebellabs/dangerous-code-how-to-be-unsafe-with-java-classes-objects-in-memory/)

Любые идеи? Благодаря :) !

+0

Означает ли объект (или любой из его супер-объектов) hashCode? Если это так, вам может повезти с ['System.identityHashCode()'] (http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#identityHashCode%28java.lang. Object% 29) – blazetopher

+0

Или это может быть так же просто, как нужно шестнадцатеричное значение hashCode? 'Integer.toHexString (obj.hashCode())' ... – blazetopher

+0

Спасибо за ваш комментарий, но нет, поскольку я сказал, что это, к сожалению, не hashCode. Также не System.identiyHashCode (это то же самое, что и обычный хэш-код объекта, если он не переопределяется). И нет, шестнадцатеричный или десятичный не имеет значения. В конце концов, это одно и то же значение, не так ли? Большинство анализаторов дампов кучи имеют тенденцию отображать значение как шестнадцатеричное. Это простое длинное значение в моем случае (вероятно, из-за 64-битного jvm). –

ответ

2

Есть два различных способа создания дампа кучи:

  1. внутри процесса виртуальной машины Java с использованием Dynamic Attach Mechanism (jmap делает это), или
  2. от внешнего процесса с использованием Serviceability Agent (jmap -F)

В обоих случаях идентификатор объекта в дампе кучи является адресом памяти объекта в момент создания дампа. Вот соответствующий исходный код HotSpot: [1] и [2].

Однако этот идентификатор объекта не имеет смысла вне файла дампа, поскольку объекты могут перемещаться в памяти во время сбора мусора.

Другая проблема заключается в том, что трудно получить (или даже невозможно) надежный адрес объекта Java из приложения Java - опять же, поскольку объекты могут перемещаться вдоль кучи и потому, что представление ссылок на объекты может варьироваться различные архитектуры, среды и варианты JVM, например в зависимости от размера кучи, UseCompressedOops и т. д. Здесь получается an example получения адреса объекта из приложения Java, но это не гарантируется для работы со всеми версиями JVM.