1. 最初に答えを教えてください。
为了能让 HashMap *存取高效*，进一步降低hash冲突的几率，尽量较少碰撞，也就是要尽量把数据分配均匀。
2. 予備知識:
2.1 なぜ長さは 2 のべき乗なのでしょうか?
HashMapでは初期容量を指定できます。初期容量を指定しない場合、デフォルトは16であり、容量を拡張するたびに2倍になります。初期容量を指定する場合は、初期容量の2のべき乗をHashMapの容量として使用します。
JDK1.8 より前は、HashMap の最下層は配列とリンク リストであり、これらを組み合わせてリンク リスト ハッシュを形成しました。
JDK1.8 以降、HashMap の最下層は配列 + リンクされたリスト + 赤黒ツリーとなり、検索プロセスがさらに高速化されます。
HashMap でオブジェクトの位置をハッシュするプロセスは 3 つのステップに分かれています。
1) キーのハッシュコードを取得します: h=key.hashCode()
2) 取得したハッシュ値と h の符号なし右シフト値との XOR:ハッシュ値に等しい ( h = key.hashCode()) ^ (h >>> 16);
3) ステップ 2) の XOR 結果と配列の長さから 1 を引いた値に対してビット単位の AND 演算を実行して、添字を取得します: int Index = ( n - 1) & ハッシュ。添字に既に要素がある場合は、その要素のハッシュ値とキーと格納する要素が同じかどうかを判定し、同じであれば網羅する。
int型は32ビットなので、バイナリコンピュータでの範囲値は-2 31～2 31 -1となり、ハッシュ値の範囲値は-2147483648～2147483647となります。総マッピング空間は約 40 億であり、ハッシュ関数が均等かつ緩やかにマッピングされている限り、一般的なアプリケーションでは衝突は起こりにくいです。しかし問題は、長さ 40 億の配列がメモリに収まらないことです。したがって、このハッシュ値を直接使用することはできません。
これを使用する前に、配列の長さに対してモジュロ演算hash % length を実行し、得られた剰余が配列の添字となります。ただし、コンピュータでの剰余 % の計算効率はビット演算 & ほど良くなく、ソース コードはハッシュ & (長さ - 1) に最適化されています。しかし、
hash % length == hash & (length - 1)的前提是 length 是 2的n次方。
理由は次のとおりです。
ビット単位の AND 演算 & : まず値を 2 進数に変換します。0 があれば 0、すべての 1 が 1 の場合、
HashMap の長さが奇数の場合、length-1 は偶数です。数値であり、偶数の最後の桁が 0 である場合、ハッシュ & (長さ - 1) の最後の桁は偶数である 0 でなければなりません。現時点では、ハッシュ値は偶数の添字位置にのみハッシュ化できるため、スペースが無駄になり、衝突が増加します。
HashMap の長さ length が偶数の場合、length-1 は奇数となり、奇数の最後の桁は 1 となり、ハッシュ & (長さ - 1) の最後の桁はハッシュ値に依存します。均等に漕ぎます。
したがって、長さは 2 の累乗とみなされ、ハッシュ テーブル内で要素を均等にハッシュできるため、異なるハッシュ値間の衝突の確率が小さくなります。
2.2 16 ビット XOR によってハッシュを右にシフトする必要があるのはなぜですか? h>>>16
または演算 ^ : 異なるは 1、同じは 0、これにより各部分の特性をよりよく保持できます (01 はすべての変更を持ちます)
h >>> 16 : int は 32 ビットなので、h のバイナリ値を右に 16 ビット移動することを意味し、右に 16 ビットシフトした後、上位 16 ビットを下位 16 ビットにシフトすることを意味します。上位 16 ビットはすべて 0 です。
(h = key.hashCode()) ^ (h >>> 16) : 上位 16 ビットと下位 16 ビットを XOR 演算に使用することを意味します。衝突を減らすために上位ビットも操作に参加させます。
? それでは、なぜ & や | を使用せずに ^ を使用するのでしょうか?
& 演算で計算される値は 1 に近づき、| 演算で計算される値は 0 に近くなり、^ の方が各部分の特性をよりよく保持できます。