0

現在、作成したアプリケーションのメモリ リークを調査しています。ヒープ ダンプを分析した後、MyFaces CODI の奇妙な動作に焦点を合わせました。

ViewAccessScope を多用し、最近コードを修正して、対応するインスタンスのハッシュコードと共に @PostConstruct および @PreDestroy コールバックをログに記録しました。

PostConstruct コールバックは、たとえば、Bean を使用していないまったく別のビューから来た場合など、期待どおりに実行されます。@PreDestroy コールバックが呼び出されないことは、私を悩ませています (私は (私が思うに) 次のビューのどこにも Bean への参照がないことを確認しましたが)。

これをさらに混乱させているのは、それぞれが ViewAccesScoped Bean によってサポートされている 3 つのビューを持つ単純で小さなテスト プログラムを作成したという事実です。ビューを変更すると、移動元の Bean が、移動先のビューの Bean 内のどこにも参照されていないため、期待どおりに Bean が破棄されます。

したがって、私の質問は、ViewAccessScoped Bean のクリーンアップ/破棄動作に関して考慮すべき Bean 参照以外の要因はありますか?

JBoss AS Final 7.1.1 でバージョン 1.0.5 の MyFaces CODI を使用しています。

4

1 に答える 1

0

私はここで私自身の質問に答えるつもりです-

問題の Bean が決して破棄されない理由は、スコープが解除されることのないオブジェクトを実際に共有しているためです。これは、カスタム CDI ポータブル拡張によって提供されるオブジェクトです。

そのため、CODI は実際には意図したとおりに機能しています。メモリ リークは CODI ではなく、カスタム CDI 拡張機能が原因です。

私が見たように、問題は、拡張機能によって提供されるオブジェクトがプロキシされていないことですが、CDI 拡張機能によって作成されたインスタンスは、消費するすべての Bean で共有されています。

于 2015-02-22T23:57:21.457 に答える