jdk1.6以降のHashMapsがmulti = threadingで問題を引き起こすことを考えると、コードを修正するにはどうすればよいですか？

私は最近stackoverflowで質問をし、その答えを見つけました。最初の質問は、ミューテックスまたはガベージコレクション以外のどのメカニズムがマルチスレッドJavaプログラムを遅くする可能性があるかということでした。

恐ろしいことに、HashMapがJDK1.6とJDK1.7の間で変更されていることに気づきました。これで、HashMapを作成するすべてのスレッドを同期させるコードのブロックができました。

JDK1.7.0_10のコード行は次のとおりです。

 /**A randomizing value associated with this instance that is applied to hash code of  keys to make hash collisions harder to find.     */
transient final int hashSeed = sun.misc.Hashing.randomHashSeed(this);

どちらが呼び出すことになります

 protected int next(int bits) {
    long oldseed, nextseed;
    AtomicLong seed = this.seed;
    do {
        oldseed = seed.get();
        nextseed = (oldseed * multiplier + addend) & mask;
    } while (!seed.compareAndSet(oldseed, nextseed));
    return (int)(nextseed >>> (48 - bits));
 }    

他のJDKを見ると、これはJDK1.5.0_22またはJDK1.6.0_26には存在しません。

私のコードへの影響は甚大です。これにより、64スレッドで実行した場合、1スレッドで実行した場合よりもパフォーマンスが低下します。JStackは、ほとんどのスレッドがランダムのそのループでスピンすることにほとんどの時間を費やしていることを示しています。

だから私はいくつかのオプションがあるようです：

• HashMapを使用しないようにコードを書き直しますが、同様のものを使用します
• どういうわけかrt.jarをいじって、その中のハッシュマップを置き換えます
• どういうわけかクラスパスを台無しにするので、各スレッドは独自のバージョンのHashMapを取得します

これらのパスのいずれかを開始する前に（すべて非常に時間がかかり、影響が大きい可能性があるように見えます）、明らかなトリックを見逃したのではないかと思いました。あなたの誰かがオーバーフローした人々を積み重ねて、どちらがより良い道であるかを提案したり、おそらく新しいアイデアを特定したりできますか？

助けてくれてありがとう

私は7u6、CR＃7118743：ハッシュベースのマップを使用した文字列の代替ハッシュ‌に登場したパッチの最初の作成者です。

hashSeedの初期化がボトルネックであることを前もって認めますが、ハッシュマップインスタンスごとに1回しか発生しないため、問題になると予想されるものではありません。このコードがボトルネックになるには、1秒あたり数百または数千のハッシュマップを作成する必要があります。これは確かに典型的ではありません。アプリケーションがこれを行う正当な理由は本当にありますか？これらのハッシュマップはどのくらいの期間存続しますか？

とにかく、おそらくランダムではなくThreadLocalRandomへの切り替えと、cambeccによって提案されたレイジー初期化のいくつかのバリアントを調査します。

編集3

ボトルネックの修正がJDK7アップデートのMercurialリポジトリにプッシュされました。

http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b03bbdef3a88

この修正は、今後の7u40リリースの一部であり、IcedTea2.4リリースですでに利用可能です。

7u40のほぼ最終的なテストビルドはこちらから入手できます。

https://jdk7.java.net/download.html

フィードバックは引き続き歓迎します。それをhttp://mail.openjdk.java.net/mailman/listinfo/core-libs-devに送信して、openJDK開発者に確実に表示されるようにします。

これは、回避できる「バグ」のように見えます。新しい「代替ハッシュ」機能を無効にするプロパティがあります。

jdk.map.althashing.threshold = -1

ただし、代替ハッシュを無効にしても、ランダムハッシュシードの生成がオフにならないため、十分ではありません（実際には必要ですが）。したがって、altハッシュをオフにしても、ハッシュマップのインスタンス化中にスレッドの競合が発生します。

これを回避する特に厄介な方法の1つはRandom、ハッシュシードの生成に使用されるインスタンスを独自の非同期バージョンに強制的に置き換えることです。

// Create an instance of "Random" having no thread synchronization.
Random alwaysOne = new Random() {
    @Override
    protected int next(int bits) {
        return 1;
    }
};

// Get a handle to the static final field sun.misc.Hashing.Holder.SEED_MAKER
Class<?> clazz = Class.forName("sun.misc.Hashing$Holder");
Field field = clazz.getDeclaredField("SEED_MAKER");
field.setAccessible(true);

// Convince Java the field is not final.
Field modifiers = Field.class.getDeclaredField("modifiers");
modifiers.setAccessible(true);
modifiers.setInt(field, field.getModifiers() & ~Modifier.FINAL);

// Set our custom instance of Random into the field.
field.set(null, alwaysOne);

なぜこれを行うのが（おそらく）安全なのですか？altハッシュが無効になっているため、ランダムハッシュシードが無視されます。したがって、のインスタンスがRandom実際にランダムでなくてもかまいません。このような厄介なハックではいつものように、注意して使用してください。

（静的な最終フィールドを設定するコードについては、https：//stackoverflow.com/a/3301720/1899721に感謝します）。

---編集---

FWIW、次の変更HashMapにより、altハッシュが無効になっている場合のスレッドの競合が解消されます。

-   transient final int hashSeed = sun.misc.Hashing.randomHashSeed(this);
+   transient final int hashSeed;

...

         useAltHashing = sun.misc.VM.isBooted() &&
                 (capacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD);
+        hashSeed = useAltHashing ? sun.misc.Hashing.randomHashSeed(this) : 0;
         init();

同様のアプローチはConcurrentHashMap、などにも使用できます。

ビッグデータアプリケーションのレコードごとに一時的なHashMapを作成するアプリはたくさんあります。たとえば、このパーサーとシリアライザー。同期を同期されていないコレクションクラスに入れることは、本当の落とし穴です。私の意見では、これは受け入れられず、できるだけ早く修正する必要があります。7u6、CR＃7118743で明らかに導入された変更は、同期やアトミック操作を必要とせずに元に戻すか修正する必要があります。

どういうわけか、これは、JDK 1.1 /1.2でStringBufferとVectorおよびHashTableを同期させるという大きな間違いを思い出させます。人々はその過ちに対して何年にもわたって高額の支払いをしました。その経験を繰り返す必要はありません。

使用パターンが妥当であると仮定すると、独自のバージョンのHashmapを使用することをお勧めします。

そのコードは、ハッシュの衝突を引き起こしにくくし、攻撃者がパフォーマンスの問題を引き起こすのを防ぐためにあります（詳細）-この問題がすでに他の方法で処理されていると仮定すると、同期はまったく必要ないと思います。ただし、同期を使用するかどうかは関係ありませんが、JDKが提供するものにそれほど依存しないように、独自のバージョンのHashmapを使用することをお勧めします。

したがって、通常は似たようなものを記述してそれを指すか、JDKのクラスをオーバーライドします。後者を行うには、ブートストラップクラスパスを-Xbootclasspath/p:パラメーターでオーバーライドできます。ただし、そうすると、「Java 2ランタイム環境のバイナリコードライセンスに違反する」ことになります（ソース）。