おそらく、商用プロジェクトに関与するすべてのJava開発者は、遅かれ早かれメモリリークの問題に直面します。これは、アプリケーションパフォーマンスの低下を伴い、ほとんど必然的に、よく知られているOutOfMemoryErrorにつながります。この記事では、そのような状況の実際の例と、Eclipce MemoryAnalyzerを使用してその原因を見つける方法について検討します。

前書き

メモリリークは通常、アプリケーションの長期操作中にヒープ内の占有メモリ量が増加し、ガベージコレクタが終了した後も減少しない状況と呼ばれます。ご存知のように、jvmメモリはヒープとスタックに分かれています。スタックは単純なタイプの変数の値とストリームのコンテキスト内のオブジェクトへの参照を格納し、ヒープはオブジェクト自体を格納します。また、ヒープにはMetaspaceと呼ばれるスペースがあり、ロードされたクラスに関するデータと、クラス自体にバインドされたデータを格納します。インスタンス、特に静的変数の値は格納しません。 Javaマシンによって定期的に起動されるGarbageCollector（以下、GC）は、参照されなくなったオブジェクトをヒープ内で検出し、これらのオブジェクトが占有していたメモリを解放します。 GC作業アルゴリズムは異なり、特に複雑です。次回GCが起動するときに、未使用のオブジェクトを見つけるために毎回ヒープ全体を「検査」するわけではないため、1回のGCの起動後に未使用のオブジェクトがメモリから削除されるという事実に依存する価値はありませんが、アプリケーションで使用されるメモリの量が安定している場合長い間明白な理由もなく成長したので、そのような状況につながった可能性があるものについて考える時が来ました。



jvmには、多機能ユーティリティVisual VM（以下、VMと呼びます）が含まれています。 VMを使用すると、グラフ内のjvmの主要なインジケーターのダイナミクス、特に、ヒープ内の空きメモリと占有メモリの量、ロードされたクラス、スレッドの数などを視覚的に観察できます。さらに、VMを使用して、メモリダンプを取得して調べることができます。もちろん、VMではスレッドダンプとアプリケーションプロファイリングも可能ですが、これらの機能の概要はこの記事の範囲を超えています。この例でVMに必要なのは、仮想マシンに接続して、最初にメモリ使用量の全体像を確認することだけです。 VMをリモートサーバーに接続するには、接続がjmxを介しているため、jmxremoteパラメーターをVMで構成する必要があることに注意してください。これらのパラメーターの説明については、Oracleの公式ドキュメントまたはHabréに関する多数の記事を参照してください。



それで、VMを使用してアプリケーションサーバーに正常に接続したと仮定し、グラフを見てみましょう。







[ヒープ]タブで、jvmの合計メモリと使用済みメモリを確認できます。このタブでは、メタスペースタイプのメモリも考慮されていることに注意してください（これもヒープであるため、他の方法です）。 [メタスペース]タブには、メタデータが占有しているメモリ（クラス自体とそれにバインドされているオブジェクト）に関する情報のみが表示されます。



グラフを見ると、ヒープメモリの合計が約10GB、現在の占有スペースが約5.8GBであることがわかります。グラフの隆起はGC呼び出しに対応し、10：18頃から始まるほぼ直線（隆起なし）は、アクティブな割り当てと割り当て解除がなかったため、それ以降、アプリケーションサーバーがほとんど実行されていないことを示します（必ずしもそうとは限りません）。メモリ。一般に、このグラフは、アプリケーションサーバーの通常の操作に対応します（もちろん、メモリからのみ作業を判断する場合）。問題のグラフは、隆起のない真っ直ぐな水平の青い線が、ヒープ内のメモリの最大量を表すオレンジ色の線のあたりにあるグラフです。



次に、別のグラフを見てみましょう。







ここでは、この記事のメイントピックである例の分析に直接行きます。クラスグラフは、メタスペースにロードされたクラスの数を示し、約73,000オブジェクトです。クラスインスタンスについてではなく、クラス自体、つまりクラス<？>タイプのオブジェクトについて話しているという事実に注意を向けたいと思います。グラフから、個々のタイプClassAまたはClassBのインスタンスがいくつメモリにロードされているかは明らかではありません。おそらく、何らかの理由でクラスAタイプの同一クラスの数が増加しますか？以下で説明する例では、73,000の一意のクラスは絶対に正常な状況であったと言わなければなりません。



