オブジェクトプールは、各インスタンスの作成にコストがかかる状況でアプリケーションが作成して手元に保管する特定のオブジェクトのコレクションです。良い例は、データベース接続またはワーカースレッドです。ライブラリーからの本のようなユーザーの場合、プールはインスタンスをチェックインおよびチェックアウトします。
通常、オブジェクトプーリングはJava EEアプリケーションサーバーによって処理されます。自分で行う必要がある場合は、Apacheのオブジェクトプールなどを使用することをお勧めします。自分で記述しないでください。スレッドの安全性などの問題複雑にすることができます。
ここにあります 弱いオブジェクト参照に関する優れた参照。
チェック common-pools
オブジェクトプーリングAPIを提供します
通常、作成にコストがかかるオブジェクトに使用されます。事前に作成されたN個のオブジェクトのプールを維持して再利用することを回避するために。
弱参照は、ガベージコレクタによって特別に処理される一種の参照変数です。
これにより、別の種類の到達可能性が導入されます。オブジェクトは次のとおりです。
- 強く到達可能（どのライフスレッドからもnormal参照のみで到達可能）
- 弱い到達可能性（強い到達可能性はないが、弱い参照（または弱い参照を含む複数の方法）によって到達可能）
- まったく到達できない
（Soft ReferencesとPhantom Referencesもあります。これらはここでは省略します-これらは同様に機能し、その間により多くのレベルを導入します。）
オブジェクトにまったく到達できない場合は、いつでもガベージコレクションを実行できます。オブジェクトに強く到達できる場合、そのオブジェクトはガベージコレクションできません。ガベージコレクターがオブジェクト（またはオブジェクトのグループ）への到達が弱い（複数の弱い参照による可能性がある）ことを検出した場合、これらのすべての参照を一度にクリアしますであり、オブジェクトに到達できません（およびガベージコレクション可能）。
（実際には、「到達不能」とコレクションの間にファイナライズステップがあり、最終的にオブジェクトが再び到達可能になる場合があります。）
弱い参照を使用するには、クラスJava.lang.ref.WeakReferenceを使用できます。実際の参照はこのクラスのプライベート変数にあり、コンストラクターでのみ設定でき、後でクリアできます。参照自体とは別に他のデータが必要な場合は、このクラスをサブクラス化できます。これは、参照がクリアされてもまだ存在しているはずです。
「コストのかかるインスタンス化を避ける」という意味のオブジェクトプールの場合、弱い参照は適切なツールではありません。
オブジェクトプールは、必要になるたびに再作成されるのではなく、リサイクルされるオブジェクトのコレクションです。
要件に応じて、このようなオブジェクトプールを実装する方法はいくつかあります。オブジェクトプールは、単純なオブジェクトでもパフォーマンスを向上させるために使用されていましたが、Java 5+ではそれほど役に立ちません。
ファイル、ソケット、データベース接続などの外部リソースに接続するオブジェクトにのみ使用することをお勧めします。
オブジェクトプールパターンの考え方は、ライブラリの考え方に似ています。図書館に行って本を購入するよりも借りる方が安くて簡単だということは誰もが知っています。同様に、プロセスがオブジェクトをインスタンス化するよりも借りるプロセスのほうが（システムメモリと速度に関して）安上がりです。したがって、プロセスが別のプロセスからオブジェクトを借用するこのようなプロセスは、オブジェクトプーリングと呼ばれます。
プールとオブジェクトプール：
基本的にプーリングとは、オブジェクトへのアクセスをクライアントが必要とする期間のみに制限することにより、リソースを効率的に利用することを意味します。
プールを介して使用率を上げると、通常、システムのパフォーマンスが向上します。
オブジェクトプーリングは、競合するクライアント間のオブジェクトの有限セットへのアクセスを管理する方法です。
つまり、オブジェクトプーリングは、異なるクライアント間でのオブジェクトの共有に他なりません。
オブジェクトプーリングではオブジェクトを共有できるため、他のクライアント/プロセスはオブジェクトを再インスタンス化する必要がなく（ロード時間を短縮します）、代わりに既存のオブジェクトを使用できます。
使用後、オブジェクトはプールに返されます。
弱い参照オブジェクト：
弱参照は、参照先と呼ばれるオブジェクトへの参照のホルダーです。
弱参照を使用すると、ガベージコレクションの妨げになることなく、参照先への参照を維持できます。
ガベージコレクターがヒープをトレースするときに、オブジェクトへの未解決の参照のみが弱い参照である場合、リファレントは、未処理の参照がなく、未処理の弱い参照がクリアされたかのように、GCの候補になります。
GCは常に、いくつかのアルゴリズムを使用して、到達範囲の弱いオブジェクトを回収します。
簡単な ObjectPool をJavaに実装しました。ここを参照してください弱いオブジェクト参照は使用しません。オブジェクトへの参照がある場合でもオブジェクトメモリを収集できるようにする弱いオブジェクト参照の目的。キャッシュにも使用できますが、オブジェクトプールよりもキャッシュの方が便利です。
（WeakReferenceではなく）SoftReferenceキャッシュについて質問しているのではないかと思います。現時点では見つかりませんが、プロプライエタリなJVMを実装した人から、使用しないようにと頼まれたことを覚えています。彼の主張は、これらのキャッシュは、ガベージコレクタの作成者があなたよりもキャッシュのニーズについて何らかの方法で知っていると想定しているということでした（決して真実であってはなりません）。
その日のことを思い出して、GCサイクルで十分なメモリが解放されなかった場合、その後すべてのSoftReferenceが一度にクリアされました。つまり、キャッシュが途方もなく（メモリ不足）フルから（同じように途方もない）完全に空になっています。代わりに、サイズ、年齢、またはその両方に基づいて機能するキャッシュ実装を選択します。つまり、ガベージコレクターを作成した人にキャッシュの動作の決定をオフロードするのではなく、独自の賢明なルールを与えることができるキャッシュ実装を選択します。何らかの理由で。