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で行われます、テストコマンド:

リーリー