理論的最小値

• monitorenter ：キャプチャを監視します。 一度に1つのスレッドのみがモニターを所有できます。 キャプチャの試行時にモニターがビジーの場合、キャプチャしようとするスレッドは解放されるまで待機します。 この場合、キューには複数のスレッドが存在する可能性があります。
• monitorexit ：無料のモニター
• wait ：現在のスレッドをモニターのいわゆる待機セットに移動し、 notify発生を待機します。 waitメソッドの終了もfalseである可能性があります。 モニターを所有するスレッドwaitと、他のスレッドがモニターを引き継ぐことができます。
• notify （all） ：現在モニターの待機セットにあるスレッドの1つ（またはすべて）を起動します。 制御を取得するには、目覚めたストリームがモニターを正常にキャプチャする必要があります（monitorenter）

競合 -複数のエンティティが同時に同じリソースを所有しようとする状況。排他的使用を目的としています

• init ：モニターは作成されたばかりで、これまで誰もキャプチャしていません
• バイアス ：（ スマート最適化、すぐにはほど遠いように見えました）モニターは、それをキャプチャした最初のスレッド用に「予約」されています。 将来、このストリームはキャプチャするのに高価な操作を必要とせず、キャプチャは非常に迅速に行われます。 キャプチャが別のストリームを生成しようとすると、モニターはそのストリームのために予約されます（ rebias ）、またはモニターがシン状態になります（ バイアスを取り消します ）。 モニターがキャプチャーしようとしているオブジェクトのクラスのすべてのインスタンスに即座に作用する追加の最適化もあります（ 一括取り消し/バイアス ）
• thin ：複数のストリームがモニターをキャプチャしようとしますが、競合はありません（つまり、同時にキャプチャしたり、非常に小さなオーバーラップでキャプチャしたりすることはありません） 。 この場合、キャプチャは比較的安価なCASを使用して実行されます。 競合が発生すると、モニターは膨張状態に入ります
• fat / inflated ：オペレーティングシステムレベルで同期が行われます。 ストリームは、モニターをキャプチャする順番になるまで待機してスリープします。 コンテキストを変更するコストを忘れたとしても、スレッドが制御を取得するときは、システムシェダラーにも依存するため、必要以上に時間がかかります。 競合が解消されると、モニターは薄い状態に戻る場合があります

オブジェクトヘッダー

単語の内容をマークする

 Identity hashcode 

 age 

 0 

     mark word 

 id - 

 epoch 

 age 

 1 

バイアスの場合、アイデンティティハッシュコードとthreadID +エポックの両方に十分なスペースが同時にないことに気づきましたか？ そして、これはそうであり、ここから興味深い結果があります：ホットスポットでは、 System.identityHashCodeを呼び出すと、オブジェクトの取り消しバイアスが発生します。

