問題タブ [synchronized-block]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - Java同期ブロックは「this」とメソッドパラメーターで同じように機能しますか?
メソッド・パラメーターがこのキーワードの代わりに同期ブロックで使用されている場合の Java 同期の動作。
対
正味の効果は同じですか?
java - 同期ブロックにパラメーターを渡す目的は何ですか?
そんなこと知ってる
コードのブロックを同期するときは、ロックとして使用するオブジェクトのロックを指定します。たとえば、サードパーティ オブジェクトをこのコードのロックとして使用できます。これにより、1 つのオブジェクト内でコードを同期するために複数のロックを設定できます。
ただし、ブロックに引数を渡す必要性がわかりません。String のインスタンスを渡すかどうかは問題ではないため、同期ブロックはブロックに渡されるパラメーターに関係なく完全に機能するため、一部のランダム クラスのインスタンスが同期ブロックに渡されます。
したがって、私の質問は、とにかく同期ブロックが2つのスレッドが同時にクリティカルセクションに入るのを防ぐかどうかです。次に、なぜ引数を渡す必要があるのか。(つまり、デフォルトでランダムなオブジェクトのロックを取得します)。
質問が正しく構成されていることを願っています。
次の例を、同期ブロックに対するランダム パラメータを使用して試しました。
非静的同期ブロックの使用:
静的同期ブロックの使用:
java - 同期に対して ReentrantLock を使用する利点
同期よりも ReentrantLock を使用する利点がもう 1 つあります。
以下のコードは、クリティカルセクションで例外が発生してもロックが解除されることを示しています ( ReentrantLock を使用)
今すぐ同期を使用して
両方のコードを比較すると、同期ブロックを使用することにはもう1つの欠点があることがわかります。つまり、クリティカルセクションで例外が発生した場合、ロックを解放できないことです。
私は正しいですか?
間違っている場合は修正してください。
同期ブロックで例外が発生した場合、ロックを解除する方法はありますか?
java - 再入可能同期 - 呼び出された同期メソッドのロック解除
最初のロックは、2 回目に同じロックを取得する同期メソッド 2 を呼び出すメソッド 1 で取得されます。
ここで、同期ブロックが method2() で終了すると、ここで初めてロック解除が行われ、 method1() の同期ブロックに戻り、再びロック解除が 2 度目に行われるときに疑問が生じます。
ReentrantLock のように内部でロック数を管理していますか?
android - コンパイル時の検証に失敗したため、クラスを拒否しています Android
アプリケーションの 1 つが起動時に突然失敗し、次のエラー メッセージが表示されます。
java.lang.VerifyError: コンパイル時の検証に失敗したため、クラス com.sample.BufferManagerImpl を拒否しています (「com.sample.BufferManagerImpl」の宣言が /data/app/com.sample.myapp-1/base.apk に表示されます)
ART 仮想マシンを使用するデバイスでのみ失敗しますが、Dalvik では失敗しません
java - コードの同期ブロックでJavaタイマーを呼び出す
A というコードの親ブロックがある場合、A は同期されます。そして、A では、B というコードの子ブロックを実行します。B も同期されると仮定してもよろしいですか?
AI に特定の t 時間で B の実行を遅らせるタイマーがある場合、A が既に終了した後で B が実行される可能性はありますか?
どうもありがとうございました。
P/S: わかりにくいコードで申し訳ありません。
java - 同期 (これ) は、同期ブロックのみをロックしますか、それともすべての「この」コードをロックしますか?
いくつかのスレッドを実行すると、そのうちのいくつかは静的関数getCount()
を呼び出し、いくつかは新しいインスタンスを作成します。getCount()
その時点で実際のインスタンス数を呼び出すたびに取得したいと考えています。
- コード内の 2 つのオプションに違いはありますか?
- " " をロックした場合、コンストラクターが同期ブロックを終了するまで
this
呼び出すことができないということではありgetCount()
ません (getCount() で同期を記述しない場合としましょう)。 - コード内のどこかで同期ブロックを実行すると、同期ブロックのみがロックされますか?それともすべての "
this
" コードがロックされますか? - ここから編集: ありがとうございました。とても役に立ちましたが、回答に続いていくつか質問があります。
- 私が正しく理解していれば、同期された(this)ブロックは静的同期関数に影響を与えません(または接続されません)(numOfInstancesインクリメントではなくロック条件で)?
- インクリメントと getCount() 関数をスレッドセーフにするためのより良いオプションはありますか? (静的オブジェクトを開いて、synced(this) の代わりに synchronized(obj) を実行するように - 友人が提案)。
- ObjectCounter クラスに f1() メソッド (非静的) がある場合、1 つのスレッドが同期 (this) にあるときに、他のスレッドは f1() ブロック (同期クラスではないか、内部に同期ブロックがある) に入ることができますか?
- ObjectCounter に f1() メソッド (非静的) と f2() メソッド (非静的) がある場合、f1() に同期 (this) ブロックがあります。1 つのスレッドが synchronized(this) ブロックにある間、他のスレッドは f1() ブロックに入ることができますか (同期クラスではないか、内部に同期ブロックがあります)? (両方のスレッドが同じインスタンスで「動作」しているとしましょう)
`