Java SE マルチスレッドのセキュリティ問題の原因は何ですか?

Question

おそらく、図のコードには負の数が含まれる可能性は低いですが、if ステートメントの後に Thread.sleep(10); を追加すると、負の数の出力が確認できます。

Answer 1

何を質問しているのかわかりません。複数のスレッドが同時にリソースを読み取り、同期が取れていない問題が発生するのは通常のことです。これは、1 つのスレッドが値を書き込んでいる間に、別のスレッドが値を取得している可能性があるためです。値が大きくなり、同期の問題が発生します。

解決策はたくさんありますが、最も愚かな方法は、コード ブロックに直接同期を追加してコード全体をロックすることです。AtomInteger 多くの場合、同期を確保するために、スレッド セーフなクラスを使用することです。マルチスレッドに関する研究の結果を踏まえると、いくつかのロックを追加するだけでも作業を完了できます。

Answer 2

スレッドの呼び出し順序は、順序どおりであることが保証されていません。その根本的な理由は、JVM がリソースを調整するときのスレッド間の切り替えにあります。

Answer 3

本質的な理由は、CPU が効率を向上させるために命令を並べ替えることです

Answer 4

num の同期はありません。現在のスレッドが num の値を変更した後、質問者が Java メモリ モデルをすぐに確認できるという保証はありません。
対象者のコードを例に挙げると、num=1が最後まで実行され、3つのスレッドが同時にif判定を実行し、すべて合格と判定できた場合、負の数が現れる可能性があります。

Answer 5

1. メモリの可視性
2. 変更の原子性

num は静的変数であるため、run() メソッドが実行されると、コピーがスタックにコピーされて保存されます。複数のスレッドがそれを変更すると、同じコピーが取得される可能性があります。同時に実行されますが、実行順序により、1 つのスレッドが変数を変更して書き込みますが、ヒープ内の num が変更されても、他のスレッドはそれを認識せず、そのコピーを変更し続けます。その後、変更がヒープに書き込まれ、前のスレッドの変更が上書きされ、状態の不整合が発生します。
それでは、スレッドの安全性が確保できたらどうなるでしょうか?次に、num を変更する前にヒープ領域の変更の可視性が保証されていることを確認し、変更する前にコピーを取得します (以前に取得されていた場合でも) これは volatile キーワードによって保証できます。

原子性、num-- の実際の実行は 2 つの操作であるため、実行順序の問題が発生します。可視性を確保するために volatile が使用されると前述しましたが。ただし、変更が他のスレッドによって上書きされる状況は依然として存在しますが、その可能性は低くなります。アトミック性を確保するには、synchronized キーワード、Lock メカニズム、JDK 同時実行ツールキットなどを使用できます。この状況に対する最も簡単な解決策は

リーリー