HashMapの
+ HashMapの下地層は、リンクされたリストからなる配列に基づいて、若干異なるjdk1.7および1.8で具現化されます。
唯一の配列とリンクリスト構造の底部では1.7で、しかし、ハッシュ紛争の多くは、我々は競合はますます長くなるリスト、我々は必然的にO（N）のルックアップの時間を取る必要がありますので、これは素晴らしいです損失
1.8ハッシュ・ノードの数がします8以上赤黒木構造の複雑さに今回のみO（LOGN）である場合には、効率を向上させるためのものです
問題を拡大
ハッシュマップを超えて製品の長さと負荷率の電流容量（= 0.75×16 12デフォルト）が、オリジナルを再作成するときNEWTABLE AのHashMapアレイの2倍のサイズ1 + 30 ^ 2にリサイズ方法、最大拡張を呼び出すことによって、および再ハッシュと分配位置に応じて移動NEWTABLE再計算ハッシュすべての要素の元のテーブル。それは新しいバケット位置を見つけるために、ハッシュメソッドを呼び出すので、このプロセスは、焼き直しと呼ばれています。
アレイの拡張後は、ほとんどの消費性能ポイントが登場：配列内の元のデータは、新しい配列内での位置を再計算しなければならない、と彼らに、この操作は非常に消費パフォーマンスです。私たちが予想していた場合のHashMapの要素数ので、デフォルトの初期容量を有効にHashMapのパフォーマンスを向上させることができます。
HashMapの条件が発生する可能性がありマルチスレッドレースの場合には、サイズを再調整します。なぜならもし2つのスレッドがサイズを変更するのHashMapの必要性を発見している、と彼らはまた、サイズを調整しようとします。バケットは、ハッシュマップがある、リストの最後に、しかし、頭の上に素子を取らない場合、新しい場所に移動するため、リサイズ処理では、要素の順序は、順番にリンクされたリストに格納されていますテール（尾の横断）を横断避けるために。死の競争の状況が発生した場合、サイクル。
スレッドの安全性の問題
まずHashMapのは、スレッドセーフではないことを決定し、いくつかの奇妙で予測できない問題は、直接、マルチスレッド状況でHashMapを使用します。マルチスレッドでの使用HashMapの、いくつかのオプションがあります。
外装のHashMap、同期メカニズムにおいてA.
B.使用地図メートル= Collections.synchronizedMap（新しいHashMapの（...））;同期（マッピングエラーが発生しやすいの構造を変更するために時間をかけて繰り返し処理を使用するように、公式プログラムを参照して、推奨されません）
D.使用したjava.util.Hashtable、最小効率（ほぼ除去）
E.使用java.util.concurrent.ConcurrentHashMap、比較的安全、効率的な（推奨）
**
ConcurrentHashMapの
**
とHashMapのは非常に類似しており、唯一の違いは、そのような値として、コアデータの一つであり、リストは、取得時の視認性を確保するように改変揮発性です。
原則として：ConcurrentHashMapのは、ReentrantLockのから継承されたセグメント分割されたロック技術を使用しています。ハッシュテーブルは、いずれかのプットまたはスレッドの同時実行の操作が同期を行う必要があります、理論的にはConcurrentHashMapのサポートCurrencyLevel（配列のセグメント数）好きではなかったです。たびセグメントへのロックのアクセスを保持しているスレッドは、他のセグメントには影響しません。
