問題タブ [jls]

次のクラスがあるとします。

また、同じインスタンスで同時にmethod1()複数のスレッドを呼び出す場合、method1（）を呼び出すと1以外のものが返される可能性がありますか？method2()Foo

この見苦しいコードはコンパイルされますが、次の場合に NPE がスローされます。s == null

これはそうではありませんが（予想どおり）：

どちらも明らかに間違っていることはわかっていますが、ソースで最初のコードを見つけたとき、それがコンパイルされたことに非常に驚きました。

編集: Java 7 の JLS の関連部分は次のとおりです。最初のステートメントが適用されると思いましたが、太字のステートメントが適用されます。

15.25 条件演算子 ? :

[...]

条件式のタイプは、次のように決定されます。

[...]

• 2 番目と 3 番目のオペランドの一方がプリミティブ型 T で、もう一方の型が T にボックス化変換 (§5.1.7) を適用した結果である場合、条件式の型は T です。

[...]

• それ以外の場合、2 番目と 3 番目のオペランドの型はそれぞれ S1 と S2 です。T1 を S1 にボックス化変換を適用した結果の型とし、T2 を S2 にボックス化変換を適用した結果の型とする。条件式の型は、キャプチャ変換 (§5.1.10) を lub(T1, T2) (§15.12.2.7) に適用した結果です。

最近の講演で、volatile への書き込みは、スレッドが書き込みを行った変数ごとにメモリ バリアをトリガーするという話を聞きました。それは本当に正しいですか？JLS からは、関連する変数のみがフラッシュされ、他の変数はフラッシュされないようです。実際に何が正しいのか誰か知っていますか？JLSの具体的な場所を教えてもらえますか?

以下に示すエラーで失敗するのはなぜですか? このようなことを行うための制限をJLSのどこで探すべきかわかりません。

コンパイル時のエラー

Java言語仕様（例17.4-1）によると、次のスニペット（で始まるA == B == 0）...

...結果としてr2 == 2とになる可能性がありr1 == 1ます。これは、実行の結果が実行B = 1;されたかどうかに依存しないr2 = Aため、JVMはこれら2つの命令の実行順序を自由に入れ替えることができるためです。つまり、仕様では次のインターリーブが許可されています。

これは明らかにとにr2 == 1なりr1 == 1ます。

私の質問：

例を少し微調整するとします。

ここobjで、はスレッド間で共有される参照です。

の並べ替えは引き続き許可されますかr2 = A？B = 1

JLSは言う...

ただし、コンパイラーは、どちらかのスレッドの命令を並べ替えることができます。これが、そのスレッドの単独での実行に影響を与えない場合です。

...これは、命令がまだスワップされている可能性があることを示しています。一方、次のステートメント

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

特定のスケジューリングでは、2つのスレッドのステートメント間に発生前の関係がある可能性があることを示します。これにより、おそらく命令の並べ替えが許可されなくなります。

次のコードは、Windows 7 x86 jdk 7 (-ea をオン)で volatile の JLS の例に従って AssertionError をスローすべきではありませんか?

Java 言語仕様 7 (JLS7-17.4.5) では、「正しく同期された」プログラムを次のように定義しています。

JLS7-17.4.5 には、次のようにも記載されています。

正しく同期しないと、非常に奇妙で、混乱を招き、直感に反する動作が発生する可能性があります。

したがって、プログラマーの観点からは、プログラムが上記の定義に従って「正しく同期されている」かどうかを判断するツールがあれば非常に便利です。

そのようなツールはありますか？グーグルで検索しても何も見つかりませんでした。そのようなツールがない場合、作成することは可能でしょうか?

JLS 8.3.2.3を実行したとき、次のコードを理解できませんでした。

コードの結果、エラーが発生しますCannot reference a field before it is defined

しかし、コードを次のように変更すると

コードがコンパイルされています。ただし、どちらの場合も、変数定義は初期化ブロックの後にあります。この背後にある謎は何ですか？

重複の可能性:
なぜエラーが発生するのですか?

以下の 3 つのメソッドはまったく同じことを行い、明らかに true を返します。

ただし、最初の 2 つはコンパイルされますが、3 つ目はコンパイルされません (「return ステートメントがありません」)。

言語仕様のどの部分がその動作を規定していますか?

このオブジェクトのコンストラクターが終了する前に、オブジェクトへの参照が値を受け取ることがあるJMMのこの機能については、誰もが知っています。

JLS7では、p 。17.5最終的なフィールド セマンティクスも読むことができます。

フィールドの使用モデルfinalは単純finalです。オブジェクトのコンストラクターでオブジェクトのフィールドを設定します。オブジェクトのコンストラクターが終了する前に、別のスレッドが参照できる場所に構築中のオブジェクトへの参照を書き込まないでください。これに従った場合、オブジェクトが別のスレッドによって認識されると、そのスレッドは常に、そのオブジェクトのfinalフィールドの正しく構築されたバージョンを認識します。(1)

そして、その直後に JLS の例が続きます。これは、non-finalフィールドがどのように初期化されることが保証されていないかを示しています (1Example 17.5-1.1) (2):

また、この質疑応答でグレイ氏は次のように書いています。

フィールドを としてマークするとfinal、コンストラクターはコンストラクターの一部として初期化を完了することが保証されます。それ以外の場合は、ロックを使用する前にロックを同期する必要があります。(3)

したがって、質問は次のとおりです。

1) ステートメント (1) によると、コンストラクターが終了する前に不変オブジェクトへの参照を共有することは避けるべきです

2) JLS の例 (2) と結論 (3) によると、不変オブジェクトのコンストラクターが終了する前、つまりすべてのフィールドがfinal.

何か矛盾していませんか？

EDIT-1 : 私が正確に言いたいこと。そのような方法で例のクラスを変更すると、そのフィールドyもfinal(2) になります。

したがって、reader()メソッドでは、次のことが保証されます。

fもしそうなら、コンストラクターが終了する前に ((1) に従って)オブジェクトへの参照を書き込むことを避ける必要があるのはなぜfですか?