事実、この記事の著者が参加したプロジェクトの1つでは、辞書システムと呼ばれるドメインエンティティ（1Cなど）のユニバーサル記述、および特定の顧客または特定の事業領域に合わせてシステムをカスタマイズするアナリストのためのメカニズムが開発されました。特別なエディターを介して、テーブルのレベルではなく、「ドキュメント」、「アカウント」、「従業員」などの概念で動作する、新しいエンティティと変更する既存のエンティティを作成することによってビジネスモデルをモデル化する機会がありました。システムカーネルは、エンティティデータ用のリレーショナルDBMSにテーブルを作成しました。ユニバーサルシステムでは、属性値を履歴に保存でき、データベースに追加のサービステーブルを作成する必要があるため、エンティティごとにいくつかのテーブルを作成できました。



ORMフレームワークを使用しなければならなかった人々は、テーブルについて話すことによって記事のメイントピックから気を取られて、著者が何についてであるかをすでに推測していると思います。プロジェクトはHibernateを使用し、テーブルごとにEntityBeanクラスが必要でした。同時に、アナリストによるシステムの作業中に新しいテーブルが動的に作成されたため、Hibernate Beanクラスが生成され、開発者が手動で作成することはありませんでした。そして、次世代ごとに、約5万から6万の新しいクラスが作成されました。システム内のテーブルは大幅に少なくなりましたが（約5〜6千）、テーブルごとに、エンティティBeanクラスだけでなく、多くの補助クラスも生成され、最終的に共通の数値になりました。



作業の仕組みは以下のとおりです。システムの開始時に、エンティティBeanクラスと補助クラス（以下、単にBeanクラス）がデータベース内のメタデータに基づいて生成されました。システムの実行中に、Hibernateセッションファクトリがセッションを作成し、セッションがBeanクラスオブジェクトのインスタンスを作成しました。構造を変更（テーブルの追加、変更）すると、Beanクラスが再生成され、新しいセッションファクトリが作成されました。再生後、新しいファクトリは新しいBeanクラスを使用する新しいセッションを作成し、古いファクトリとセッションは閉じられ、古いBeanクラスはHibernateインフラストラクチャオブジェクトから参照されなくなったため、GCによってアンロードされました。











ある時点で、ビンクラスの数が次の再生ごとに増加し始めるという問題が発生しました。明らかに、これは、使用されるべきではなくなった古いクラスのセットが、何らかの理由でメモリからアンロードされなかったという事実によるものでした。システムのこの動作の理由を理解するために、Eclipse Memory Analizer（MAT）が役に立ちました。

メモリリークを見つける

MATはメモリダンプを処理して、潜在的な問題を見つけることができますが、最初にこのメモリダンプを取得する必要がありますが、実際の環境では、ダンプの取得には一定の微妙な違いがあります。

メモリダンプの削除

前述のように、メモリダンプは、[







バット]ボタンを押すことでVMから直接削除できます。ダンプのサイズが大きいため、VMはこのタスクに対応できず、[ヒープダンプ]ボタンを押してからしばらくするとフリーズする場合があります。さらに、jmxを介してVMに必要な製品アプリケーションサーバーに接続できるということはまったく事実ではありません。この場合、jMapと呼ばれる別のjvmユーティリティが役に立ちます。コマンドラインで、jvmが実行されているサーバー上で直接実行され、追加のダンプパラメータを設定できます



。jmap- dump ：live、format = b、file = / tmp / heapdump.bin 14616 –dump：live



パラメータは非常に重要です。参照されなくなったオブジェクトを除いて、サイズを大幅に縮小できます。



もう1つの一般的な状況は、jvm自体がOutOfMemoryErrorでクラッシュするため、手動ダンプが不可能な場合です。この状況では、-XX：+ HeapDumpOnOutOfMemoryErrorオプションが助けになり、それに加えて、-XX：HeapDumpPathがあり、キャプチャされたダンプへのパスを指定できます。



次に、Eclipse MemoryAnalyzerを使用してキャプチャされたダンプを開きます。ファイルのサイズは大きくなる可能性があるため（数ギガバイト）、MemoryAnalyzer.iniファイルに十分なメモリを提供する必要があります：



-Xmx4096m

