0

JavaDoc API によると、HashSet は HashMap の単なるラッパーです。したがって、HashMap よりも HashSet を使用すると、パフォーマンスが向上する可能性があります。これまで？これまで？それとも、他のケースに適した別の API を用意するだけですか?

4

2 に答える 2

3

いいえ、「パフォーマンス」のメリットはありません。適切な問題に適切な API を使用することで得られるメリットは、それだけです...これはかなりのものです。

于 2013-03-22T21:19:20.450 に答える
1

実際にはパフォーマンス上の利点はありません。どちらも異なる目的に役立ちます。

API ドキュメントのハッシュセットについて

このクラスは、ハッシュ テーブル (実際には HashMap インスタンス) によってサポートされる Set インターフェイスを実装します。セットの反復順序については保証されません。特に、順序が長期的に一定であることを保証するものではありません。このクラスは null 要素を許可します。

このクラスは、ハッシュ関数が要素をバケット間で適切に分散すると仮定すると、基本操作 (追加、削除、包含、およびサイズ) に対して一定時間のパフォーマンスを提供します。このセットを反復処理するには、HashSet インスタンスのサイズ (要素の数) とバッキング HashMap インスタンスの「容量」 (バケットの数) の合計に比例する時間が必要です。したがって、反復のパフォーマンスが重要な場合は、初期容量を高く設定しすぎないようにする (または負荷係数を低く設定しすぎない) ことが非常に重要です。

この実装は同期されていないことに注意してください。複数のスレッドが同時にハッシュ セットにアクセスし、少なくとも 1 つのスレッドがセットを変更する場合は、外部で同期する必要があります。これは通常、セットを自然にカプセル化するオブジェクトを同期することによって実現されます。そのようなオブジェクトが存在しない場合は、Collections.synchronizedSet メソッドを使用してセットを「ラップ」する必要があります。これは、セットへの偶発的な非同期アクセスを防ぐために、作成時に行うのが最適です。

   Set s = Collections.synchronizedSet(new HashSet(...));

このクラスの iterator メソッドによって返される反復子はフェイルファストです。反復子の作成後に、反復子自体の remove メソッド以外の方法でセットが変更されると、Iterator は ConcurrentModificationException をスローします。したがって、同時変更に直面した場合、反復子は、将来の不確定な時点で恣意的で非決定論的な動作を危険にさらすのではなく、迅速かつ明確に失敗します。

イテレータのフェイルファスト動作は保証できないことに注意してください。一般的に言えば、同期されていない同時変更が存在する場合にハードな保証を行うことは不可能であるためです。フェイルファスト イテレーターは、ベスト エフォート ベースで ConcurrentModificationException をスローします。したがって、その正確性をこの例外に依存するプログラムを作成するのは誤りです。反復子のフェイルファスト動作は、バグを検出するためだけに使用する必要があります。

このリファレンスを確認してください: HashSet

于 2013-03-22T21:20:10.660 に答える