Java ロックフリーの同時実行性

Question

次のコードのロックなし実装とロックなし実装の比率はどちらが良いでしょうか? jmeter を使用して 1 秒あたり 20 リクエストを作成しています。ロック コードなしの test() のスリープ操作の出力のほとんどは 500 ミリ秒とは大きく異なりますが、ロック コードの出力は基本的に 500 ミリ秒です。 1.2 ミリ秒の差、この問題は非常に奇妙です....

リーリー

Answer 1

1. まず最初に、Synchronized は AtomicXX クラスと比較されるのではなく、ReentrantLock クラスと比較されることが多くありますので、ご自身で検索してください。

2. ロックなしまたはロックに関する質問については、テストコード b のコードに問題があります。

• メソッド a、同期されたコード ブロックの場合、最初の受信スレッドによってロックが保持された後、ロックの取得を要求する後続のスレッドはブロックされ、一時停止されます。

  前のスレッドがロックを解放するまで、後続のスレッドは実行を再開します。ロックの存在により、20 個のリクエストは順次実行 に似ており、この層は jvm によってスケジュールされます

• メソッド b の場合、

  cas 操作は実際には常に実行されており (cas 操作の実行を継続的に試行します)、無限ループがより多くの CPU リソースを消費することがわかっています。スレッドが多いほど、ここでの CAS 操作も多くなり、必然的に CPU 使用率が急増します。理論的には、メソッド B のコードが常に 20 個のアクティブな作業スレッドになるはずです。CPU とスレッド モデルは別のトピックです。 、スレッド数のチューニングは、jvm の比較的高度なトピックです。興味がある場合は、自分でググってください

  。
• ReentrantLock と synchronized について話しましょう: 通常、同時実行性が高い場合、ReentrantLock は synchronized よりもパフォーマンスが高く、ReentrantLock は synchronized では提供されないいくつかの機能を提供します (サンプル コードではスリープの自動放棄など)。 500ms は人間にとっては非常に短いですが、基本的には「カタツムリのように遅い」と表現しても過言ではありません。コード:

リーリー

• メソッド c は ReentrantLock を使用して実装されます。ほとんどの場合、ReentrantLock は synchronized よりも効率的です
  。
• juc (java.util.concurrent) のコア クラス Aqs (AbstractQueuedSynchronizer) は、キューベースの同時実行パッケージです。デフォルトでは、ロック競合 (スピン) が 1000 ナノ秒を超えると、スレッドがパークされます (操作を一時停止します)。 CPU の頻繁なスレッド切り替えを減らすために、方法 c でスリープ時間パラメータを調整してみることができます。

• テスト方法、このマシンにはjmeterがインストールされていません、テストはApache abで行われます、テストコマンド:

リーリー