私は：を構築するためのパラメータについて疑問に思っていますConcurrentHashMap：
initialCapacityデフォルトでは16です（理解されています）。loadFactorデフォルトでは0.75です。concurrencyLevelデフォルトでは16です。私の質問は次のとおりです。
loadFactorか？concurrencyLevelか？さらに：
ありがとうございました！
負荷率は、主にハッシュ関数の品質に関連しています。負荷係数がゼロに近づくほど、ハッシュ関数がそれほど優れていなくても、衝突が発生する可能性は低くなります。トレードオフは、メモリ フットプリントが大きくなることです。つまり、HashMap はエントリを個別のハッシュコードごとに個別のバケットに分散するのではなく、近接性によってグループ化するため、バケットが多いほど分散が広がり、衝突が発生する可能性が低くなります。
したがって、要点は、ニーズとマップに保存するオブジェクトに応じて、負荷係数をいじってルックアップ時間を改善するか、メモリを削減することです。
ConcurrencyLevel は実際にはアプリケーションに依存します。アプリケーションで実行しているスレッドが 2 つまたは 3 つしかない場合は、問題ありません。任意の数のスレッドを持つアプリケーション サーバーの場合、負荷容量と最適化するポイントを理解する必要があります。
高品質のハッシュコードの実装は、コントラクトを尊重しながら、衝突の数を最小限に抑えながら、オブジェクトの潜在的な値全体に可能な限り広い分布を提供します。つまり、HashMap (場合によっては Set) がオブジェクトを個別のバケットに分散して、検索を高速化できるようにします。
loadFactor: 実装がハッシュテーブルのサイズ変更を決定するタイミングを制御します。値が高すぎるとスペースが無駄になります。値が小さすぎると、サイズ変更操作のコストが高くなります。
concurrencyLevel: 指定された数の書き込みスレッドを最適化するように実装に指示します。API docs によると、最大 10 倍のずれがあっても、パフォーマンスに大きな影響はありません。
更新操作間で許可される同時実行数は、オプションの concurrencyLevel コンストラクター引数 (デフォルト 16) によってガイドされます。これは、内部サイズ設定のヒントとして使用されます。テーブルは内部的に分割され、指定された数の同時更新を競合なしで許可しようとします。ハッシュ テーブル内の配置は基本的にランダムであるため、実際の同時実行数は異なります。理想的には、同時にテーブルを変更するスレッド数に対応できる値を選択する必要があります。必要以上に高い値を使用すると、スペースと時間が浪費される可能性があり、極端に低い値を使用すると、スレッドの競合が発生する可能性があります。しかし、1 桁以内の過大評価と過小評価は、通常、それほど顕著な影響を及ぼしません。
適切なハッシュコードの実装では、任意の間隔でハッシュ値が均一に分散されます。キーのセットが事前にわかっている場合、各キーに対して一意のハッシュ値を作成する「完全な」ハッシュ関数を定義できます。
loadFactor はデフォルトで 0.75 に設定されていますが、これを上下に調整するにはどの基準を使用する必要がありますか?
これがどのように機能するかを理解するには、ハッシュ マップがどのように機能するかについての背景知識が必要です。マップは基本的に一連のバケットです。マップ内の各値は、そのハッシュ コードに応じてバケットに入れられます。loadFactor は、バケットが 75% 以上埋まっている場合、マップのサイズを変更する必要があることを意味します
concurrencyLevel はデフォルトで 16 に設定されていますが、同時更新スレッドの数をどのように設定すればよいでしょうか? これを上下に調整するには、どの基準を使用する必要がありますか?
これは、Map を同時に (同時に) 変更すると予想されるスレッドの数を尋ねています。
ハッシュ コードについては、Joshua Bloch の「Effective Java 」を参照してください。