0

現在、独自の接続プールクラスを実装したJavaEEアプリケーションがあります。私が使用する各メソッドは、単純なクエリ（StatementおよびResultSet）を実行します。JDBC / my poolを使用する各メソッドのfinallyブロックで、最初にResultSetを閉じてから、本やオンラインで実行する必要があることを示す多くのリソースでステートメントを閉じます。最後に、接続をプールに戻します。

JVMのメモリを監視していると、接続プールを介してJDBCを使用する呼び出しを行った後、メモリが実際に解放されないか、解放するのに非常に長い時間がかかることに気付きました。ガベージコレクションの設定を確認し、gencon（IBM WebSphere）を使用しています。これは、オンラインの多くのリソースでも非常に優れていることを示しています。私は自分のアプリケーションでもSpringFrameworkを使用しています。

私が書いた接続プールクラスは非常に単純です。初期化時に、データベースへの特定の数の接続を作成し、それらをキューに追加します（単純なベクトルだけで別の実装を試しましたが、メモリでも同じ結果になります）。接続をリクエストすると、利用可能な接続があるかどうかがチェックされ、利用可能な場合は発信者に接続が提供されます。最後に、それを元に戻し、キュー/ベクターに戻します。

これについて他に何かできることはないかと思います。代わりにSpringFrameworkに接続プールを処理させる必要がありますか、それともメモリをより適切に処理する何か他のものがありますか？私にはそれは理にかなっていますが、接続プールの実装についてはあまり詳しくありません。すべてのリソースは、私が行っていることを実行すると言っていますが、組み込みのプーリング実装を使用している可能性があると想定しています。接続を閉じることが機能することは知っていますが、これはカスタムプールソリューションであるため、実際にはそれを行うことはできません。

ありがとう！

4

2 に答える 2

4

アプリケーションはWebSphereアプリケーションサーバー内で実行されていますか？データソースを自分で作成するのではなく、アプリサーバーから取得していますか？その場合、接続とステートメントはすでにプールされているので、自分でプールする必要はありません。

于 2012-10-29T22:33:23.310 に答える
2

OK、まず最初に：非常に正当な理由がない限り、独自の接続プールメカニズムを実装することは不必要なリスクの練習です。そこから選択できる接続プールメカニズムは単純にたくさんあります。Springがその1つであり、JakartaのDBCPがもう1つです。接続プールにサードパーティのユーティリティを使用するオプションがある場合は、それを実行してください。コンテナー内で実行している場合は、コンテナーに作業を任せます（WebSphereは、さまざまな「ヘルパー・クラス」を介して、これを既に実行しています）。

あなたが経験している症状に関して：メモリが解放されていないという事実は、メモリリークがあることを意味するものではありません。参照されていないオブジェクトインスタンスを実際に解放するかどうか、またいつ解放するかは、JVM次第です。OutOfMemoryエラーも発生していますか？

いくつかのヒープダンプ（JDBCリソースのリリース直後）を発行して、そこで何が起こっているかを確認することから始めます。

あなたが書いたコードについて-コードを投稿しないと、そこに隠れたバグがあるかどうかを推測するのは非常に困難です。しかし、あなたが説明しているフローは正しいように見えます。

于 2012-10-29T22:32:46.603 に答える