前回，システム運用者は次の4つのポイントに絞ってJVMの動きを監視することを紹介し，そのうち1.と2.について解説しました。

1. JVMがアプリケーションを中断することなく実行できているか
2. JVMがアプリケーションのリソースを奪っていないか
3. OSのリソースが十分に割り当てられているか
4. アプリケーションが動いているか

今回は，3.と4.について解説します。

「OSのリソースが十分に割り当てられているか」と「アプリケーションが動いているか」は，ともにスレッドを見ることで確認できます。

3.では，たとえばOS上で動くほかのプロセスによってストレージのリソースが大量に使われていると，JVMが十分なリソースを確保できなくなります。十分なリソースを確保できないと，JVMのI/Oの時間が長くなりますが，そのときファイルI/Oに関わるメソッドを処理するスレッドの実行時間が普段よりも長くなることが多いです。普段の実行時間と処理時間が長くなったときのI/O時間を比較することで，リソースが十分に割り当てられているかを確認することができます。

また，4.は，アプリケーションの実装が酷いためスレッドが常に動けない状態になっている可能性を確認することで把握できます。

スレッドの状態を4つに分ける

スレッドを見るにあたり，スレッドの状態を次の4つに分類します。

• 処理の受付中
• 処理中
• 休み中
• 待機中

「処理の受付中」は，スレッドが何も処理をしていない状況です。スレッドプールでプールされているスレッドがこの状態に該当します。

「処理中」は，スレッドが仕事を受け，CPUを使用して処理を実行している状態です。

「休み中」は，スレッドが明示的に休みを命じられて，何もしていない状態です。

「待機中」は，スレッドが何かしらの方法で処理を止められて，処理を再開するのを待たされている状態です。

OSのリソースが十分に割り当てられていないと，スレッドは待機中となります。

また，アプリケーションが動けていないと，スレッドは休み中もしくは待機中となります。

同じ理由で待機するスレッドが一定量を超えると，待機時間が急激に増加することがあります。しかし，少ないスレッド数で実行すると顕在化しないことがあるため，テストフェーズでは気付かないことが多いです。大量のリクエストが発生する本番環境でのみ発生することがよくあるため，注意が必要です。

スレッドが待機中になる3つの理由

スレッドは，おもに次の3つの理由から待機中になります。

• I/O待ち
• ロック待ち中
• 委譲した処理の完了待ち

I/O待ち

ローカルやリモートのファイルを読み書きする時間や，ネットワーク先のマシンへアクセスを待っている状態です。ネットワーク先のマシンへのアクセスの一部は，後述する委譲した処理の完了待ちも含むことがあります。

これらは，OSのシステムコールを経由して処理されます。ほかのプロセスがリソースを使いすぎると，リソースがなかなか使えなくなってしまうため，待ち時間が長くなります。また，同一アプリケーション内でも別のスレッドがリソースを使いすぎると，同様にリソースがなかなか使えなくなります。

ロック待ち

排他的に実行しないといけない処理の入口でスレッドが待たされている状態です。

スレッドは，アプリケーションで指定したロックオブジェクトごとに待たされます。処理をおこなう際にロックオブジェクトを獲得できない場合，スレッドはロックオブジェクトが開放されるのを待ちます。ロックオブジェクトが開放されると，スレッドはロックオブジェクトを獲得して処理を続け，処理が終わるとロックオブジェクトを開放します。

委譲した処理の完了待ち

同一のJVM内で別スレッドへ処理を委譲したり，（⁠RESTfullな）Webサービスやデータベースなど外部へ委譲した処理が返ってくるのを待っている状態です。待ち時間には，外部での実行時間に加え，データを転送する時間が含まれます。