問題タブ [java-memory-model]

怠惰なインスタンス化されたシングルトンパターンを使用していくつかの問題に遭遇しました

参照：http ：//www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html 。

同様に、初期のインスタンス化されたシングルトンパターンの使用に問題はありますか？

JSR-133仕様を読み直していたとき、Java 7 リリースで何か変更があったのではないかと思いました。つまり、133 が廃止されたか、まだ有効な場合です。

Java 7 のメモリ モデルの変更については Google で何も見つかりませんでしたが、誰かが知っている場合に備えてここで質問しています。

「Java Concurrency in Practice」では、Java メモリ モデルの性質により、永久に実行されるか、0 を出力する可能性がある安全でないクラスの例を次に示します。

このクラスが実証しようとしている問題は、ここの変数がスレッド間で「共有」されていないことです。そのため、スレッドが参照する値は、揮発性または同期化されていないため、別のスレッドとは異なる場合があります。また、JVM によって許可されるステートメントの並べ替えにより、ready=true が number=42 より前に設定される場合があります。

私にとって、このクラスは常に JVM 1.6 を使用して正常に動作します。このクラスが正しくない動作を実行する方法 (つまり、0 を出力するか、永久に実行する) に関するアイデアはありますか?

Java7のForkJoinPoolクラスには、次のような実装に関するコメントがあります。

メソッド signalWork() と scan() は主なボトルネックであるため、特に大幅にマイクロ最適化/マングルされています。多くのインライン割り当て("while ((local = field) != 0)" の形式) があり、これらは通常、必要な読み取り順序を確保する最も簡単な方法です (これは重要な場合もあります)。

私の質問は次のとおりです:インライン割り当ては読み取り順序にどのように役立ちますか(私はJavaメモリモデルに精通しており、インライン割り当てがここでどのように役立つかわかりません)?

序文: ほとんどの場合、揮発性フィールドを使用しても測定可能なパフォーマンス ペナルティが発生しないことはわかっていますが、この質問はより理論的であり、非常に高い相関性をサポートする設計を対象としています。

List<Something>構築後に埋められるフィールドがあります。パフォーマンスを節約するために、リストを読み取り専用のマップに変換したいと思います。これを行うには、少なくとも volatile Map フィールドが必要になるため、すべてのスレッドで変更が表示されるようにします。

私は次のことを考えていました：

これにより、シリアライズされた方法で get ブロックに入ったとしても、複数のスレッドがマップを生成する可能性があります。スレッドがマップの異なる同一インスタンスで動作する場合、これは大きな問題にはなりません。もっと気になるのは：

1 つのスレッドが新しい一時マップをマップ フィールドに割り当て、次に 2 番目のスレッドがそれを確認してmap!=null、新しいマップ フィールドを生成せずにマップ フィールドにアクセスすることは可能ですか?まだ共有メモリ領域にプッシュされていない場所はどこですか?

コメントへの回答:

• スレッドは一時マップのみを変更し、その後は読み取り専用になります。
• List を Map に変換する必要があるのは、特別な JAXB セットアップが原因で、最初から Map を持つことが実現できないためです。

JAXBはゼロ引数コンストラクターを呼び出してから、不揮発性フィールドへの入力を開始し、リストにデータを追加すると思います。

私自身のコードでは：これ（アンマーシャリング）を行った直後に、生成されたBeanは、いくつかのaddメソッドを介して一部のワーカースレッドに強制送還されますが、コンストラクターや、メモリモデルがデータをフラッシュして再フェッチするトリガーとなるその他の方法を介してではありません。共有エリアから。

これは安全ですか？それとも、JAXBは舞台裏で魔法のトリックをしますか？すべてのスレッドにすべてが表示されるように強制できるJavaプログラミング言語の方法は考えられません。JAXBで生成されたBeanのユーザーは、並行セットアップでフィールドが目に見えて設定されていない可能性があることを心配する必要がありますか？

編集：なぜこれほど多くの反対票があるのですか？JAXBがこの一見不可能なタスクをどのように保証するかをまだ誰も説明できませんでした。

構成、依存性注入などを必要とするクラスがあるとしましょう。

これは不自然な例ですが、ctorですべての構成を簡単に実行できない場合はどうなりますか？構成が実行の早い段階で行われ、変更されないとします。厳密に言えば、メモリモデルのために、someConfigへのすべての参照を同期する必要があります。この要件を実際に緩和することはできますか？

単一変数の前に起こった関係を理解し​​ていると思います。揮発性フィールドを書き込むと、このフィールドの後続のすべての読み取りにこの新しい値が含まれます。クロスを書き込むvolatileと、メモリバリアを越えて、新しい値がメインメモリにフラッシュされます。

Thread.start()他のすべての場合、たとえば、synchronizedまたはの新しいロックで何が起こるかについては、まだはっきりしていませんjava.util.concurrent。それらがメモリバリアも越えるとはどういう意味ですか？どのデータがローカルキャッシュからメインメモリにフラッシュされますか？言い換えれば、交差点の範囲は何ですか？

すべてが常にフラッシュされますか？さて、に戻って、それは単一のフィールドvolatile以上のものをフラッシュしますか？volatile

12MB のキャッシュを備えた 6 コアのマシンがあるとします。数ギガバイトのヒープを持つサーバー アプリケーションに使用します (その多くは第 2 レベルの Hibernate キャッシュです)。

ほとんどの場合、少数のスレッドがアクティブにクライアント リクエストを処理している (CPU を焼き尽くして DB と通信している) だけでなく、クライアントとの古い同期ネットワーク IO のみを実行している約 30 ～ 50 のスレッドがあることに気付きました。

Java メモリ モデルについて学習しているので、これがパフォーマンスに影響を与える可能性があるかどうか疑問に思っています。多くのネットワーク IO スレッドの 1 つのコンテキスト切り替えは、「アクティブな」スレッドのスレッド/CPU キャッシュを台無しにしますか? このレベルの同時実行性自体は有害ですか (メモリ キャッシュは別として)?

アプリケーションメモリ全体に対してCPUキャッシュがどれほど小さいかを考えると、それは本当に重要ですか? 境界がどこにあるかをどのように判断できますか?

Javaメモリモデルによる「効果的に不変のオブジェクト」の動作を正しく理解していることを確認したいと思います。

事実上不変として公開したい可変クラスがあるとしましょう。

次のことを行います。

問題は次のとおりです。Javaメモリモデルは、すべてのスレッドが持っている必要があることを保証しますOutworld.published.get() == 3か？

Java Concurrency In Practiceによると、これは正しいはずですが、間違っている場合は訂正してください。

3.5.3。安全な出版イディオム

オブジェクトを安全に公開するには、オブジェクトへの参照とオブジェクトの状態の両方を同時に他のスレッドに表示する必要があります。適切に構築されたオブジェクトは、次の方法で安全に公開できます。-
静的初期化子からオブジェクト参照を初期化する。
-それへの参照を揮発性フィールドまたはAtomicReferenceに保存します。
-それへの参照を適切に構築されたオブジェクトの最終フィールドに格納します。または
-ロックによって適切に保護されているフィールドに参照を保存します。

3.5.4。効果的に不変のオブジェクト

安全に公開された効果的に不変のオブジェクトは、追加の同期なしで任意のスレッドで安全に使用できます。