問題タブ [permgen]

私のプロセスでは、新しい Thread オブジェクト (実際には Thread のサブクラス) を継続的に作成し (1 秒あたり最大数まで)、それを実行して正常に終了します。

たとえば、プロセスが 25 日間稼働している場合、プロセスは hprof を残して終了する可能性があることに気付きました。これは OOM を意味します。しかし、ヒープ ダンプは、ヒープに割り当てられたメモリに比べて小さいため、おそらく PermGen OOM であり、原因を突き止めようとしています。

-XX:+HeapDumpOnOutOfMemoryError を禁止する特別な jvm パラメータは使用していません。

文字列のインターンを完全に無効にすることはできますか? あまり参考にならないかもしれませんが、ただの感想です。たとえば、jvm のチューニング中に、perm gen のサイズを制御するときに役立つポイントが少なくとも 1 つあります。

たとえば、私が OSGI フレームワークを配布し、誰でも独自のバンドルをいくつでも追加でき、各バンドルの文字列インターンがチューニング パラメーターを完全に台無しにする可能性がある場合などです。(もちろん、特定の固定ディストリビューションでチューニングを行う必要があることはわかっていますが、それでも...)

何かご意見は！！

Glassfishインスタンスは、しばらくの間2週間ごとにダウンしましたjava.lang.OutOfMemoryError: PermGen space。PermGenスペースを512MBに増やし、メモリ使用量のダンプを開始しましjstat -gcた。2週間後、PermGenスペースが着実に増加していることを示す次のグラフを思いつきました（x軸の単位は分、y軸はKBです）。

私はエラーを特定できるある種のプロファイリングツールを探し回ってみました。ここでSOが言及したjmapのスレッドは、非常に役立つことがわかりました。からダンプされた約14000行のうちjmap -permstats $PID、約12500行が含まれgroovy/lang/GroovyClassLoader$InnerLoaderており、独自のGroovyコードまたはGroovy自体からのある種のメモリリークを示しています。Groovyは関連するコードベースの1％未満を構成していることを指摘する必要があります。

以下の出力例：

では、どのコードがこれを引き起こしているのかをもっと知るにはどうすればよいですか？

この記事から、Groovyコードがどこかに動的にクラスを作成していると推測します。そして、jmapからのダンプから、死んだオブジェクト/クラス（？）のほとんどが同じparent_loaderを持っていることがわかりますが、このコンテキストでそれが何を意味するのかはわかりません。ここから先に進む方法がわかりません。

補遺

後発者の場合、受け入れられた回答は問題を解決しないことを指摘する価値があります。クラス情報をあまり保存しないことで、再起動するまでに必要な期間を10倍に延長するだけです。私たちの問題を実際に修正したのは、それを生成したコードを取り除くことでした。メソッドとクラスのアノテーションとしてGroovyを使用してカスタム制約をスクリプト化できる、検証（契約による設計）フレームワークOValを使用しました。プレーンJavaで明示的な事前条件と事後条件を優先してアノテーションを削除するのは退屈でしたが、それで作業は完了しました。OVal制約がチェックされるたびに、新しい匿名クラスが作成されていて、何らかの形で関連するクラスデータがメモリリークを引き起こしていたのではないかと思います。

Javaオブジェクトのサイズに関するQ＆Aはたくさんありますが、これは非常に簡単に理解できます。しかし、PermGenスペースのJavaクラスのサイズについて疑問に思っています。

これについて疑問に思う理由は、私がコードジェネレーターを作成していて、多くのクラスを生成しているためです。基本的に、データベース内のすべてのテーブル/ビューに対して2つのクラスを生成しています。ここで、外部キーの関係もモデル化したいと思います。複雑でシリアル化可能なオブジェクト構造を維持するのではなく（一意のキーを持つテーブルが、他の外部キーを持つ他のテーブルに属する複数の外部キーによって参照されるなど）、1つのクラスごとUNIQUE KEYに1つのクラスを生成することをお勧めします。 FOREIGN KEY。

これが私の質問です：

1. これを使用して、クラスローダーとPermGenスペースにどのくらいのオーバーヘッドを作成しますか？
2. publicクラス、staticクラス、privateメンバークラスに違いはありますか？
3. ソースコードで外部キー情報を生成するためのより良い方法がわかりますか？

プロジェクトがある場合、xtext 1.0.2 で eclipse モデリング helios SR2 が起動時にクラッシュするという問題があります。Eclipse を更新しようとすると、クラッシュします。ワークスペースを構築するとクラッシュします。

• 「Workbench Early startup」中に内部エラーが発生しました。java.lang.OutOfMemoryError: PermGen スペース

