Goetz、Peierls、Bloch et al。 2006：実践でのJava並行処理このJava 64ビット数値可変マルチスレッドルールは、Java 1.8でも有効ですか、それとも古くなっていますか？
3.1.2。非単調64ビット操作
スレッドが同期なしで変数を読み取ると、無効な値が表示されることがありますが、少なくともランダムな値ではなくスレッドによって実際にそこに配置された値が表示されます。この安全性の保証は、薄いエアーアウトの安全と呼ばれています。
薄い空気の安全性は、揮発性と宣言されていない64ビット数値変数（第3.1.4項を参照）を除いて、すべての変数に適用されます。 Javaメモリモデルでは、フェッチおよびストア操作をアトミックにする必要がありますが、不揮発変数のlongおよびdouble変数の場合、JVMは64ビットの読み取りまたは書き込みを2つの別々の32ビット操作として扱うことができます。読み書きが異なるスレッドで発生すると、不揮発性のlong型を読み込み、ある値の上位32ビットと別の値の下位32ビットを取り戻すことができます。[3]
このように、無効な値を気にしなくても、volatileまたはlockで保護されていない限り、マルチスレッドプログラムで共有変数longおよびdouble変数を使用することは安全ではありません。
[3] Java仮想マシン仕様書が作成されたとき、多くの広く使用されているプロセッサーアーキテクチャーでは、効率的にアトミックな64ビット算術演算を行うことができませんでした。
これは2004年にリリースされたJava 5のリリース後に書かれました。多くの変更がマルチスレッド化と並行処理のプログラミングを容易にしました。だからなぜそれはまだ適用されますか？今でも10年後？
32ビットハードウェアでJavaアプリケーションを実行することができるだけであれば、必要に応じてJVMランタイムオプションを使用できないのはなぜですか？
このスレッドを気にせずにマルチスレッドおよび低遅延アプリケーションをコーディングできることは有益でしょうか？
ランタイムオプションの機能は何ですか？アトミックな64ビットメモリ操作をサポートするアーキテクチャでは、それらを有効にします（オプションをオフにする必要はありません）。私は、64ビットJDKを実行するとそのケースが予想されます。しかし、プログラマとして私はそれに依存したくないでしょう（そして、JLSは私たちが@ kordirkoの答えの引用符を見てはならないと言っているようです）。 – Thilo