2

これはおそらく以前に何度も尋ねられたことでしょうが、実際の修正はまだ見ていません。

私の日常の開発環境は次のとおりです: 1. NetBeans (最新)、2. Glassfish (NB にバンドルされている最新)、3. JPA、JSF、JAXB、Jersey for JAX-RS

私のプロジェクトには約 600 のクラスがあり、それらは 2 つの EJB プロジェクトと 1 つの WAR プロジェクトにまたがり、すべて EAR 内にあります。

私は最新のJDK 7（OS X上）を使用しており、悪名高い「PermGenスペース」バグを1時間ごとに取得しています。1 分間に 3 回の増分再デプロイを行っている場合、次のいずれかの前に短時間しか作業できないとします。

  • Glassfish は PermGen スペースを使い果たしたので、プロセスを強制終了する必要があります。
  • 最大permgenスペースを増やしたため、展開が非常に遅くなります（SOに関する数十の回答から推奨されているように）

多くの場合、唯一の解決策はグラスフィッシュを 30 分ごとに殺すことです。これは間違いなく、古いクラスを取り除くのではなく、新しい増分再デプロイごとに新しいクラスをロードするだけのどこかのバグによるものです。これはJDK 7で修正されるはずだと思っていましたか？

これは、この種の開発環境における長年のバグであり、私が 5 年以上 Java 開発を行ってきたにもかかわらず、それがまだ続いていることにかなりショックを受けています。それはとても苛立たしく、信じられないほど非生産的です。

(誰かが permgen スペースを増やすことを提案する直前に、私がそれを試したことを信じてください。それが「解決」する唯一のことは、避けられないことを長引かせることです。再デプロイには最悪の場合で最大 400 秒かかることを見てきました。再デプロイには時間がかかるはずです。このサイズのプロジェクトでは 5 ～ 6 秒、それ以上はかかりません。)

編集:次の手順の後、Glassfish プロセスで jmap と jhat を実行しました。

  1. グラスフィッシュを開始
  2. EA をデプロイする
  3. EA のアンデプロイ
  4. 次に、jmapでヒープダンプを行いました

すべてのクラス (アンロードされているはず) がまだロードされていることがわかりました。これを読んでいる方にとって有益な情報となれば幸いです...

4

2 に答える 2

3

確かにそれはバグであり、簡単な解決策はないと思います。（もしあれば、おそらくあなたはすでにそれを持っていました）。

試すことができること:たとえば、いくつかのホット コード置換ツールJRebelを使用します。この方法では、常に展開する必要はありません。代わりに、このツールは.classファイルの変更を監視します (構成している場合は他の Web リソースも監視します)。実行中の JVM 内のクラス定義を置き換えます。クールですね。

これはJava エージェントとして機能し、JVM の開始時に開始されます。

このソリューションには 3 つの欠点があります: 展開が少し遅い、デバッグが難しい、プロプライエタリ ソフトウェアであること (ただし、コストはあまりかかりません)。

于 2013-02-07T11:55:45.013 に答える
0

Netbeans + Glassfish で開発し、「Deploy on Save」を使用している場合、プロジェクトが再デプロイされたときに、アプリケーション内にパッケージ化されたライブラリがアンロードされないことがわかりました。これにより、GF の速度が低下し、すぐにメモリ不足になります。

すべてのコンパイル時ライブラリの「パッケージ」の選択を解除して、まだ Glassfish クラスパスにないものを domainX/lib ディレクトリに配置してみてください。

確かではありませんが、これは GLASSFISH-17449 または GLASSFISH-16283 に関連している可能性があります。

于 2013-11-03T20:23:04.857 に答える