1

JBoss 4.2 は @EJB インジェクションをサポートしていないため、サーブレットが必要とする EJB を参照するために JNDI ルックアップを使用しています。

このタイプのルックアップが原因で、JVM の Permgen 非ヒープ メモリが増大するのではないかと懸念しています。

私が理解しているように、JNDI は動的なクラスローディングの一種であるため、クラスローダー リークが発生している可能性があります。

私の質問は、以下のサーブレット コードが、時間の経過とともに Permgen メモリ リークを引き起こしている可能性があるということです。

また、ルックアップ後に InitialContext で明示的に close() メソッドを呼び出す必要がありますか? ここで (サーブレットで) インスタンス化される方法が原因で、GC が InitialContexts を期待どおりにクリーンアップしない可能性はありますか?

ありがとうございました。

public class MyServlet extends HttpServlet {

// JBoss 4.x does not support @EJB injections in servlets (see jndi lookup below)
@EJB
private MyService myService;

private static final String SERVICE_JNDI_NAME = "MyServiceBean";

private Logger log = Logger.getLogger(this.getClass().getPackage().getName());


public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

try {
    // JBoss 4.x does not support @EJB injections in servlets
    InitialContext ctx = new javax.naming.InitialContext();
    myService = (MyService) ctx.lookup(SERVICE_JNDI_NAME);
} catch (NamingException e) {
    log.warn("NamingException trying to lookup MyService in context");
    throw new RuntimeException(e);
}

...

RequestDispatcher requestDispatcher = request.getRequestDispatcher("/page.jsp");
requestDispatcher.forward(request, response);
}

}

4

1 に答える 1

0

JNDIは、ディレクトリ ルックアップ サービスであり、Java Enterprise Edition アプリケーション サーバーのコア テクノロジーです。実装にバグがあるか、異常な使用パターンのアプリケーションを使用していない限り、JNDI によってロードされたクラスは最終的に安定するはずです。

いずれにせよ、ヒープ ダンプ アナライザーを使用することを強くお勧めします。アプリケーションの実行中にいくつかのスナップショットを作成し、permgen が増加し続けるときに何が追加されるかを確認します。この情報は、問題の内容を直接示したり、根本原因をより小さな領域に絞り込むのに役立ちます。

于 2011-03-04T21:18:59.223 に答える