понимание метода комментария для хэша() класса HashMap в Java 8

/** 
    * Computes key.hashCode() and spreads (XORs) higher bits of hash 
    * to lower. Because the table uses power-of-two masking, sets of 
    * hashes that vary only in bits above the current mask will 
    * always collide. (Among known examples are sets of Float keys 
    * holding consecutive whole numbers in small tables.) So we 
    * apply a transform that spreads the impact of higher bits 
    * downward. There is a tradeoff between speed, utility, and 
    * quality of bit-spreading. Because many common sets of hashes 
    * are already reasonably distributed (so don't benefit from 
    * spreading), and because we use trees to handle large sets of 
    * collisions in bins, we just XOR some shifted bits in the 
    * cheapest possible way to reduce systematic lossage, as well as 
    * to incorporate impact of the highest bits that would otherwise 
    * never be used in index calculations because of table bounds. 
    */ 

static final int hash(Object key) { 
    int h; 
    return (key == null) ? 0 : (h = key.hashCode())^(h >>> 16); 
}

ниже предыдущая версия JDK 1.6понимание метода комментария для хэша() класса HashMap в Java 8

/** 
    * Applies a supplemental hash function to a given hashCode, which 
    * defends against poor quality hash functions. This is critical 
    * because HashMap uses power-of-two length hash tables, that 
    * otherwise encounter collisions for hashCodes that do not differ 
    * in lower bits. Note: Null keys always map to hash 0, thus index 0. 
    */ 
    static int hash(int h) { 
     // This function ensures that hashCodes that differ only by 
     // constant multiples at each bit position have a bounded 
     // number of collisions (approximately 8 at default load factor). 
     h ^= (h >>> 20)^(h >>> 12); 
     return h^(h >>> 7)^(h >>> 4); 
    }

может кто-нибудь объяснить, какие преимущества это применяющие этот вид хэширования, чем это был выполнен в более ранних версиях java. Как это повлияет на скорость и качество распределения ключей, и я имею в виду новую хеш-функцию, реализованную в jdk 8, и как она была достигнута для уменьшения конфликтов?

источник

2016-04-11 Ram Kumar

Не могли бы вы включить фрагмент кода, как это было сделано в более ранних версиях? В частности, в разных версиях могут быть разные реализации. Что именно вы имеете в виду? –

http://stackoverflow.com/questions/30225054/why-is-there-a-transformation-of-hashcode-to-get-the-hash-and-is-it-a-good-idea и http://stackoverflow.com/questions/33177043/why-and-how-does-hashmap-have-its-own-internal-implementation-of-hashcode-call/33177236 – Tom

@tobias_k отредактировал вопрос, включив предыдущую версию хэширования. –

В ситуациях, когда метод hashCode довольно плохо себя ведет, производительность HashMap может резко ухудшиться. Например, скажем, ваш метод hashCode генерировал только 16 бит.

Это решает проблему xor с хеш-кодом, который сам по себе сдвинут вправо 16. Если номер был хорошо распределен, для этого он все равно должен быть. Если бы это было плохо, это должно улучшить его.

источник

2016-04-11 16:24:03 OldCurmudgeon

Но как мы достигли сдвига 16 бит вправо, и почему бы не 32 сделать это эффективным. Хотите знать, как мы обрушились на этот –

понимание метода комментария для хэша() класса HashMap в Java 8

ответ

Смежные вопросы