Javaの変数がデフォルトで揮発性でないのはなぜですか？

Question

おそらく同様の質問：

Do you ever use the volatile keyword in Java?

---

今日、私は私のゲームをデバッグました。数分ごとに表示される非常に困難なスレッド問題がありましたが、再現するのは難しかったです。最初に私の方法のそれぞれに​​キーワードを追加しました。それはうまくいかなかった。その後、すべてのフィールドに volatileというキーワードを追加しました。問題はちょうどそれ自身を修正するようだった。

いくつかの実験の後、担当するフィールドがゲームの現在の状態（再生中またはビジー状態のいずれか）を記録したGameStateオブジェクトであることがわかりました。ビジー状態のとき、ゲームはユーザーの入力を無視します。私が持っていたのは、常にstateという変数を変更したスレッドでしたが、イベントスレッドはstateという変数を読み取りました。しかし、あるスレッドが変数を変更した後、他のスレッドが変更を認識するまで数秒かかるため、最終的に問題が発生します。

状態変数volatileを作成することで修正されました。

Javaの変数がデフォルトでvolatileでないのはなぜですか？また、volatileキーワードを使用しない理由は何ですか？

Answer 1

長い話を簡単にするために、JavaやC＃のような揮発性変数は決してスレッド内でローカルにキャッシュされません。これは、異なるキャッシュで実行されているスレッドを持つマルチプロセッサ/マルチコアCPUを扱っていない限り、同じキャッシュを探している場合を除き、意味がありません。変数をvolatileとして宣言すると、すべての読み書きが実際のメインメモリ位置からまっすぐに進みます。キャッシュは含まれていません。これは最適化に際して意味があり、不必要に（ほとんどの変数が揮発性である必要がない場合）、比較的小さな利益のためにパフォーマンス上のペナルティがかかります。

Answer 2

コンパイラは揮発性変数を最適化できないためです。

volatileは、変数がいつでも変更できることをコンパイラに伝えます。したがって、変数がそれに応じて変更および最適化されないと想定することはできません。

Answer 3

変数をvolatile宣言すると、一般にパフォーマンスに大きな影響があります。従来のシングルスレッドシステムでは、何が揮発性である必要があるかを比較的簡単に知ることができました。それはハードウェアにアクセスするものでした。

マルチスレッドの場合はもう少し複雑になる可能性がありますが、一般的には、通知とイベントキューを使用して、マジック変数を使ってデータを渡すことをお勧めします。 Javaではそれほど重要ではないかもしれません。 C/C++では、基礎となるハードウェアによってこれらの変数をアトミックに設定できない場合、問題が発生します。

Answer 4

他の人がvolatileにデフォルトするのが悪い理由を指摘するのは間違いありませんが、別の点もあります。コードにバグがありそうです。 変数は揮発性にする必要はほとんどありません。同期されたキーワード、またはjava.util.concurrencyのAtomicXxxオブジェクトを使用して、変数へのアクセスを適切に同期する方法は常にあります。例外には、これらを操作するJNIコードが含まれます（同期ディレクティブ）。

volatileを追加する代わりに、問題が解決された理由を把握したい場合があります。それを解決するのは唯一の方法ではなく、おそらくもっと良い方法があります。

Answer 5

実際には、低レベルのスレッドセーフ、ロックフリーのコードを作成しようとしているときにのみ揮発性物質が必要です。ほとんどのコードはであるべきではありません。スレッドセーフまたはロックフリーです。私の経験上、ロックフリープログラミングは、ロックのために重要なパフォーマンスヒットが発生するを行うより単純なバージョンであることが判明した後で試してみる価値があります。

java.util.concurrentには他のビルディングブロックを使用することをお勧めしますが、その中にはロックフリーのものもありますが、低レベルですべて自分自身でやっているように頭を悩ますものではありません。

ボラティリティには独自のパフォーマンスコストがあり、のほとんどのコードではコードにこれらのコストが発生する必要はありません。

Answer 6

個人的に私は、フィールドはデフォルトでは最後になり、余分なキーワードでしか変更できないはずだと思っていますが、そのボートは時間の経過とともに航海しています。 ;）