Хеш-код как serialVersionUid
Я прочитал в статье, что serialVersionUid по умолчанию, предоставляемый JVM, является хэш-кодом объекта. Если мы не переопределим метод хэш-кода в классе, как будет вычисляться хэш-код во время десериализации, поскольку обычно хэш-код является адресом памяти объекта?
Ответы 2
I read in an article that the default
serialVersionUidprovided by JVM is the hashcode of an object.
Это неверно. (Либо статья неверна, либо вы неправильно ее прочитали / поняли.)
UID серийной версии по умолчанию для сериализуемого класса совершенно не связан с hashCode.
Алгоритм генерации UID серийной версии по умолчанию описан здесь:
По сути, он создает хэш SHA-1 из имени классов, модификаторов, имен интерфейсов и сигнатур для своих полей, конструкторов и методов. Затем он берет первые 8 байтов хэша и собирает их в long.
Спасибо, что поделились ссылкой, в которой упоминается подход к генерации SUID. Однако в нем также упоминается, что «Если SUID не объявлен для класса, по умолчанию используется хэш для этого класса».
Этот хеш создается с использованием алгоритма, с которым я связался. Пожалуйста, прочтите это еще раз.
Кетан, возможно, им следовало написать «результат хеширования для этого класса».
@MartinAndersson - Это не >> результат хеширования. Это результаты применения определенной хеш-функции к определенному набору входных данных.
Это я понял =) Но спасибо за разъяснения.
Я думаю, вы неправильно поняли. Это не hashcode. serialVersionUid - статическая переменная, а hashcode - метод экземпляра, и значение хэш-кода объекта варьируется от объекта к объекту.
serialVersionUid рассчитывается на основе структуры вашего класса - полей, методов и т.д. Он указан в http://download.oracle.com/javase/6/docs/platform/serialization/spec/serialTOC.htmlhttp://download.oracle.com/javase/6/docs/platform/serialization/spec/class.html#4100 для точного формата.
В спецификации не указано, что происходит, но при автогенерации используется тот же алгоритм.
Последовательность элементов в потоке следующая:
Имя класса.
Модификаторы класса записываются как 32-битное целое число.
Имя каждого интерфейса, отсортированное по имени.
Для каждого поля класса, отсортированного по имени поля (кроме закрытого статические и частные переходные поля:
- Название поля.
- Модификаторы поля записываются как 32-битное целое число.
- Дескриптор поля.
Если инициализатор класса существует, напишите следующее:
- Имя метода,.
- Модификатор метода, java.lang.reflect.Modifier.STATIC, записанный как 32-битное целое число.
- Дескриптор метода () V.
Для каждого неприватного конструктора, отсортированного по имени метода и сигнатуре:
- Имя метода,.
- Модификаторы метода записываются как 32-битное целое число.
- Дескриптор метода.
Для каждого непубличного метода, отсортированного по имени метода и сигнатуре:
- Название метода.
- Модификаторы метода, записанные как 32-битное целое число.
- Дескриптор метода.
- Алгоритм SHA-1 выполняется в потоке байтов, созданном DataOutputStream, и выдает пять 32-битных значений sha [0..4]. Хеш-значение собирается из первого и второго 32-битных значений дайджеста сообщения SHA-1. Если результат дайджеста сообщения, пять 32-битных слов H0 H1 H2 H3 H4, находится в массиве из пяти значений int с именем sha, хеш-значение будет вычислено следующим образом:
long hash= ((sha [0] >>> 24) & 0xFF) |((sha [0] >>> 16) & 0xFF) << 8 |
((sha [0] >>> 8) & 0xFF) << 16 |
((sha [0] >>> 0) & 0xFF) << 24 |
((sha [1] >>> 24) & 0xFF) << 32 |
((sha [1] >>> 16) & 0xFF) << 40 |
((sha [1] >>> 8) & 0xFF) << 48 |
((ша [1] >>> 0) & 0xFF) << 56;
Здесь long hash не упоминается как hashcode.
В JVM будет ОДИН экземпляр каждого класса. Итак, что в документе говорится о hashCode, это экземпляр класса ...
Не могли бы вы поделиться ссылкой на документ.
Я предполагаю, что вы имеете в виду статью «Откройте для себя секреты API сериализации Java», где говорится: «Вы можете использовать утилиту
serialver, поставляемую с дистрибутивом JDK, чтобы увидеть, каким будет этот код по умолчанию (по умолчанию это просто хеш-код объекта)».