「知っておく価値はあるが多くの人が知らないJavaに関する基本的なこと」と呼ばれる一連のトピックの続き。 前のトピック： 例だけでなく、バ​​イナリ互換性

Javaメモリモデルは、Java開発者のコ​​ードの動作に影響を与えるものです。 ただし、この重要なトピックの知識を無視する人がかなりおり、JMMデバイスの機能によって正確に説明される、アプリケーションの完全に予期しない動作に遭遇する場合があります。 たとえば、二重チェックロックパターンの非常に一般的で誤った実装を考えてみましょう。

public class Keeper { private Data data = null; public Data getData() { if(data == null) { synchronized(this) { if(data == null) { data = new Data(); } } } return data; } } 

このようなコードを記述する人々は、値が既に割り当てられている場合、ブロックを回避することによりパフォーマンスを改善しようとします。 残念ながら、これらの人々は多くの要因を考慮していないため、ゾンビの黙示録が発生する可能性があります。 カットの下で、私は理論を語り、何かがうまくいかない場合の例を挙げます。 さらに、あるインド映画で彼らが言ったように、「何が間違っているのかを知るだけでは不十分です。 その方法を知っておく必要があります。」 したがって、成功のためのレシピは、あなたもさらに見つけることができます。

ちょっとした歴史

JMMの最初のバージョンは、1995年にJava 1.0で登場しました。 これは、一貫性のあるクロスプラットフォームのメモリモデルを作成する最初の試みでした。 残念ながら、または幸いなことに、いくつかの重大な欠陥と誤解がありました。 最も悲しい問題の1つは、最終フィールドの保証がないことでした。 つまり、1つのスレッドが最終フィールドを持つオブジェクトを作成し、別のスレッドがこの最終フィールドの値を表示しない場合があります。 java.lang.Stringクラスでさえこれにさらされていました。 さらに、このモデルではコンパイラーが多くの効果的な最適化を行うことができなかったため、マルチスレッドコードを記述するときに、期待どおりに機能するかどうかを確認することは困難でした。

そのため、2004年にJSR 133がJava 5に登場し、元のモデルの欠点がなくなりました。 何が起こったのかについて話します。

原子性

多くの人がこれを知っていますが、一部のプラットフォームでは記録操作が非アトミックになることがあることを思い出す必要があると思います。 つまり、あるスレッドが値を記録している間に、別のスレッドが何らかの中間状態を見る場合があります。 例えば、同じlongとdoubleのレコードは、揮発性として宣言されていない場合、アトミックである必要はなく、多くのプラットフォームで2つの操作で書き込まれます。最上位ビットと下位32ビットは別々です。 （ 標準を参照）

可視性

古いJMMでは、実行中の各スレッドに独自のキャッシュ（作業メモリ）があり、このスレッドが操作したオブジェクトの状態が保存されていました。 いくつかの条件下では、キャッシュはメインメモリと同期しましたが、それでも、かなりの時間、メインメモリとキャッシュの値が異なる可能性がありました。

新しいメモリモデルでは、値が格納されている正確な場所に誰も関心がないため、このような概念は放棄されました。 唯一の重要なことは、あるスレッドが別のスレッドによって行われた変更をどのような条件下で見るかということです 。 さらに、ハードウェアは既にキャッシュされ、レジスタに配置され、他の操作を実行するのに十分なほどスマートです。

同じC ++とは異なり、「空気の外」の値は決して取られないことに注意することが重要です。どの変数についても、ストリームによって監視された値がそれに割り当てられたか、値デフォルトで。

再注文

しかし、これは彼らが言うように、すべてではありません。 今すぐ注文すると、指示が無料で交換されます！ プロセッサは、命令実行の最適化において非常に機敏です。 コンパイラとJITもこれに役立ちます。 注目すべき効果の1つは、1つのスレッドによって実行されるアクションと、他のスレッドが異なる順序で表示されることです。 このフレーズは理解するのが非常に難しく、読むだけなので、例を挙げます。 そのようなコードがあります：

 public class ReorderingSample { boolean first = false; boolean second = false; void setValues() { first = true; second = true; } void checkValues() { while(!second); assert first; } } 

