6

私の環境では、PermGen で OOM を常に検出しています。

  1. ジャワ6
  2. jboss-4.2.3
  3. 大規模な Web アプリケーションではない

String.intern() の問題については知っていますが、それを十分に活用する価値はありません。MaxPermGen のサイズを大きくしても、力はかかりませんでした (128 Mb から 256 Mb へ)。

PermGen の OOM を呼び出すその他の理由は何ですか? そのような状況では、どのような調査シナリオが最適ですか (戦略、ツールなど)?

助けてくれてありがとう

4

2 に答える 2

13

このメモを参照してください

  • JDBC ドライバーを (Tomcat のドキュメントにあるように) common/lib に配置し、WEB-INF/lib には配置しません。
  • tomcat がすでにブートストラップしているため、commons-logging を WEB-INF/lib に配置しないでください。

新しいクラス オブジェクトは PermGen に配置されるため、ますます多くのスペースを占有します。PermGen スペースをどれだけ大きくしても、十分な数のデプロイを行うと、必然的に上限に達します。あなたがする必要があるのは、そのサイズを安定させることができるように、PermGen をフラッシュするための措置を講じることです。このクリーニングを処理する 2 つの JVM フラグがあります。

-XX:+CMSPermGenSweepingEnabled

この設定には、ガベージ コレクションの実行に PermGen が含まれます。デフォルトでは、PermGen スペースはガベージ コレクションに含まれません (したがって、無制限に大きくなります)。

-XX:+CMSClassUnloadingEnabled

この設定は、PermGen ガベージ コレクション スイープに、クラス オブジェクトに対してアクションを実行するように指示します。デフォルトでは、ガベージ コレクション中に PermGen スペースにアクセスしている場合でも、クラス オブジェクトは免除されます。

于 2011-04-12T12:38:34.803 に答える
8

通常、クラスローダーリークが発生しているときにアプリケーションを再デプロイすると、このエラーが発生します。これは、古いバージョンが残っている間にすべてのクラスが再度ロードされることを意味するためです。

2つの解決策があります：

  • アプリケーションを再デプロイする代わりに、アプリサーバーを再起動します-簡単ですが、面倒です
  • プロファイラーを使用してリークを調査し、修正します。残念ながら、クラスローダーのリークを特定するのは非常に難しい場合があります。
于 2011-04-12T12:39:35.810 に答える