Java 8時代の開発者のためのデバッグ／トラブル解決の基本・応用テクニック〜JJUG CCC 2014 Springまとめリポート（後編）（1/3 ページ）

　日本Javaユーザーグループは2014年5月18日、「JJUG Cross Community Conference 2014 Spring」を開催した。「JJUG Cross Community Conference」（以下、JJUG CCC）は毎年春と秋に開催されるカンファレンス。初心者向けからエキスパート向けまで、Java／JVMに少しでも関連すればいいという広いテーマでさまざまな講演が行われている。

　前編では、「Struts後時代のJava EE／Javaモダン開発はどうあるべきか」と題し、Java EEにおいてJava 8はどこまで利用できるのか、Java開発でGit、CI、継続的デリバリは、どこまで有効なのか、Struts後時代のJava EE開発における有効なフレームワークなどをお伝えした。

　後編では、Java開発におけるデバッグ／トラブル解決についてのセッションの模様をいくつかお届けする。

Java開発における「3大トラブル」と、その対策

　日本Javaユーザーグループの上妻宜人氏は「Javaトラブルに備えよう」という講演で、トラブルに対する予防的措置の必要性を訴えた。

　上妻氏は日々の業務でJavaにまつわるさまざまなトラブルシューティングを行っており、頻繁に遭遇するトラブルとしてOutOfMemoryError（メモリ不足）、スローダウン、OS設定漏れを「3大トラブル」として挙げる。どの種の問題も報告を受けた際には原因を追究するための情報が乏しく、さらに再現性がなく調査ができないケースが非常に多いという。

　そこで各種の問題が発生した際に十分な情報を取得できるようにするための事前設定、発生した際に取得すべき情報、そして取得した情報を解析するためのツールを紹介した。

日本Javaユーザーグループ 上妻宜人氏「クリティカルなトラブルでも迷宮入りしてしまうことがしばしば」

OutOfMemoryError

　OutOfMemoryErrorは、一度発生してしまった後の動作は保証されない、Java仮想マシンとして「起こってはならない」問題だ。また、開発時には見つかりにくい微細なメモリリークは長時間稼働したり、想定外の負荷がかかる本番環境で顕在化しやすいのでやっかいだ。

　そこで、上妻氏は「まずは運用環境ではGCログを出力させるように設定してヒープ領域の利用傾向を後から確認できるようにすることが重要だ」と強調。GCログを確認すれば「実際にメモリリークが発生しているのか」「そもそも設定ヒープサイズが小さ過ぎるのか」といったことが切り分けられるからだ。

お勧めのGCログ出力設定

　また上妻氏は、OutOfMemoryError発生時はヒープダンプとクラスヒストグラムを取得しておくことでリークしているオブジェクトやリーク発生箇所を絞り込めることを解説。ツールとしてヒープダンプの解析に「Eclipse Memory Analyzer」や、クラスヒストグラムの取得・解析に便利な「HeapStats」も紹介した。

ヒープダンプの取得方法

低オーバーヘッドに情報収集、そして解析結果を可視化してくれるHeapStats

　クラスヒストグラムは取得負荷が小さいため定期的に取得しておき、OutOfMemoryError発生時に増加傾向にあるクラスを解析するというテクニックは多くのシステムで参考にすべきだろう。

定期的なクラスヒストグラムの取得も有効

OutOfMemoryError（OOMエラー）に備えて設定しておくべきJVMオプション

スローダウン

　スローダウン発生時は、「何となく」再起動し、以降なかなか問題が再現せず根本的な問題解決ができないケースは非常に多い。上妻氏は「スローダウンが発生したら対症療法的に再起動するのはやむを得ないものの、再起動前に必ずスレッドダンプを取得すべき」と強調した。

よくあるハングの原因

　スレッドダンプを確認すればスローダウン（またはハング）しているタイミングでどのスレッドがどういった処理をしているのか確認できるが、生のスレッドダンプの解析は難しいので可視化・解析ツールとして「侍」「ThreadLogic」の利用を勧めた。

スレッドダンプの取得方法

スレッドダンプの可視化ツール「侍」。時系列にスレッドの状態を追ったり、各スレッドの状態を一目で確認したりしやすい

もう一つのスレッドダンプ可視化ツール「ThreadLogic」。確認すべきスレッドを洗い出してくれ、特にJRockitやWebLogic Serverで検出精度が高い

OS設定漏れ

　OSの設定漏れで発生する代表的な問題として上妻氏は、ファイルデスクリプターの枯渇（ファイルI/Oエラーが「too many open files」というメッセージと共に発生）や、プロセス当たりの最大スレッド数を超えた際のスレッド生成失敗（「OutOfMemoryError: unable to create new thread」というメッセージと共に発生）を挙げた。

　多くの場合は「ulimit」や「limits.conf」の「nproc」を適切に設定すれば避けられる問題だ。しかしアプリケーションの作りの問題でファイルを開き過ぎていたり、クローズし忘れていたりする場合や、スレッドを無尽蔵に作成してしまっている可能性もある。スレッドダンプを取得したり、lsofコマンドでオープン中のファイルを確認したりすることも重要だ。

　上妻氏は講演の最後に、「トラブルが発生時に初めて情報収集をするのは難しいので、日頃より設定や情報収集の『素振り』を行ってトラブル発生に備えることが大事」と締めくくった。