問題タブ [objectpool]

大量 (数百万) の存続期間の長いオブジェクトを持つアプリケーションのヒープ サイズの使用をどのように最適化しますか? (大きなキャッシュ、データベースから大量のレコードをロードする)

• 適切なデータ型を使用する
  • 他のデータ型を表すために java.lang.String を避ける
• オブジェクトの重複を避ける
  • 値が事前にわかっている場合は列挙型を使用します
  • オブジェクト プールを使用する
  • String.intern() (良いアイデア?)
• 必要なオブジェクトのみをロード/保持

一般的なプログラミングまたは Java 固有の回答を探しています。ファンキーなコンパイラ スイッチはありません。

編集：

ヒープに何百万回も出現する可能性のある POJO のメモリ表現を最適化します。

ユースケース

• 巨大な csv ファイルをメモリにロードします (POJO に変換されます)
• Hibernate を使用してデータベースから何百万ものレコードを取得する

回答の再開:

• フライウェイト パターンを使用する
• コピーオンライト
• 3 つのプロパティを持つ 10M オブジェクトをロードする代わりに、サイズが 10M の 3 つの配列 (または他のデータ構造) を持つ方が効率的ですか? （データを操作するのは面倒かもしれませんが、メモリが本当に不足している場合は...）

いくつかの機能を提供するコア JAR があるため、他の多くのアプリ (デスクトップ アプリ、Web アプリなど) でも使用されます。現在、このコア JAR は、作成に計算コストがかかるオブジェクトを含むオブジェクト プールを保持しています。オブジェクト プールは固定サイズであるため、一度にすべてのオブジェクトを作成してプールにデータを入力します。私がやりたいことは、私の JAR を使用するアプリがロードされるたびに、アプリケーションがそのようなプールの詳細を知らなくても、オブジェクト プールが作成されることです。また、プールの人口が原因でアプリの読み込み時間に影響が出ますが、アプリがこの段階を過ぎると、後でそのような重いオブジェクトを作成する際にパフォーマンスが低下することはありません。

これを達成する方法はありますか？

それらは存在しますか？

*明確にするために追加：

テンプレートを使用してC++言語で記述されたロックフリー（スレッドセーフで、スピンロックまたは他の軽量同期を実装する可能性があります）ObjectPool（http://en.wikipedia.org/wiki/Object_pool_pattern）を実装する使用可能なライブラリはありますか？

ObjectPool<T>私の会社ではしばらくの間、コンテンツへのアクセスをブロックする自家製の実装を使用してきました。これは非常に簡単です。a Queue<T>、objectロックオン、およびAutoResetEventアイテムが追加されたときに「借用」スレッドに通知するためのシグナルです。

クラスの要点は、実際には次の2つの方法です。

System.Collections.Concurrent4.0ではなく.NET3.5を使用しているため、によって提供されるものの代わりに、これと他のいくつかのコレクションクラスを使用しています。しかし最近、Reactive Extensionsを使用しているため、実際にはConcurrent（System.Threading.dllで）名前空間を使用できることがわかりました。

当然、名前空間BlockingCollection<T>のコアクラスの1つであるためConcurrent、私やチームメートが書いたものよりも優れたパフォーマンスを提供する可能性があると思いました。

そこで、非常に簡単に機能する新しい実装を書いてみました。

驚いたことに、いくつかの簡単なテスト（複数のスレッドから数千回プールに借用/戻る）によると、元の実装はパフォーマンスの点で大幅BlockingCollection<T>に優れています。どちらも正しく機能しているようです。元の実装の方がはるかに高速であるように見えるだけです。

私の質問：

1. なぜこれでしょうか？おそらく、BlockingCollection<T>柔軟性が高く（ラッピングすることで機能することを理解していますIProducerConsumerCollection<T>）、パフォーマンスのオーバーヘッドが必然的に発生するためですか？
2. BlockingCollection<T>これは、クラスの完全に誤った使用法ですか？
3. これが適切な使用法である場合BlockingCollection<T>、私は適切に使用していないだけですか？たとえば、Take/Addアプローチは過度に単純化されており、同じ機能を取得するためのはるかに優れたパフォーマンスの方法がありますか？

その3番目の質問に答える洞察が誰かにない限り、今のところ元の実装に固執しているように見えます。

CSLA フレームワークの基本的な方法論に従うアプリケーションがあります。具体的には、オブジェクトはその状態を維持する方法と、自分自身を作成、更新、削除する方法を知っています。car クラスはこの考え方を示しています。

アプリケーションは 100 万を超えるオブジェクトを作成および破棄します。ガベージ コレクションの量が原因で、オブジェクト作成のせん断数がパフォーマンスに影響を与えています。また、これらのオブジェクトの多くは完全に一時的なものであり、単にデータをリポジトリに渡すために使用されます。

Flyweight パターンについて読んだことがありますが、これは私のニーズに合っているようです。また、オブジェクト プーリングと関連するコードについても読みました。

私が問題を抱えているのは、プールを使用して何百万もの Car オブジェクトを作成するか、オブジェクトの原則と組み合わせてフライウェイトのデータを外部化することで、独自のデータとデータアクセスを維持する必要があります。

これを達成する方法についてのアイデアはありますか?

apache common poolを使用すると、Java オブジェクト プーリングの優れた実装が得られます。ただし、それらのKeyedPoolableObjectFactoryインターフェイスはタイプ セーフではありません。タイプ セーフなオブジェクト プールを作成するためのジェネリック インターフェイスを提供できる Java のオブジェクト プール ライブラリはありますか?

ユーザーが定義済みの数を超えるオブジェクトを作成できないように、ライブラリにオブジェクト プール デザイン パターンを使用したいと考えています。
リソースのコンストラクターではなく、インスタンスを取得するためにユーザーに Pool クラスを使用させるにはどうすればよいですか?

プールクラスもインスタンスを作成できないため、リソースコンストラクターをプライベートと宣言することはできません...

ありがとう

私が知る限り、オブジェクト プールは作成パターンであり、フライウェイトは構造パターンですが、実際には 2 つの間に大きな違いは見られません。誰かが私に違いと、それぞれが実装に役立つ時期を説明してもらえますか?

私のプロジェクトでは、さまざまな種類のオブジェクトにオブジェクト プールを使用したいと考えています。動作は似ていますが、プール サイズは異なります。

作成したオブジェクトに適用するプールとインターフェイスのジェネリック クラスを作成する必要がありますか?それとも、共通のロジックを使用して抽象プール クラスを作成し、それを使用するすべての異なるクラスに対して特定のサブクラスを作成する必要がありますか?

私の ASP.Net アプリケーションは、最初に初期化して大量のデータをロードする必要がある特別な DLL を呼び出す必要があります。すべてがロードされると、単一の関数で呼び出すことができます。

「ロード」の処理に時間がかかりすぎて、ASP.Net アプリケーションの起動時にすべてをロードする必要があるため、クライアントからの要求がすぐに届いたときに「検証」を行うことができます。さまざまなテンプレートを保持する FPScanner オブジェクトがいくつかあります......これを実装する方法を教えてください。ありがとう。