Linux futex_wait()カーネルのバグにより、ノードが応答していないように見える
ノードがランダムにフリーズし、応答しなくなります（理由は不明）。
ノードがランダムにフリーズし、応答しなくなります（理由は不明）。
バグはRHEL 6.6、CentOS 6.6以降で発生します。
このバグの影響を受けるノードには、次の特徴があります。
- ログにガーベージ・コレクション・アクティビティーはありません。
- 実行中のコンパクションはありません。
- nodetoolコマンドを実行できません。
- ネイティブ・トランスポート、Thrift、またはJMXポートで応答がありません。
- CPU使用率が低いかゼロに近くなっています。
- CPU使用率が高くなっており、いずれノードが応答しなくなります。
ノード上のスレッド・ダンプは次のように表示されます。
Thread 104823: (state = BLOCKED)
- sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise)
- java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long) @bci=20, line=226 (Compiled frame)
- java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long) @bci=68, line=2082 (Compiled frame)
- java.util.concurrent.LinkedBlockingQueue.poll(long, java.util.concurrent.TimeUnit) @bci=62, line=467 (Compiled frame)
- java.util.concurrent.ThreadPoolExecutor.getTask() @bci=141, line=1068 (Compiled frame)
- java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=26, line=1130 (Compiled frame)
- java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=615 (Interpreted frame)
- java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)原因
この問題は、ユーザープロセスがデッドロックしてハングアップする原因となるLinuxのfutex_wait()バグによって引き起こされます。futex_wait()呼び出し（およびそれを呼び出しているプロセス）は永遠にブロックされたままになる可能性があります。lock()、park()、unpark()などのJVM同期メソッド呼び出しはすべて、ある時点でfutex_wait()を呼び出すため、このバグが原因で応答しなくなる可能性があります。
解決策
get_futex_key_refs() fixが含まれているLinuxカーネル（RHEL 6.6.zやCentOS 6.6.zなど）にアップグレードします。
RHELサーバーにインストールされているパッチを、次のコマンドを使用して確認します。
sudo rpm -q --changelog kernel-`uname -r` | grep futex | grep ref
このコマンドの出力例：
- [kernel] futex: Mention key referencing differences between shared and private futexes (Larry Woodman) [1167405] - [kernel] futex: Ensure get_futex_key_refs() always implies a barrier (Larry Woodman) [1167405]
パッチがインストールされていない場合、rpmコマンドの結果として、何も表示されません。
修正が含まれているディストリビューションの詳細については、オペレーティング・システムの関連する製造元または販売元に問い合わせてください。