この記事は、Liferay DXP 7.0のThread Contentionに関連する一般的なパフォーマンスの問題を説明します。 この問題についての必要な情報とナビゲート方法については以下をお読みください。
解決策
スレッド競合とは、同じオブジェクトのロックを待っている複数のスレッドがある場合です。 これは、ロックを待っているスレッドの数に応じて、スレッドがロックを取得するのにかかる時間が長くなるため、手に負えなくなる可能性があります。 これは、JVMが待機中のスレッドの1つにロックを与える際にFIFOシステムを利用しないという事実によって悪化します。、何らかの基準に基づいて1つを選びますが、私たちの目的では、それはランダムであるのと同じくらいかもしれません。
症状は、スレッド競合の深刻度によって異なります。 もし、影響を受けるスレッドが2、3個しかない場合は、応答時間が遅くなるだけで済むかもしれません。 もし数百人が影響を受けるのであれば、Liferayプラットフォームは完全に無反応になるのと同じことかもしれません。
ここでは、ロギングでの例を紹介します：
"http-/0.0.0.0:8280-248" daemon prio=10 tid=0x00007fbd0018b780 nid=0x484d waiting for monitor entry [0x00007fbbba490000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.log4j.Category.callAppenders(Category.java:205)
- waiting to lock <0x000000066b869058> (a org.apache.log4j.spi.RootLogger)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
この場合、 log4j が RootLogger オブジェクトのロックを待っており、ロックが取得されるまでその実行は中断される（例えば、状態がRUNNABLEでない）。 ID (0x0000...)を検索すると、他の多くのスレッドも同じオブジェクトを待っていることが表示される場合があります。
log4j's Category.callAppenders() を呼び出そうとしているスレッドが十数個、あるいは数百個あり、同じオブジェクトのロックを待っている場合、それは間違いなくスレッド競合の問題です。
Spotifyの Online Thread Dump Analyzer は、この結果をきちんとまとめています：
さいごに:
多くのスレッドがオブジェクトのロックを待っており、この状態が複数のスレッドダンプを通して持続している場合、スレッド競合の問題となります。
これらの問題に対する解決策として考えられるのは
- ボトルネックにあまり依存しないような実行ロジックに変更したり...。
- 設定を変更する、または...
- 受けている負荷に対応できるリソースを追加する。