• !MESSAGE 「ソフトウェア サイトへの接続」中に内部エラーが発生しました。java.lang.OutOfMemoryError: PermGen スペース

私はWindows 7、64ビット、および32ビットのjdk 1.6.0_25_b06と32ビットのEclipseも使用しています。すべて 64 ビットでは、さらに多くの問題があります。

eclipse .ini ファイルを構成しようとしましたが、メモリ構成の正しいパラメーターが見つかりませんでした。

この問題について本当に助けが必要です。

前もって感謝します。

Java WebアプリケーションでいくつかのPermGen関連の問題を排除した後、私は次の点に到達しました。

• アプリケーションはTomcat6.0.32で実行され、Tomcat管理を使用しますDataSource
• でDataSource定義されています$TOMCAT_HOME/conf/context.xml
• アプリケーションが起動すると、アプリケーションが検索し、DataSourceその時点でのみDataSourceインスタンス化されます。
• BasicDataSourcecommons-dbcpからの実装はクラスをロードし、GenericObjectPoolクラスは次にjava.util.Timer
• タイマーTimerThreadは、GCルートであり、Webアプリケーションクラスローダーによってロードされるを開始します。

タイマー作成のスタックトレース

webappクラスローダーによってロードされているように表示されるタイマー

私の最初は、TomcatにDataSource熱心に初期化するように依頼し、それを一般的なクラスローダーに固定することでしたが、それを行う方法が見つかりませんでした。もちろん、これを解決する他の方法も受け入れています（ただし、JNDIにバインドされたリソースはそのままにしておく必要があります）。

TimerThreadがWebアプリクラスローダーにリンクされていることを確認するにはどうすればよいですか？

重複の可能性：
Java-文字列がインターンされているかどうかを教えてください。

jvmによって内部化された文字列のリストが必要です。これは、リテラルであるため、メソッドinternが呼び出されたためです。どうすれば生成できますか？

〜300のJUnitテストを実行し、Springコンテキストを使用しているときに、「java.lang.OutOfMemoryError：PermGenspace」が表示されます。それ以来、PermGenを食いつぶしているものを理解するのに苦労しています：

• 定常状態では、アプリは約90mのpermgenスペースを消費します
• 私はユニットテストのために-XX：MaxPermSize=256mを試しました-まだ不足しています
• 有効にする-XX:+TraceClassLoadingと-XX:+TraceClassUnloading、の前の最後の20〜30のテストを実行しているときに、追加の「読み込み」イベントが表示されませんOutOfMemoryError。

後者は、Classオブジェクト以外の何かがPermGenを埋めていることを示唆しているようです。もしそうなら、それは何でしょうか？たとえば、クラスインスタンスがPermGenに保存される状況はありますか？

これが私のVM情報です：

関連している

FWIW、この投稿を引き起こした私の問題の根本はやや些細なことであることが判明しました：Maven SurefireプラグインがVMをフォークするときにMAVEN_OPTS（またはmvnを実行するVMインスタンス）からVM設定を継承すると仮定しました-それは（ブーイング）しません。プラグインの構成でargLineを使用して明示的に指定する必要があります。HTH。

この問題について助けが必要です。なぜこれが起こっているのか、そしてそれを防ぐまたは回避する方法を説明してくれる人が必要です。

私たちはアプリの permgen メモリ スペースをどんどん高くしてきましたが、permgen 領域に食い込んでいる何らかのリークがあるかどうかを調べようとしています。ホット アンデプロイ/再デプロイ アクションは実行しませんが、動的および CGLIB 生成の両方のプロキシが多数あります。また、さまざまなユースケースをサポートするために、いくつかの複雑なクラスローダー ビットも実行しています。これらも、permgen の浪費の一因である可能性があるのではないかと疑っています。

そこで、実行中のアプリで jmap -permstat を実行し、permgen スペースを埋めている可能性があるものについて洞察を得たいと考えています。(permstat の出力から得られる可能性のある手がかりを追跡できるように、ライブ オブジェクトとデッド オブジェクトの両方で通常のヒープ ダンプも実行します)。

ただし、jmap permstat によってリストされた 2400 のクラスローダーのうち、ブートストラップ クラスローダーを除くすべてが「デッド」としてリストされます。アプリは間違いなくライブで動作しているため、これは意味がありません。

私の理解では、クラスローダがガベージ コレクションの対象である場合、jmap はそのクラスローダを「死んだ」と報告しますが、ここでは間違っているに違いありません...

私は何が欠けていますか？ここでの「死んだ」とはどういう意味ですか? グーグルで調べても、私がここで持っている誤解以外の多くの答えは得られません。