【ITニュース解説】Your Java App Is Leaking Memory! The Hidden Classloader Trap You're Missing.

Javaアプリケーションを開発し、特にWebサーバー上で運用していると、奇妙な現象に遭遇することがある。アプリケーションの新しいバージョンをデプロイするたびに、システムのメモリ使用量が少しずつ増え続け、初期の状態に戻らなくなるという問題だ。これを繰り返すうちに、アプリケーションの動作が遅くなったり、最終的には「OutOfMemoryError」というエラーで停止してしまったりする。これは、Javaのメモリ管理における「クラスローダーのメモリリーク」と呼ばれる、発見が困難で厄介な問題が原因であることが多い。

まず、Javaにおけるメモリリークの基本を理解する必要がある。Javaには「ガベージコレクタ（GC）」という、プログラム中で使われなくなったオブジェクトを自動的に探し出し、そのオブジェクトが占有していたメモリを解放してくれる優れた仕組みがある。これにより、開発者はメモリ管理をあまり意識せずにプログラミングに集中できる。しかし、本来は不要になったはずのオブジェクトが、プログラムのどこかから参照され続けている場合、GCはそのオブジェクトを「まだ使われている」と判断し、メモリから解放できない。このように不要なオブジェクトがメモリ上に溜まり続け、利用可能なメモリを圧迫していく現象がメモリリークである。

この問題の鍵を握るのが「クラスローダー」だ。クラスローダーは、その名の通り、Javaのクラス、つまりプログラムの設計図が書かれた.classファイルを必要に応じてメモリ上に読み込む役割を担っている。TomcatのようなWebアプリケーションサーバーでは、デプロイされたWebアプリケーションごとに個別のクラスローダーが作成される。これは非常に重要な仕組みで、あるアプリケーションが使っているライブラリと、別のアプリケーションが使っている同じ名前のライブラリのバージョンが違っていても、互いに干渉することなく安全に動作させることができる。また、サーバー全体を再起動することなく、特定のアプリケーションだけを新しいバージョンに入れ替える「ホットデプロイ」も、この仕組みによって実現されている。

メモリリークは、このアプリケーションの入れ替え、つまり再デプロイの際に発生する。アプリケーションのバージョン2をデプロイすると、サーバーはバージョン1のアプリケーションを停止し、関連する全てのオブジェクトやクラスをメモリから解放しようとする。このとき、バージョン1のクラスを読み込んだクラスローダーも一緒に破棄されるはずだ。しかし、もしサーバー側のプログラムなど、バージョン1のアプリケーションの外にある何かが、バージョン1のクラスローダーによって読み込まれたオブジェクトへの参照を一つでも持ち続けていた場合、事態は深刻になる。その参照が残っている限り、GCは参照されているオブジェクトを解放できず、さらにそのオブジェクトを生成したクラス、そしてそのクラスを読み込んだクラスローダー全体もメモリ上に残り続けてしまう。これが、再デプロイのたびに古いバージョンのアプリケーションが丸ごとメモリ上にゴミとして蓄積されていく原因だ。

このような意図しない参照が残ってしまう原因はいくつか考えられる。最も多いのは、静的フィールド（staticキーワードで宣言された変数）の不適切な使用である。静的フィールドは特定のインスタンスではなくクラス自身に属するため、アプリケーションのライフサイクルを超えてメモリ上に残りやすい。例えば、アプリケーション内のクラスが静的なリストを持っていて、そのリストへの参照がサーバー側のどこかに渡ってしまうと、アプリケーションがアンデプロイされてもリストとそこに含まれる全データが解放されなくなる。次に多いのがThreadLocal変数の扱いで、サーバーが管理するスレッドプール内のスレッドでThreadLocalを使い、処理後に値を削除（remove()）し忘れると、そのスレッドが再利用される際に古いアプリケーションのオブジェクトへの参照が残り続けてしまう。その他にも、アプリケーションが独自に起動したスレッドを停止し忘れたり、JDBCドライバやログ出力ライブラリなどの共有リソースを、アプリケーション終了時に登録解除し忘れたりすることも原因となりうる。

この問題が発生している兆候は、再デプロイごとにメモリ使用量が階段状に増加していくことだ。また、クラス定義情報を格納するためのメモリ領域である「Metaspace」（Java 8以降の名称）が枯渇することによるOutOfMemoryErrorも典型的な症状である。疑わしい場合は、プロファイリングツールを使ってメモリの状態を詳細に調査する必要がある。ヒープダンプと呼ばれるメモリのスナップショットを取得し、Eclipse Memory Analyzer (MAT) などのツールで解析することで、どのオブジェクトがメモリを占有しているのか、そしてどの参照が原因で解放されずにいるのかを突き止めることができる。

解決策は、アプリケーションが終了する際に、自身が確保したリソースを明示的に解放する処理を徹底することにある。Webアプリケーションの場合、ServletContextListenerという仕組みを利用して、アプリケーションが停止するタイミングでクリーンアップ処理を実行するのが一般的だ。この中で、静的フィールドにnullを代入して参照を断ち切ったり、起動したスレッドを確実に停止させたり、登録したJDBCドライバを登録解除したりといった処理を実装する。ThreadLocal変数については、try-finally構文を使って、処理の成功・失敗にかかわらず必ずremove()メソッドが呼ばれるように記述することが重要だ。

クラスローダーによるメモリリークは、Javaの内部構造に起因するため一見すると複雑に思えるが、その仕組みを理解すれば予防と対策は可能である。アプリケーションを設計する初期段階から、起動時だけでなく終了時の処理も意識し、リソースをきれいに後片付けする習慣をつけることが、長期的に安定して稼働する堅牢なシステムを構築する上で極めて重要となる。