サイズ変更または再ハッシュがいつ発生するかを知りたいのですが、要素をマップに配置しようとするとどうなりますか?それは新しい増加したマップまたは古いマップに移動しますか?
また、負荷率が 75% であるため、元のマップ サイズの 25% である hashmap の余分な空き領域の使用は何ですか?
2 に答える
2
おそらく、これには首尾一貫した答えが必要です。
要素をマップに配置しようとすると、サイズ変更または再ハッシュがいつ行われるかを知りたいです。
この質問は、 で操作を実行するスレッドが 2 つ以上ある場合にのみ意味がありますHashMap。そうしている場合、コードはスレッドセーフではありません。その動作は特定されておらず、バージョン固有であり、予期しないときに悪いことが起こる可能性があります。エントリが失われたり、不可解な NPE が発生したり、スレッドの 1 つが無限ループに陥ったりすることさえあります。
HashMap同時操作を避けるために、適切な外部同期なしで で 2 つ以上のスレッドが動作するコードを記述しないでください。もしそうなら、私はあなたに何が起こるかは言えません。
を使用するスレッドが 1 つしかない場合HashMap、心配しているシナリオは不可能です。サイズ変更は、更新操作中に発生します。
複数のスレッドがあり、同時操作を防ぐために同期する場合、心配しているシナリオは不可能です。もう 1 つの方法はConcurrentHashMap、複数のスレッドが同時に red と write を行うことができる場合に正しく動作するように設計された which を使用することです。(当然、 a のサイズを変更するためのコードはConcurrentHashMapもっと複雑です。しかし、これにより、エントリが正しい場所に配置されることが保証されます。)
新しい増加マップに行くか、古いマップに行くか。
マルチスレッドの非同期ケースについて話していると仮定すると、答えは特定されておらず、おそらくバージョン固有です。(コードは確認していません。) それ以外の場合、シナリオは不可能です。
また、負荷率が 75% であるため、元のマップ サイズの 25% である hashmap の余分な空き領域の使用は何ですか?
使用されません。負荷率が 75% の場合、ハッシュ スロットの少なくとも 25% が空になるか、まったく使用されません。(アーキテクチャ上の理由でハッシュ配列をこれ以上拡張できないポイントに到達するまで。ただし、そのポイントに到達することはめったにありません。)
これはパフォーマンスのトレードオフです。Sun のエンジニアは、75% の負荷率が、使用されるメモリと での操作の実行にかかる時間との間の最適なトレードオフになると判断/判断しましたHashMap。負荷係数を大きくすると、スペースの使用率は向上しますがHashMap、ハッシュ チェーンの平均長が長くなるため、ほとんどの操作は遅くなります。
必要に応じて、別の負荷係数値を自由に使用できます。潜在的な結果に注意してください。
于 2020-02-02T14:50:31.493 に答える