このコードでは、 checkValuesメソッドは1つのスレッドから呼び出され、 checkValuesは別のスレッドから呼び出されます。 secondフィールドはfirstフィールドよりも後にtrueに設定されるため、コードは問題なく実行されるはずです。したがって、（より正確には）2番目のフィールドがtrueであることがわかると、最初のフィールドもそのようになります。 しかし、そこにありました。

マルチスレッド環境では、シングルスレッド内でこのことを心配する必要はありませんが、他のスレッドによって実行された操作の結果は正しい順序ではない場合があります。 根拠がないように、マシンでアサーションを機能させたかったのですが、あまり成功しませんでした（ いいえ、起動時に-eaスイッチを指定することを忘れていませんでした ）、そして必死に、悪名高いパフォーマンスエンジニアに、まだ順序変更を引き起こしています。 それで、セルゲイ・ククセンコは私の質問に答えました：

TSO（x86が適用される）を搭載したマシンでは、表示が非常に困難です
並べ替えを壊します。 これはいくつかのARM'eまたは
PowerPC また、アルファを参照することもできます-最も弱い順序規則を持つプロセッサ。 アルファは、コンパイラとオペレーティングシステムカーネルの開発者にとって悪夢でした。 彼が死んだのは幸運です。 ネット上でそれに関するたくさんの物語を見つけることができます。

古典的な例：
（例は上記に似ています-著者のコメント）
... x86では、常に正しく動作します。
「b」に保存すると、「a」に表示および保存されます。

そして、記事で検討されているすべての側面について、実際に起こっていることの実演デモを見つけたいと言ったとき、セルゲイは喜んで、対応するハードウェアのマニュアルを長く苦労して読む必要があると言いました。 しばらくの間、電話で効果を達成しようと考えていましたが、最終的にはそれほど重要ではないと判断しました。 さらに、私はまだ特定のプラットフォームの機能に特化していません。

したがって、元の例に戻って、並べ替えがそれを台無しにする可能性があることを理解してください。 コンストラクターのDataクラスで、それほど重要ではない計算を実行し、最も重要なこととして、 非最終フィールドにいくつかの値を書き込みます。

 public class Data { String question; int answer; int maxAllowedValue; public Data() { this.answer = 42; this.question = reverseEngineer(this.answer); this.maxAllowedValue = 9000; } } 

data == nullを最初に検出したスレッドは次のことを行うことがdata == null 。

1. 新しいオブジェクトにメモリを割り当てます
2. DataクラスのコンストラクターがData
3. Dataクラスのanswerフィールドに42を書き込みます
4. クラスData questionフィールドにいくつかの行を書き込みData
5. 値9000をDataクラスのmaxAllowedValueフィールドに書き込みます
6. 新しく作成されたオブジェクトをKeeperクラスのdataフィールドに書き込みます

キャッチを感じますか？ 節3〜5で何が起こったのかを見る前に、別のスレッドが節6で何が起こったのかを見ることを妨げるものは何もありません。 その結果、フィールドがまだ設定されていない場合、このスレッドはオブジェクトを誤った状態で見ることになります。 もちろん、これは誰にも適していないため、オプティマイザー/コンパイラー/悪のダブルが並べ替えを実行することを禁止する厳しいルールがあります。

前に起こる

定義

これらのルールはすべて、いわゆる発生前関係を使用して定義されます。 次のように定義されます。

ストリームXとストリームYがあるとします（必ずしもストリームXと異なるわけではありません）。 そして、操作A （スレッドXで実行）とB （スレッドYで実行）があるとします。

この場合、 AはBの前に発生 します。これは、操作Aの瞬間の前にスレッドXによって行われたすべての変更と、この操作によって引き起こされた変更が、操作Bの実行の瞬間とこの操作の実行後にスレッドYに見えることを意味します。

