モジュール java.base
パッケージ java.util

クラスHashMap<K,V>

java.lang.Object
java.util.AbstractMap<K,V>
java.util.HashMap<K,V>
型パラメータ:
K - このマップで保持されるキーの型
V - マップされる値の型
すべての実装されたインタフェース:
Serializable, Cloneable, Map<K,V>
直系の既知のサブクラス:
LinkedHashMap, PrinterStateReasons

public class HashMap<K,V> extends AbstractMap<K,V> implements Map<K,V>, Cloneable, Serializable
Mapインタフェースのハッシュ表ベースの実装。 この実装では、すべてのオプションのマップ操作が提供され、null値およびnullキーが許可されます。 (HashMapクラスは、Hashtableとほぼ同等ですが、非同期でNULLが許可される点が異なります。) このクラスはマップの順序を保証しません。特に、その順序を常に一定に保つことを保証しません。

この実装は、ハッシュ関数が要素をバケット間で適切に分散すると仮定して、基本操作(getおよびput)に対して一定時間のパフォーマンスを提供します。 コレクション・ビューを反復するには、HashMapインスタンス(バケット数)の"容量"とそのサイズ(キーと値のマッピングの数)に比例した時間が必要です。 したがって、反復処理の性能が重要な場合は、初期容量をあまり高く(負荷係数をあまり低く)設定しないことが非常に重要です。

HashMapのインスタンスには、そのパフォーマンスに影響する2つのパラメータがあります: 初期容量および負荷率 容量はハッシュ表のバケット数であり、初期容量は単純にハッシュ表が作成された時点での容量です。 負荷係数は、ハッシュ表がどの程度いっぱいになると、その容量が自動的に増加されるかの基準です。 ハッシュ表エントリ数が負荷係数と現在の容量の積を超えると、ハッシュ表のハッシュがやり直され (つまり、内部データ構造が再構築され)、ハッシュ表のバケット数は約2倍になります。

ほとんどの場合、デフォルトの負荷係数(.75)では、時間コストとスペース・コストの釣合いを取ります。 値を大きくすると領域のオーバーヘッドは減少しますが、ルックアップ・コストは(getputなど、HashMapクラスのほとんどの操作に反映されます)になります。 初期容量を設定するときは、rehashオペレーションの回数を最小限に抑えるために、マップのエントリ予定数および負荷係数を考慮する必要があります。 初期容量が、エントリの最大数を負荷係数で割った値より大きい場合、rehashオペレーションは起こりません。

多数のマッピングをHashMapインスタンスに格納する場合、十分な容量でそれを作成すると、表の拡張に必要な自動リハッシングを実行するよりも、マッピングをより効率的に格納できます。 同じhashCode()で多数のキーを使用すると、必ずいずれかのハッシュ表のパフォーマンスが低下することに注意してください。 影響を軽減するため、キーがComparableである場合は、このクラスでキー間の比較順序を使用してキーの重複を解消できます。

この実装はsynchronizedされません。 複数のスレッドが並行してハッシュ・マップにアクセスし、それらのスレッドの少なくとも1つが構造的にマップを変更する場合は、外部でその同期をとる必要があります 構造的な変更とは、1つ以上のマッピングを追加または削除するオペレーションのことです。すでにインスタンスに格納されているキーに関連付けられた値を変更することは構造的な変更ではありません。 これは通常、マップを自然にカプセル化する一部のオブジェクトでsynchronizedすることによって達成されます。 そのようなオブジェクトが存在しない場合は、Collections.synchronizedMapメソッドを使用してマップを「ラップ」することをお薦めします。 マップが誤ってsynchronizedなしでアクセスされるのを防ぐために、作成時に行うことをお薦めします。

   Map m = Collections.synchronizedMap(new HashMap(...));

このクラスの"コレクション表示メソッド"すべてによって返されるイテレータは、fail-fastです: イテレータの作成後にマップが構造的に変更された場合、イテレータ独自のremoveメソッド以外のすべての方法で、イテレータはConcurrentModificationExceptionをスローします。 このように、並行して変更が行われると、イテレータは、将来の予測できない時点において予測できない動作が発生する危険を回避するために、ただちにかつ手際よく例外をスローします。

通常、非同期の並行変更がある場合、確かな保証を行うことは不可能なので、イテレータのフェイルファストの動作を保証することはできません。 フェイルファスト・イテレータは、ベスト・エフォート・ベースでConcurrentModificationExceptionをスローします。 したがって、正確を期すためにこの例外に依存するプログラムを書くことは誤りです。イテレータのフェイルファストの動作はバグを検出するためにのみ使用すべきです。

このクラスは、Java Collections Frameworkのメンバーです。

導入されたバージョン:
1.2
関連項目: