問題タブ [happens-before]

Java の事前発生規則を説明するコード セグメントを含む「JVM の高度な機能とベスト プラクティスについて」を読んでいます。私は理解できない。コードは以下のとおりです。

スレッドがコード内のAスレッドの前に開始するとBします。getValue()スレッド セーフではないため、スレッド B で返される結果がわからないことは理解できます。しかし、この本は、同期キーワードを関数setValue()とgetValue()に追加すると、スレッドセーフの問題は存在せず、メソッドgetValue()は正しい値を返すと述べています。この本は、なぜならそれsynchronizedは事前発生規則に適合していると説明しています。したがって、以下のコードで2つの質問があります。

1. A.start()run beforeB.start()で value は ですが、volatileスレッド B が を出力できるかどうかは保証できません10よね? スレッド B は JVM によって最初にスケジュールされる可能性があるため、スレッド B は 10 ではなく 0 を出力します。
2. JVM によってスレッドのA前にスレッドがスケジュールされたとしても、JVM は命令を再度ソートするため、JVMによって以前に実行されBた命令を保証することはできません。私の理解は正しいですか？私を助けてください。this.value = valuereturn this.value

回答、コメント、およびjls-17.4.2を見た後の受け入れ可能な回答

1）反対称プロパティは、次のように保持されます-user3707125

2) ロック間の hb 関係は、実際にはロック解除とロック hb(ul, l) の間であり、hb(l, ul) とは異なります。ヒントは - shmosel
From JSL -

モニターのロック解除は、そのモニターの後続のすべてのロックの前に発生します。

3) ジェームス・ラージによる hb の合理的な説明

実際の質問は次のとおりです。

Java メモリ モデル (JMM) の記述は、いくつかのアクション間の関係の前に発生します。"x" と "y" が h(x,y) 関係を持つ 2 つのアクションの場合。JMM はまた、実装 (コンパイラ、ランタイム、またはハードウェア) は、「x」と「y」を順番に実行した場合と同じ結果を達成する場合、これらの実行を自由に並べ替えることができると述べています。

だから私は思う、

私は正しいですか？それとも私は何かを逃しましたか？

更新:
ロックを伴うアクションについても、hb 関係を確立する方法を教えてください。異なるスレッドによるロックのイベントはプログラムの順序で定義できず、決定論的ではなく、命令やスケジューラなどのいくつかの要因に依存するため、
2 つのロック アクション - l1 と l2 の間で関係を定義する方法 hb(l1 , l2) または hb(l2, l1)。どちらも受け入れられるようです。この場合、どちらも同じように見えます。
l1 と l2 は、同じオブジェクトに対するロック アクションです。 l1 と l2 はロックではありません

明確化（コメントに基づく）：異なるスレッドによって同じオブジェクトに対してロックが行われる場合、ロックアクションは明らかに相互に排他的です。

A と B の 2 つのノードしかないとします。

ノード A でこれら 2 つのコマンドを発行すると、

(つまり PUT one key1 、前発生 PUT two key2)が返された場合GET、/v1/kv/key2ノード B で返さtwoれることが保証されGETます/v1/kv/key1かone? つまり、Consul KVS は、ノード A 上の 2 つの書き込み間の事前発生関係を尊重しますか?

• https://www.consul.io/docs/internals/consensus.html

Consul はコンセンサス プロトコルを使用して一貫性を提供します (CAP で定義)。

ええ、しかし私の理解では、CAP定理は複数のレジスタについて話していません。これら 2 つの書き込みは最終的にノード B に伝播する可能性がありますが、予期しない中間状態が発生しないことが保証されていますか?

知られているように、オブジェクト参照があり、この参照に最終フィールドがある場合、最終フィールドから到達可能なすべてのフィールドが表示されます（少なくともコンストラクターが終了したとき）

例 1:

この場合、次の理由により、メソッドが常に出力されることが保証されていますbar()。1 .クラスの完全なコードをリストし、マップは最終です。2. 一部のスレッドが参照を参照し、この参照が != null である場合、最終参照値から到達可能であることが保証されます。object
Foo
Foomap

私もそう思います

例 2:

bar()ここでは、メソッドについて同じ保証がありますが、割り当ての前に割り当てが発生してもbar2スローでき ます。NullPointerExceptionnonFinalMapmap

揮発性について知りたい：

例 3:

私が理解しているように、bar()メソッドはスローできませんNullPoinerExceptionが、印刷できますnull。（私はこの点について完全に確信が持てません）

例 4:

ここでは、割り当てがより高い揮発性のマップ割り当てを記述したため、bar()メソッドもbar2()スローできないという同じ保証があると思いますが、nullを出力できますNullPointerExceptionnonVolatileMap

エリオット・フリッシュのコメントの後に追加

レースの例による出版：

コード スニペットに対する私のコメントを証明または修正してください。