言葉で言えば、そのような定義はあまりよく認識されないかもしれないので、少し説明します。 ストリームが1つだけである、つまりXとYが同じである最も単純なケースから始めましょう。 すでに述べたように、1つのスレッド内では、ソースコードで示されている順序（プログラムの順序）に従って操作が相互に関連して発生するため、問題はありません。 マルチスレッドの場合、すべてがやや複雑になりますが、ここでは...画像が理解できません。 そしてここに彼女は：


ここでは、左側で、ストリームYが表示されることが保証されている操作が緑色でマークされ、表示されない可能性がある操作が赤色でマークされています。 右側では、これらの操作は赤でマークされ、その実行中、左の緑の操作の結果はまだ表示されない場合があり、緑ではすべてが表示される場合があります。 happen-before関係は推移的であることに注意することが重要です。つまり、A が B の前に発生し 、B が Cの前に発生する場合 、A は Cの前に発生します 。

発生前の関係に関連する操作

次に、JMMでの並べ替えの制限事項を正確に見てみましょう。 深く詳細な説明は、例えばThe JSR-133 Cookbookにありますが、私はすべてを少し表面的なレベルにし、おそらくいくつかの制限を見逃します。 最も単純で最も有名なロックから始めましょう。

1.モニターの解放は、同じモニターを取得する 前に発生します。 注：出口ではなくリリースです。つまり、 waitを使用する場合、セキュリティについて心配する必要はありません。

この知識が私たちの例を修正するのにどのように役立つか見てみましょう。 この場合、すべてが非常に簡単です。外部チェックを削除し、同期をそのままにしておきます。 これで、2番目のスレッドは、他のスレッドがモニターを解放した後にのみモニターを受け取るため、すべての変更を確認することが保証されます。 そして、彼はすべてが初期化されるまで彼を手放さないので、個別にではなく、すべての変更を一度に見ることができます：

 public class Keeper { private Data data = null; public Data getData() { synchronized(this) { if(data == null) { data = new Data(); } } return data; } } 

2. volatile変数への書き込みは、同じ変数から読み取る前に行われます。

もちろん、私たちが行った変更は不正確さを修正しますが、元のコードを書いた人を元のコード-毎回ロックに戻します。 volatileキーワードは保存できます。 実際、検討中のステートメント（2）は、volatileと宣言されたすべてを読み取るときに、常に現在の値を取得することを意味します。 さらに、前述したように、揮発性フィールドの場合、書き込みは常に（longおよびdoubleを含む）アトミック操作です。 別の重要な点：他のエンティティ（たとえば、配列、リスト、または他のクラス）への参照を持つ揮発性エンティティがある場合、すべてではなく、エンティティ自体への参照のみが常に「新鮮」になります着信。

それでは、ダブルロックラムに戻りましょう。 volatileを使用すると、次のような状況を修正できます。

 public class Keeper { private volatile Data data = null; public Data getData() { if(data == null) { synchronized(this) { if(data == null) { data = new Data(); } } } return data; } } 

ここではまだdata == null場合にのみロックがありdata == null 。 残りのケースでは、volatile読み取りを使用して除外します。 揮発性ストアが揮発性読み取りの前に発生し、コンストラクターで発生するすべての操作がフィールドの値を読み取るユーザーに表示されるという事実によって、正確さが保証されます。

さらに、ここでは興味深い仮定が使用されており、確認する価値があります。揮発性ストア+読み取りはロックよりも高速です。 ただし、同じパフォーマンスエンジニアが絶え間なく私たちに繰り返しているように、マイクロベンチマークは現実とはほとんど関係がありません。特に、測定しようとしている仕組みがわからない場合はそうです。 さらに、あなたがそれがどのように機能するかを知っていると思うなら、あなたは間違いである可能性が高く、重要な要素を考慮に入れていません。 ベンチマークを作成するための知識の深さには十分な自信がないので、ここではそのような測定値はありません。 ただし、このプレゼンテーションには 、スライド＃54から始まる揮発性のパフォーマンスに関する情報があります（ただし、すべてを読むことを強くお勧めします）。 UPD：設計上、volatileよりもvolatileよりもはるかに速いという興味深いコメントがあります。

