重複とマークする前に、完全に読んでください。
perm gen OOMの問題を解決する具体的な方法を見つけるために、こことGoogleで多くのブログ/投稿を調べました。しかし、これまでのところ、それらのどれも問題を解決していません。これが私のユースケースです：
- 多くの個々のプロジェクト *.war ファイルがデプロイされている tomcat サーバーがあります。
- perm gen の問題は最初は問題ではなかったので、モジュールを追加し続けました。
- 最近 Perm Gen - OOM の問題に直面しましたが、JVM パラメータの perm gen メモリを増やすことで問題を解決しました。
- モジュールを追加し続けた後、ある晴れた日に再びこの問題が発生しました。
- 一時的な解決策として、サーバーを再起動し続けますが、問題は 1 週間程度発生しません。
恒久的な解決に向けたアプローチ:
- JVM パラメータで perm gen を増やすという有名なアプローチは、もはやオプションではありません。
- perm gen のメモリ リークを引き起こしているコードの問題である可能性があることを理解しています。しかし、膨大なコードベースをレビューすることはほとんど不可能です。
あなたの助けが必要です:
ここで悪いコードを理解するための無料のツールまたは簡単な方法 (またはヒント) はありますか?
私たちのコード モジュールの 1 つの観察:
- 各モジュール *war で、80% の一般的な jar が使用されていることを観察しましたが、それらはすべて、各 war に個別にバンドルされています。
ここで私の分析（間違っているかもしれません）
- Tomcat サーバーは、モジュール war ごとに個別の app-classloader を使用する必要があります。
- したがって、jar からの 2 つの同じクラス (たとえば、別の war にある同じ abcd.jar) が perm gen 領域にロードされます。それらは互いに見えません (Java セキュリティ モデルのため)。
- つまり、アプリごとに、クラスの多くのコピーが読み込まれる可能性があります (それ以外の場合は一般的になる可能性があります)。
あなたの助けが必要です:
上記の分析は正しいですか？
共通の jar をいくつかの共通の lib パスに移動し、そのパスを tomcat 共有 lib 構成に含めると、役に立ちますか? 私のターゲットは、perm gen 領域にロードされたクラスの 1 つのコピーだけです。
最後に - 他にどのような方法を考えればよいでしょうか?