問題タブ [java-memory-model]

同期ブロック内のコードが「happensbefore」セマンティクスに準拠していることを読みました。これにより、同期ブロック内に書き込まれたすべての値が他のスレッドに連続して表示されるようになります。さらに、キャッシュは同期ブロックの終了時にのみフラッシュされることを読みました。同期されたブロックの終了でキャッシュのみがフラッシュされる場合、以下で説明するシナリオでは、上記の「発生前」のセマンティクスはどのように適用されますか？

スレッドAはオブジェクトCへの参照を持ち、Cで同期された同期コードのCのフィールドを変更します。スレッドBもオブジェクトCへの参照を取得しました。これで、同期コードが終了する前にスレッドAが一時停止されます。スレッドBはアクションにジャンプし、Cで同期せずに、コード内のオブジェクトCのフィールドにアクセスします。

これで、スレッドBはスレッドAによって行われた変更を確認できることが保証されますか？

java.util.concurrentクラスのいずれかを使用する場合でも、異なるスレッド間の可視性の問題を回避するために、インスタンスのアクセスを同期する必要がありますか？

質問をもう少し詳しく説明します

java.util.concurrentのインスタンスを使用する場合、1つのスレッドがインスタンスを変更し（つまり、要素を並行ハッシュマップに配置し）、後続のスレッドが変更を認識しない可能性はありますか？

私の質問は、値へのアクセスが同期されていない場合、Javaメモリモデルでは、スレッドがメモリから直接値をフェッチするのではなく、値をキャッシュできるという事実から生じます。

Dalvik のメモリ モデルはJavaのメモリ モデルと同じですか? long参照変数と非プリミティブ変数の読み取りと書き込みがアトミックかどうかに特に関心がありますdoubleが、2 つのプラットフォームのメモリ モデルに違いがあるかどうかも知りたいです。

プロジェクトの 1 つで使用volatileして、異なるスレッドからアクセスされる変数の同じコピーを維持します。volatile私の質問は、 で使用しても大丈夫かどうかですstatic。コンパイラはエラーを出しませんが、両方を使用する理由がわかりません。

このクラスがスレッドセーフかどうか教えてもらえますか?

編集：質問を明確にしないのは私のせいです。JMM FAQによると:

初期化の安全性を新たに保証する必要があります。オブジェクトが適切に構築されている場合 (つまり、そのオブジェクトへの参照が構築中にエスケープされない場合)、そのオブジェクトへの参照を参照するすべてのスレッドは、コンストラクターで設定された最終フィールドの値も参照します。同期。

これにより、aMap へのセットがaMap = new HashMap<String, String>();. したがって、他のスレッドはこれらを見ることができます

か否か ？

編集：私はこの質問が私の質問に正確に近いことを見つけました

Java 5 以降、volatileキーワードにはリリース/取得セマンティクスがあり、副作用を他のスレッドから見えるようにします (非揮発性変数への代入を含む!)。たとえば、次の 2 つの変数を使用します。

iは通常の非揮発性変数であることに注意してください。次のステートメントを実行するスレッド 1 を想像してください。

その後、スレッド 2 は次のステートメントを実行します。

Java メモリ モデルによると、vスレッド 1 での書き込みとそれに続くスレッド 2 での読み取りによりv、スレッド 2 はiスレッド 1 で実行された書き込みを認識できるため、値 42 が出力されます。

私の質問はvolatile、C# で同じリリース/取得セマンティクスを持っていますか?

mysqlを使用しているシステムの起動時にjarファイルを実行するようにスケジュールしました。

あるDBから別のDBに数千のレコードをプッシュするために使用します。各実行中に大量のCPUメモリを占有しますが、終了すると（実行が正常に完了すると）、システムが再起動するまで占有されたCPUメモリを解放しません.

この jar は 4 時間ごとに実行されるようにスケジュールされています。この占有されたメモリを解放するにはどうすればよいですか?

-- ありがとう、マヌー

関心をお寄せいただきありがとうございます:)

同期ブロック内のステートメントの並べ替えは可能ですか? 例えば

statement1 と statement2 は互いに依存していません。プロセッサーまたはコンパイラーは、これらのステートメントを並べ替えることができますか?

ありがとうございました。

Javaメモリモデルについて質問があります。問題を提示する簡単なクラスを次に示します。

私の知る限り、JMMは、最終フィールドの値が構築後に他のスレッドに表示されることを保証します。ただし、構築後に他のスレッドが配列に格納されている最新バージョンのデータを確実に参照できるようにしたいと思います。

もちろん、上記のコードは問題を示す単純な例です。実際には、直接バイトバッファー用の単純なキャッシュを実装したいので、一部のコレクションクラスに依存したくありません。現在、正しい動作を保証するためにReentrantReadWriteLockを使用していますが、可能であれば回避したいと思います。

JavaメモリモデルはDRF保証（データレースの自由）を提供します。つまり、Javaのリラックスしたメモリモデルで実行された場合、データレースのないプログラムは、逐次一貫性のある実行と同じ動作をします。私は次の質問があります：a）際どいプログラムが与えられた場合、コンパイラは（非常に具体的には任意のjvm実装）遅延セット分析/スレッドエスケープ分析などを実行して、レースにするために挿入する必要のあるフェンス命令を見つけます-自由？それとも、JITはどこで実行されるかに基づいてそれを行いませんか？

b）コンパイラがそれを行う場合（この場合はjvm）、コンパイラはとにかくそれをレースフリープログラムに変換するので、なぜ私たちは際どいプログラムを書くことができないのですか？そして、コンパイラーがそれを行う方法（フェンスの挿入によってレースフリーにする）の場合、Javaでの同時データ構造の実装のように、（意図的に）際どいプログラムをどのように書くことができますか？

c）または、jvm自体がレーシーをレースフリープログラムに変換しないという3番目の可能性がありますが、それを実行できる他の分析が存在します。本当ですか？