私の知る限りでは、Javaですべてのオブジェクトは、マークの単語を持っています。最初のワード（マーク・ワード）が唯一のスレッドがロックを取得または異なるスレッド間の競合がある場合、ロック・モニター・オブジェクトを指している場合、フラグのいずれかを介して、ロック情報を格納するために使用され、両方の場合に、比較され、そしてスワップ構築物は、ロックを取得するために使用されます。
-しかし、このリンクに従っhttps://www.baeldung.com/lmax-disruptor-concurrency
書き込みの競合に対処するために、キューは、多くの場合、カーネルにコンテキストスイッチが発生する可能性があり、ロックを使用しています。これが起こると関与プロセッサは、そのキャッシュにデータを失う可能性があります。
私は何をしないのですか？
どちらも、synchronizedも標準Lockロックする際の実装では、カーネルへのコンテキストスイッチを必要としない競合のない又は解錠。これらの操作は、実際に原子CASまたは書き込みに煮詰めます。
パフォーマンスの重要な側面は、競合モニタやロックを取得しようとしたとき、すなわち、それは利用できません。モニタやロックの可用性を待って待機している状態にスレッドを入れて、リソースが利用可能になったときにそれを再活性化を意味します。パフォーマンスへの影響は、すべてのCPUのキャッシュを心配する必要はありませんことを、非常に大きいです。
その時に利用可能になる可能性があるときに、このような理由から、一般的な実装は、いくつかの時間のために、ループ内のモニタやロックの可用性を再チェック、スピニングのいくつかの量を行います。これは通常、CPUコアの数に関連付けられています。リソースがその時点で利用可能になると、これらのコストを回避することができます。これは、しかし、通常は取得があることを許可する必要が不公平スピニング買収はすでに待機しているスレッドを追い越すこととして、。
リンク先の記事があなたの引用文の前に言うことに注意してください：
キューは、常に一般的に近いフルや消費者と生産者の間でペースの違いによる空に近いです。
このようなシナリオでは、より高速なスレッドは、遅かれ早かれ、彼らは競合せずにロックを取得した場合でも、キューに新しいスペースまたは新しいアイテムを待って、状態待機を入力します。シンプルなキューの実装を使用したときに、この特定のシナリオでは、関連するコストは確かにあると避けられません。