私はここで考えています：同期する必要があるFAST操作を実行する2つのスレッドがある場合、非ブロッキングアプローチはブロッキング/コンテキストスイッチアプローチよりも高速/優れていませんか？
非ブロッキングとは、次のような意味です。
while（true）{if（checkAndGetTheLock（））break; }
私が考えることができる唯一のことは、ロックの周りでループしているスレッドが多すぎる場合の（CPUのバーンアウトによる）飢餓です。
あるアプローチと他のアプローチのバランスをとるにはどうすればよいですか？
Java Concurrency in Practiceがこの件について述べていることは次のとおりです。
JVM は、スピン待機 (成功するまでロックの取得を繰り返し試行する) を介して、またはオペレーティング システムを介してブロックされたスレッドを一時停止することにより、ブロックを実装できます。どちらがより効率的かは、コンテキスト スイッチのオーバーヘッドとロックが使用可能になるまでの時間との関係によって異なります。短い待機にはスピン待機が望ましく、長時間の待機には一時停止が望ましい。一部の JVM は、過去の待機時間のプロファイリング データに基づいて 2 つのいずれかを適応的に選択しますが、ほとんどの場合、ロックを待機するスレッドを一時停止します。
また、（これは、IMO、最も重要なポイントです）：
競合のない同期のコストについて過度に心配する必要はありません。基本的なメカニズムはすでに非常に高速であり、JVM はさらにコストを削減または排除する追加の最適化を実行できます。代わりに、ロックの競合が実際に発生する領域に最適化の取り組みを集中してください。
確認する唯一の方法は、テストすることです。マルチスレッドとパフォーマンスに関しては、単純に想定できません。