Java でのオブジェクト プールの最新の実装を探しています。apache commons のものを見ることができますが、正直に言うと、ジェネリックを使用するものと、より最近のバージョンの Java の並行性のものの方が好きです。
コモンズプールは本当にうまく機能していますか? コードはきれいに見えますが、ええと、醜いです。
カスタムの活性検証などを可能にするものが必要です。
ありがとう!
Java でのオブジェクト プールの最新の実装を探しています。apache commons のものを見ることができますが、正直に言うと、ジェネリックを使用するものと、より最近のバージョンの Java の並行性のものの方が好きです。
コモンズプールは本当にうまく機能していますか? コードはきれいに見えますが、ええと、醜いです。
カスタムの活性検証などを可能にするものが必要です。
ありがとう!
Apache Commons のものを見ることができますが、正直なところ、ジェネリックを使用するものと、より最近のバージョンの Java の並行性のものの方が好きです。
実際のところ、この種のプロジェクト (一般的なオブジェクト プール) は、最近ではほとんど必要とされていないため (オブジェクトの作成は安価です)、あまり人気がありません。これはおそらく、それらの多くが見られない理由を説明しています (実際、私は Commons Pool しか知りません)。
そうは言っても、ジェネリックが主な関心事である場合は、Commons Pool にパッチを当てることができます。POOL-83を参照してください。パッチが添付されています。
コモンズプールは本当にうまく機能しますか? コードはきれいに見えますが、ええと、醜いです。
いくつかの既知のバグ(4 つ) がありますが、私の知る限りでは動作します。最後の文についてですが、もっと良いものを書けると思うなら、そしてそのための時間があれば、それをやってみませんか?
カスタムの活性検証などを可能にするものが必要です。
無限の数のオプションはありません。また
Commons Pool は、あなたのプロジェクトの良い候補です。
必要な機能を知らずに推奨するのは難しいです。
プール内のオブジェクトの数が固定されている場合は、@codedevourが言及した質問からこの例BlockingQueue
のようにを使用できます
プールする値をキーに関連付けることができる場合は、 GuavaのMapMakerを使用できます
ConcurrentMap<Key, Connection> connections = new MapMaker()
.concurrencyLevel(32)
.softKeys()
.weakValues()
.expiration(30, TimeUnit.MINUTES)
.evictionListener(
new MapEvictionListener<Key, Connection>() {
public onEviction(Key key, Connection connection) {
connection.close();
}
});
.makeComputingMap(
new Function<Key, Connection>() {
public Connection apply(Key key) {
return createConnection(key);
}
});
KBOP をチェックアウトします。これは、単一のキーを単一のオブジェクトに、または単一のキーを複数のオブジェクト プールにブロックするスレッド セーフです。軽量で、追加の依存関係を追加しません。
さらに別のプール ( yapool ) には、リスナーを介してプール イベントに作用するオプションを備えた汎用プール実装が含まれています ( example )。これにより、プールの動作のカスタマイズ、機能の追加、およびプール リソースの使用状況の診断において多くの柔軟性が提供されます。または、プールの実装を拡張して、独自の目的の動作を追加することもできます (例)。プールの実装は既に相互に拡張されているため (基本 --> バインド --> プルーニング)、これは比較的簡単なはずです。
まず、単純なBoundPoolを使用して独自のファクトリを設定するか (前述のプール イベントの例の「LongFactory」を参照)、または単にObjectPoolを使用します。
Yapool には「同期された」ブロックがなく、非常に高速です。
これはあなたの質問に関連しているようです。おそらく、オブジェクトプールを自分で作成することを本当に検討する必要があります。この基本的な Java オブジェクト プールは機能しますか? .
プーリングは当初、特にオブジェクトの作成とガベージ コレクションのパフォーマンスの低下に対するチューニング アクションとして導入されました。最新の JVM > 1.4 では、典型的なビジネス アプリケーションでメモリ管理を最適化するためにプーリングは不要になりました。ガベージ コレクターのパフォーマンスに悪影響を及ぼすことさえあります。すべてのメソッド呼び出しで何百万ものインスタンスを作成するなどの特別なケースでは、それでも効果がある可能性があります。
ただし、インスタンス プーリングは、カスタムの "ポスト コンストラクション" が遅いオブジェクトには依然として興味深いものです。場合によっては、オブジェクトの作成後にいくつかの依存関係を注入したり、構成を読み取ったりする必要があります。これは遅くなる可能性があり、何度も何度も実行する必要はありません。このような場合、オブジェクト プーリングによって全体的なパフォーマンスが向上します。
Adam Bien --オブジェクト プーリングは依然として有用である - 理由はまったく異なる
commons Pool Framework の強化についてどう思いますか? リファクタリングを行って一般的な部分を追加することもできます。他の人にとっても良いでしょう。
http://code.google.com/p/spf4j/にオブジェクト プールの実装があります 。Apache Commons のものよりも優れた実装だと思います。コードはそれほど醜くなく、パフォーマンスも優れています...
ジェネリック側では、非ジェネリック ライブラリを使用して、キャストを処理する非ジェネリック ライブラリにアクセスするために使用するラッパーを作成してみませんか? そうすれば、キャストが行われる場所が 1 か所になり、少なくともコードが少しクリーンアップされます。
プールは従来の方法であり、キャッシュは最新の方法です。そして、キャッシュの最新の実装が数多くあります。
これら 2 つの違いについては、http: //www.informit.com/guides/content.aspx?g=java&seqNum=104を参照してください。
私の見解では、キャッシュ ライブラリを使用してオブジェクトをプールできますが、その逆はできません。キャッシュからオブジェクトを取得した後、オブジェクトを再初期化することを忘れないでください。では、1 つだけですべてを達成できるのに、わざわざ 2 つの異なる動物 (キャッシュとプール) を用意する必要はありません。