MATを使用して問題を特定する

それで、ロードされたクラスの数が初期レベルと比較して倍数増加し、ガベージコレクションを強制的に呼び出した後でも減少しない状況を考えてみましょう（これはVMの対応するボタンを押すことで実行できます）。



上記では、Beanクラスを再生成するプロセスとその使用について概念的に説明しました。より技術的なレベルでは、次のようになりました。

 

• すべてのHibernateセッションが閉じられます（SessionImplクラス）
• 古いセッションファクトリ（SessionFactoryImpl）が閉じられ、LocalSessionFactoryBeanからの古いセッションファクトリへの参照がリセットされます
• ClassLoaderが再作成されます
• ジェネレータークラスの古いBeanクラスへの参照は無効になります
• Beanクラスが再生成されます

古いBeanクラスへの参照がない場合、ガベージコレクション後にクラスの数を増やすことはできません。



MATを実行し、以前に取得したメモリダンプファイルを開きます。ダンプを開いた後、MATはメモリ内のオブジェクトの最大のチェーンを表示します。







Leak Suspectsをクリックすると、詳細



 が表示されます。それぞれ265 Mの円の2つのセグメントは、SessionFactoryImplの2つのインスタンスです。それらのインスタンスが2つある理由は明らかではなく、ほとんどの場合、各インスタンスはエンティティBeanクラスの完全なセットへの参照を保持しています。 MATは、潜在的な問題について次のように通知します。





 

問題容疑者3は実際には問題ではないことにすぐに気づきました。プロジェクトは独自の言語のパーサーを実装しました。これはSQL上のマルチプラットフォームアドオンであり、テーブルではなくシステムエンティティを操作でき、121Mはクエリキャッシュを占有します。



SessionFactoryImplの2つのインスタンスに戻りましょう。 [クラスの複製]をクリックして、各エンティティBeanクラスのインスタンスが実際に2つあることを確認します。つまり、エンティティBeanの古いクラスへのリンクは残り、ほとんどの場合、これらはSesssionFactoryImplからのリンクです。このクラスのソースコードに基づいて、Beanクラスへの参照をclassMetaDataフィールドに格納する必要があります。



Problem Suspect 1をクリックし、次にSessionFactoryImplクラスをクリックして、コンテキストメニューから[List Objects]-> [With outgouingreferences]を選択します。このようにして、SessionFactoryImplによって参照されるすべてのオブジェクトを確認できます。







classMetaDataオブジェクトを展開し、エンティティBeanクラスの配列が実際に格納されていることを確認します。







ここで、ガベージコレクタがSessionFactoryImplの単一インスタンスを破棄できない原因を理解する必要があります。 Leak Suspects-> Leaks-> Problem Suspect 1に戻ると、SessionFactoryImplへのリンクにつながるリンクのスタックが表示されます。



 



HTTPセッションのコンテキストを含むSessionInfoImplBeanのentityManager変数には、Hibernate SessionImplオブジェクトをキーとして使用する配列dbTransactionListenersが含まれており、セッションはSessionFactoryImplを参照していることがわかります。



実際には、セッションオブジェクトは特定の目的でdbTransactionListenersにキャッシュされており、Beanクラスが再生成される前は、それらへの参照がこの配列に残っている可能性があります。次に、セッションは、すべてのBeanクラスへの参照の配列を格納するセッションファクトリを参照しました。さらに、セッションはエンティティクラスのインスタンスへの参照を保持し、Beanクラス自体を参照していました。



したがって、問題へのエントリポイントが見つかりました。dbTransactionListenersからの古いセッションへの参照であることが判明しました。エラーが修正され、dbTransactionListeners配列がクリアされ始めた後、問題が修正されました。

Eclipseメモリアナライザの機能

 

したがって、Eclipse MemoryAnalyzerでは次のことができます。

• オブジェクトのどのチェーンが最大量のメモリを占有しているかを調べ、これらのチェーンへのエントリポイントを決定します（リークの疑いがある）
• すべての着信オブジェクト参照のツリーを表示します（累積ポイントへの最短パス）
• オブジェクトのすべての送信参照のツリーを表示します（[オブジェクト]-> [オブジェクトのリスト]-> [送信参照あり]）
• 異なるClassLoaderによってロードされた重複クラスを参照してください（重複クラス）