Есть ли причина, по которой Object.hashCode() 31-бит?
Если вы запустите следующую версию в 64-разрядной версии HotSpot Java 7.
int countTopBit = 0, countLowestBit = 0;
for (int i = 0; i < 100000000; i++) {
int h = new Object().hashCode();
if (h < 0)
countTopBit++;
if ((h & 1) == 1)
countLowestBit++;
}
System.out.println("The count of negative hashCodes was " + countTopBit + ", the count of odd hashCodes was " + countLowestBit);
вы можете получить результат, например
The count of negative hashCodes was 0, the count of odd hashCodes was 49994232
Мне было интересно, означает ли это, что Object.hashCode()
только 31-битный и почему это может быть так?
Не так, что верхний бит не используется. Из источника для HashMap
257 /**
258 * Applies a supplemental hash function to a given hashCode, which
259 * defends against poor quality hash functions. This is critical
260 * because HashMap uses power-of-two length hash tables, that
261 * otherwise encounter collisions for hashCodes that do not differ
262 * in lower bits. Note: Null keys always map to hash 0, thus index 0.
263 */
264 static int hash(int h) {
265 // This function ensures that hashCodes that differ only by
266 // constant multiples at each bit position have a bounded
267 // number of collisions (approximately 8 at default load factor).
268 h ^= (h >>> 20) ^ (h >>> 12);
269 return h ^ (h >>> 7) ^ (h >>> 4);
270 }
Ответы
Ответ 1
HotSpot поддерживает множество алгоритмов хэширования для Object
. Поскольку вы обнаружили emprically, верхний бит всегда маскируется до возвращения результата:
// src/share/vm/runtime/synchronizer.cpp
static inline intptr_t get_next_hash(Thread * Self, oop obj) {
...
value &= markOopDesc::hash_mask;
...
return value;
}
markOopDesc::hash_mask
вычисляется следующим образом:
enum { age_bits = 4,
lock_bits = 2,
biased_lock_bits = 1,
max_hash_bits = BitsPerWord - age_bits - lock_bits - biased_lock_bits,
hash_bits = max_hash_bits > 31 ? 31 : max_hash_bits,
...
hash_mask = right_n_bits(hash_bits),
Как вы можете видеть, markOopDesc::hash_mask
всегда имеет бит 31, установленный на ноль.
Что касается этого, то ваша догадка так же хороша, как и моя. Возможно, первоначальный разработчик считал, что только дело с положительными целыми числами упростит ситуацию. Насколько нам известно, в расчете hash_bits
это может быть даже одна ошибка.; -)