19

約 15 のメソッドで構成される Java プログラムがあります。また、これらのメソッドは、プログラムの実行中に非常に頻繁に呼び出されます。現時点では、すべてのメソッドで新しい接続を作成し、それらのステートメントを呼び出しています (データベースはネットワーク上の別のマシンにセットアップされています)。

私が知りたいのは、メインメソッドで接続を1つだけ作成し、それを接続オブジェクトを必要とするすべてのメソッドに引数として渡す必要があるかどうかです。作成する代わりに、プログラム内の接続オブジェクトの数を大幅に減らすためです。すべての方法で非常に頻繁に接続を閉じます。

現在の設計ではリソースをあまり効率的に使用していないのではないかと思います。このプログラムが将来大きく成長する可能性があることを考えると、改善の余地はたくさんあります。

4

5 に答える 5

23

はい、毎回新しい接続を作成するのではなく、接続の再利用を検討する必要があります。通常の手順は次のとおりです。

  • データベースが適切に処理できる同時接続数を推測してください (たとえば、データベース マシンの CPU ごとに 2 または 3 から始めて、これが少なすぎるか多すぎることがわかるまで、ディスクの状態に依存する傾向があります)。 -バインドされたクエリは)
  • この数の接続のプールを作成します。基本的には、各メソッドの最初に「次の空き接続」を要求し、各メソッドの最後にプールに「戻す」ことができるクラスです
  • getFreeConnection() メソッドは、利用可能な場合は無料の接続を返す必要があります。そうでない場合は、(1) 許可することを決定した接続の最大数まで、新しい接続を作成するか、(2) 最大接続数が既に作成されている場合は、その接続を返します。 、いずれかが解放されるのを待ちます
  • 接続を管理するには Semaphore クラスをお勧めします。私は実際に私の Web サイトに、セマフォを使用したリソース プールの管理に関する短い記事を掲載しています。

いくつかの実際的な考慮事項:

  • 最適なパフォーマンスを得るには、実際に接続を使用してクエリを実行していないときに、接続を「占有」しないように注意する必要があります。プールから一度接続を取得して、それをさまざまなメソッドに渡す場合は、誤ってこれを行っていないことを確認する必要があります。
  • 接続をプールに戻すことを忘れないでください! （試してみてください/ついにあなたの友達がここにいます...）
  • 多くのシステムでは、接続を「永久に」開いたままにしておくことはできません。O /S は、最大時間が経過すると接続を閉じます。したがって、「接続をプールに戻す」メソッドでは、長い間使用されてきた接続を「破棄」することについて考える必要があります(たとえば、実際の JDBC の周りにラッパー オブジェクトを配置するなどして、覚えておくためのメカニズムを構築します)。このようなメトリックを保存するために使用できる接続オブジェクト)
  • 準備済みステートメントの使用を検討することをお勧めします。
  • 時間が経つにつれて、おそらく接続プールのサイズを微調整する必要があります
于 2009-01-23T05:10:28.273 に答える
9

接続を渡すことも、Jakarta Database Connection Pooling などを使用することもできます。 http://commons.apache.org/dbcp/

于 2009-01-23T03:15:52.700 に答える
8

そのためには接続プールを使用する必要があります。

そうすれば、接続を要求し、終了したら解放してプールに戻すことができます

別のスレッドが新しい接続を必要としていて、その接続が使用されている場合は、新しい接続を作成できます。他のスレッドが接続を使用していない場合は、同じものを再利用できます。

このようにして、何らかの方法でアプリをそのままにして (接続をすべて通過させずに)、リソースを適切に使用することができます。

残念ながら、ファースト クラスの ConnectionPools は、スタンドアロン アプリケーションで使用するのはあまり簡単ではありません (アプリケーション サーバーのデフォルトです)。おそらく、マイクロコンテナ ( Sping など) または優れたフレームワーク ( Hibernate など) を使用できます。

ただし、最初からコーディングするのはそれほど難しくありません。

:)

この Google 検索は、使用方法の詳細を見つけるのに役立ちます。

ザッと読みます

于 2009-01-23T03:14:36.573 に答える
4

多くのJDBCドライバーは接続プールを実行するため、この場合、追加のプールを実行する利点はほとんどありません。JDBCドライバーのドキュメントを確認することをお勧めします。

接続プールへの別のアプローチは

  • 同期アクセスを使用して、すべてのデータベースアクセスに対して1つの接続を確立します。これは同時実行を許可しませんが、非常に単純です。
  • 接続をThreadLocal変数に格納します（initialValue（）をオーバーライドします）。これは、固定数のスレッドが少ない場合にうまく機能します。

それ以外の場合は、接続プールを使用することをお勧めします。

于 2009-01-24T13:14:08.453 に答える
1

アプリケーションがシングルスレッドの場合、または単一のスレッドからすべてのデータベース操作を行う場合は、単一の接続を使用しても問題ありません。他の理由で複数の接続が必要ないと仮定すると、これは最も単純な実装になります。

ドライバーによっては、スレッド間で接続を共有することも可能です。ドライバーがスレッドセーフについて嘘をつかないと信頼している場合は、これも問題ありません。詳細については、ドライバーのドキュメントを参照してください。

通常、「接続」の下のオブジェクトは複数のスレッドから安全に使用できないため、一般にスレッド間で ResultSet や Statement オブジェクトなどを共有することはお勧めできません。最良のポリシーは、それらを作成した同じスレッドで使用することです。これらのオブジェクトは通常、あまり長く保持されないため、これは通常は簡単です。

于 2009-01-24T12:18:43.853 に答える