synchronizedを使用する簡単な例

 1 2 3 4 5 6 7 

 public class SynchronizedSample { void doSomething() { synchronized(this) { // Do something } } } 

 javac SynchronizedSample.java && javap -c SynchronizedSample 

 void doSomething(); Code: 0: aload_0 //    this 1: dup //    (this) 2: astore_1 //      (this)   1 3: monitorenter //   ,     (this) 4: aload_1 //   this   5: monitorexit //   6: goto 14 //  "catch-" 9: astore_2 // (  ,   )     2 10: aload_1 //  this    11: monitorexit //   12: aload_2 //      13: athrow //   14: return //  Exception table: from to target type 4 6 9 any //      ,   "catch-" 9 12 9 any //   ,     

一般に、一部のアクションのVMヘルパーのコードは、JITによって貼り付けられたものと内容が異なる場合があります。 JITの一部の最適化がインタープリターに移植されない可能性がある点まで

モニター

 ./bytecodes.hpp:235: _monitorenter = 194, // 0xc2 ./bytecodes.cpp:489: def(_monitorenter, "monitorenter", "b", NULL, T_VOID, -1, true); 

CAS-比較と交換- *destとcompare_value原子的に比較し、等しい場合は*destとexchange_value場所で比較exchange_valueます。 初期値*dest返されます。 （同時に、両面membarは保証されますが、次の記事でそれらについて詳しく説明します）

 CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception); 

fast_enter

• Rebias-モニターをすばやくキャプチャする権利を留保するストリームの変更。 単純な場合に許可されます。たとえば、モニターが実際にキャプチャできなかった場合（ 匿名バイアス ）、またはバイアスが前の時代から保持されている場合（特定のクラスの一括取り消しの回数、以下を参照）、本質的には同様です誰もバイアスを監視していない。 さらに、fast_enterを呼び出すときにfast_enter完全に無効にすることができます（ attempt_rebias = false ）。
• 取り消し -モニターのバイアスロックを無効にします。 ほとんどの場合、特にattempt_rebias false設定されている場合に使用されfalse 。 現在、モニターが別のライブストリームによって所有されている場合、rebiasはこのスレッドがsafepointで停止することを要求します。その後、このストリームのスタックを調べ 、そこに格納されたモニターヘッダーをバイアスなしに修正します。
• バルクリバイアス -このクラスのすべての生きているインスタンスと後のインスタンスのリバイアス。 この時代の特定のクラスの取り消しまたはリバイアスの数がBiasedLockingBulkRebiasThresholdを超えるとBiasedLockingBulkRebiasThresholdます。 グローバルセーフポイントで実行される時代の変化を引き起こします。
• 一括取り消し -このクラスのすべての生きていて割り当てられた後のインスタンスを取り消します。 この時代の特定のクラスの失効またはリバイアスの回数がBiasedLockingBulkRevokeThresholdを超えるとBiasedLockingBulkRevokeThresholdます。 グローバルセーフポイントで実行される時代の変化を引き起こします。

safepoint-スレッドの実行が安全な場所で停止している仮想マシンの状態。 これにより、スレッドが現在所有しているモニターのバイアスの取り消し、最適化解除、スレッドダンプの取得など、侵入的な操作が可能になります。

slow_enter

1. ケース1、 「良い」 ：オブジェクトのモニターは現在無料です。 次に、CASを使用して占有しようとします。 CASは既にアーキテクチャに依存する（通常はプロセッサによってネイティブにサポートされる）命令であるため、さらに深くする意味はありません。 （Ruslan＃は彼にケレミンヘンウィートを与えましたが 、私は「MOSトランジスタのソースシンク内の電子の流れに到達しなかった」とinしました 。 ） CASが成功すると、勝利：モニターがキャプチャされます。 それが失敗すると、悲しみに満たされ、3番目のケースに進みます。
   
   
2. ケース2も「良好」です。オブジェクトのモニターは無料ではありませんが、現在キャプチャしようとしている同じストリームでビジーです。 これは再帰的なキャプチャです。 この場合、簡単にするために、スタックNULLのディスプレイスされたヘッダーに書き込みます。これは、以前にこのモニターを既にキャプチャし、スタックに関する情報をすでに持っているためです。
   
   
3. ケース3、 「悪い」膨張 ：だから、失敗したトリックを見せようとする試みはすべて失敗しました。そして、下品なユーザー言語を見せて、セグメンテーション違反に陥る以外にやることはありません。 ハハ 冗談。 ただし、ふくれっ面については何も言いませんでした。OSレベルのプリミティブに頼って「正直に」行動しなければならない場合、 モニターが膨らんだと言います。 コードでは、この動作はObjectSynchronizer::inflateで説明されていますが、ここではあまり注意しません。実際、このメソッドはスレッドセーフであり、いくつかの技術的な微妙な点を考慮して、フラグをモニターに設定します。
   
   モニターを膨らませた後、モニターに入る必要があります。 ObjectMonitor::enterメソッドはまさにそれを行い、考えられない考えられないすべてのトリックを適用して、ストリームのObjectMonitor::enterを回避します。 これらのトリックには、ご想像のとおり、1回限りのCAS-sやその他の「フリーメソッド」を使用して、スピンループを使用してキャプチャを試みることが含まれます。 ちなみに、コメントと何が起こっているのかとの間にわずかな矛盾が見つかったようです。 一度スピンループでモニターに入ろうとすると、一度だけ行うと主張します。
   
   

   352 353 354 355 356 357 358 359 360 361 362 363

   // Try one round of spinning *before* enqueueing Self // and before going through the awkward and expensive state // transitions. The following spin is strictly optional ... // Note that if we acquire the monitor from an initial spin // we forgo posting JVMTI events and firing DTRACE probes. if (Knob_SpinEarly && TrySpin (Self) > 0) { assert (_owner == Self , "invariant") ; assert (_recursions == 0 , "invariant") ; assert (((oop)(object()))->mark() == markOopDesc::encode(this), "invariant") ; Self->_Stalled = 0 ; return ; }

   
   
   そして、ここでもう少し、呼び出されたenterIメソッドで、もう一度実行します。
   
   

   485 486 487 488 489 490 491 492 493 494 495 496 497

   // We try one round of spinning *before* enqueueing Self. // // If the _owner is ready but OFFPROC we could use a YieldTo() // operation to donate the remainder of this thread's quantum // to the owner. This has subtle but beneficial affinity // effects. if (TrySpin (Self) > 0) { assert (_owner == Self , "invariant") ; assert (_succ != Self , "invariant") ; assert (_Responsible != Self , "invariant") ; return ; }

   
   
   さて、オペレーティングシステムレベルでの駐車は非常に怖いので、ほとんど何でもそれを回避する準備ができています。 彼女の何がひどいのか見てみましょう。
   
   

   逆 駐車ストリーム

   かなり前に書いたコードに近づいていると言わなければなりませんが、これは顕著です。 多くの複製、リエンジニアリング、その他の設備があります。 ただし、「この松葉杖を取り除いて」や「これらを組み合わせて」などのコメントの存在は少し安心です。
   
   それでは、駐車ストリームとは正確には何ですか？ 各モニターにはいわゆるEntry List （ Waitsetと混同しないでください ）があることを誰もが聞いたことがあるはずです。 モニターへの低価格での入力試行がすべて失敗した後、この特定のキューに自分自身を追加し、その後、駐車します。
   
   

   591 592 593 594 595 596 597 598 599 600 601

   // park self if (_Responsible == Self || (SyncFlags & 1)) { TEVENT (Inflated enter - park TIMED) ; Self->_ParkEvent->park ((jlong) RecheckInterval) ; // Increase the RecheckInterval, but clamp the value. RecheckInterval *= 8 ; if (RecheckInterval > 1000) RecheckInterval = 1000 ; } else { TEVENT (Inflated enter - park UNTIMED) ; Self->_ParkEvent->park() ; }

   
   
   駐車場に直接移動する前に、現在のストリームに責任があるかどうかに応じて、ここで時間を調整できるかどうかを確認します。 責任のあるフローは常に1つだけであり、いわゆるストランディングを回避するために必要です。モニターが空いているときの悲しみですが、待機セット内のすべてのフローはまだ待機しており、奇跡を待っています。 担当者がいるとき、彼は時々自動的に目を覚まします（より多くの無駄な目覚めが起きた-目覚めた後、ロックを取得できませんでした-駐車時間は長くなります。1000msを超えないことに注意してください）。 残りのフローは、少なくとも永遠に目覚めを待つことができます。
   
   それでは、駐車の本質に移りましょう。 すでに理解しているように、これはにwait/notifyたwait/notify Java開発者に似たセマンティクス上のものですが、オペレーティングシステムレベルで発生します。 たとえば、Linuxおよびbsdでは、ご想像のとおり、POSIXスレッドが使用されます。POSIXスレッドでは、 pthread_cond_timedwait （またはpthread_cond_wait ）が呼び出され、モニターが解放されるのを待ちます。 これらのメソッドは、LinuxスレッドのステータスをWAITINGに変更し、何らかのイベントが発生したときにシステムスケジューラにウェイクアップするように要求します（ただし、このスレッドが責任を負うのは一定期間後までです）。
   
   

   OSレベルのスレッドスケジューリング

   それでは、Linuxカーネルを調べて、そこでスケジューラーがどのように機能するかを見てみましょう。 ご存知のように、Linuxソースはgitにあり、次のようにシェダーをクローンできます。
   
   

    git clone git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-rt.git 

   
   
   フォルダに行きましょう...わかりました、わかりました、冗談です。 ソースコードの行に対して正確なLinuxシェダーデバイスの機能は、単純なsynchronizedブロックから始めた無害な記事には既に深すぎます。ハードコアを減らすために、シェダーが一般的にどのように機能するかを説明します。 linux, . - , , : — , . — quantum — , , , . linux , 10-200 , 1 . windows , 2-15 , — 10 15 .
   
   , , , . , , (, - I/O-), , - . - . , , , -, , .
   
   , , , — . , , , , , , .
   
   , , : , — , . : , , -, .
   
   , , , . , contention, .

monitorexit

NB：synchronizedメソッド

 synchronized void doSomething() { // Do something } 

 synchronized void doSomething(); Code: 0: return 

待って通知する

メモリ効果

Major O. aka Disclaimer からのコメント

お楽しみに

そしてもう一つ©