3. finalフィールドに値を書き込む（および、このフィールドがリンクの場合、このフィールドから到達可能なすべての変数（参照チェーン））を発生前オブジェクトの作成時に、外部で発生する変数にこのオブジェクトを書き込むこのコンストラクタ。

これもかなりわかりにくいですが、本質は単純です： finalフィールドを持つオブジェクトがある場合、このオブジェクトはこのfinalフィールド（およびこのフィールドが参照できるすべて）を設定した後にのみ使用できます。 ただし、コンストラクターから外部の構築されたオブジェクト（つまりthis ）へのリンクを渡すと、誰かがあなたのオブジェクトを未完成の状態で見る可能性があることを忘れないでください。

この例では、フィールド、最後のレコード、 finalを作成するだけで十分であることがわかります。

 public class Data { String question; int answer; final int maxAllowedValue; public Data() { this.answer = 42; this.question = reverseEngineer(this.answer); this.maxAllowedValue = 9000; } private String reverseEngineer(int answer) { return null; } } 

唯一のポイントは、魔法のように機能することであり、あなたの独創的なレセプションを知らない人はあなたを理解できないかもしれません。 はい、あなたもこれをすぐに忘れることができます。 もちろん、ここで何が起こっているのかを説明する「こっちのトリック！」などの誇らしいコメントを追加するオプションもありますが、何らかの理由でこれはあまり良い習慣ではないようです。

UPD：これは事実ではありません。 コメントは理由を説明します。 UPD2 ：問題の議論に続いて、Ruslanは記事を書きました 。

さらに、フィールドも静的であり、JVMクラスは最初の呼び出しで1回だけ初期化を実行することが保証されていることを覚えておくことが重要です。 この場合、同じシングルトン（ この記事のフレームワーク内でパターンまたはアンチパターンとも呼ばれません。この記事ではまったく説明しません。 ）を次のように実装できます。

 public class Singleton { private Singleton() {} private static class InstanceContainer { private static final Singleton instance = new Singleton(); } public Singleton getInstance() { return InstanceContainer.instance; } } 

もちろん、これはシングルトンを実装する方法についてのアドバイスではありません。EffectiveJavaを読む人は誰でも、何らかの理由で突然何らかの理由でそれを書くことに決めた場合、enumを使用し、マルチスレッド、シリアル化、およびクローニングに関するすべての問題の解決策を示しています。 UPD：シングルトンの最適な実装方法については、 このトピックを参照してください。

ところで、Reflectionを使用して最終フィールドを変更できることを知っている人、およびそのような変更がどのように表示されるかに興味がある人にとって、私はこう言うことができます。「すべてがうまくいくように見えます。なぜか、すべてが本当にあるかどうかは不明です。いいです。」 このトピックにはいくつかのトピックがありますが、これは最もインターンです。 コメントで誰かがそれが実際にどのようになっているのかを教えてくれるなら、私は非常に幸せです。 しかし、誰も言わない場合、私自身が見つけて、確実に伝えるでしょう。 UPD ：彼らはコメントで言った。

確かに、この記事では取り上げなかった発生前の関係に関連する他の操作がいくつかありますが、それらは既により具体的であり、興味がある場合は、 標準または他の場所で自分自身を見つけて共有することができますコメントの全員。

クレジット、リンク、およびもの

まず、前述のパフォーマンスエンジニアであるAlexei TheShade ShipilevとSergey Walrus Kuksenkoの臨床的なナンセンスの内容に関する記事のいくつかの協議と予備検証に感謝します。

また、記事の執筆時に使用したソースのリストと、トピックに関する適切なリンクも示します。

• Doug Leaによるコンパイラライター向けJSR-133クックブック
• Sergey KuksenkoによるJavaメモリモデルに関する講演のスライド
• 第17章 Java言語仕様のスレッドとロック
• Artem DanilovによるJavaメモリモデルの概要
• 実際のJava並行性

コメントに興味深い質問、追加、修正を残してください。読んで答えてうれしいです。