数百万の小さな一時オブジェクトを作成するためのベストプラクティス

何百万もの小さなオブジェクトを作成（およびリリース）するための「ベストプラクティス」とは何ですか？

私はJavaでチェスプログラムを書いており、検索アルゴリズムは可能な各移動に対して単一の「移動」オブジェクトを生成し、名目検索は1秒あたり100万以上の移動オブジェクトを簡単に生成できます。JVM GCは私の開発システムの負荷を処理することができましたが、次のような代替アプローチを模索しています。

1. ガベージコレクションのオーバーヘッドを最小限に抑える。
2. ローエンドシステムのピークメモリフットプリントを削減します。

オブジェクトの大部分は存続期間が非常に短いですが、生成された移動の約1％が永続化され、永続化された値として返されるため、プーリングまたはキャッシングテクニックでは、特定のオブジェクトの再利用を除外する機能を提供する必要があります。

私は完全に具体化されたサンプルコードを期待していませんが、さらに読んだり研究したりするための提案、または同様の性質のオープンソースの例をいただければ幸いです。

詳細なガベージコレクションでアプリケーションを実行します。

java -verbose:gc

そして、それは収集するときに教えてくれます。掃引には、高速掃引と完全掃引の2つのタイプがあります。

[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

矢印はサイズの前後です。

完全なGCではなく、GCを実行している限り、安全です。通常のGCは「若い世代」のコピーコレクターであるため、参照されなくなったオブジェクトは単に忘れられるだけであり、これはまさに望んでいることです。

Java SE 6 HotSpot Virtual Machine Garbage Collection Tuningを読むと役立つでしょう。

バージョン6以降、JVMのサーバーモードはエスケープ分析手法を採用しています。これを使用すると、GCをすべて一緒に回避できます。

さて、ここにはいくつかの質問があります！

1-存続期間の短いオブジェクトはどのように管理されますか？

前述のように、JVMは弱い世代仮説に従うため、大量の短期間のオブジェクトを完全に処理できます。

メインメモリ（ヒープ）に到達したオブジェクトについて話していることに注意してください。これは常にそうであるとは限りません。作成したオブジェクトの多くは、CPUレジスタを残しさえしません。たとえば、このforループを考えてみましょう

for(int i=0, i<max, i++) {
  // stuff that implies i
}

ループ展開（JVMがコードで頻繁に実行する最適化）について考えないでください。maxがに等しい場合Integer.MAX_VALUE、ループの実行には時間がかかる場合があります。ただし、i変数がループブロックをエスケープすることはありません。したがって、JVMはその変数をCPUレジスタに入れ、定期的にインクリメントしますが、メインメモリに送り返すことはありません。

そのため、何百万ものオブジェクトをローカルでのみ使用する場合、それらを作成することは大したことではありません。それらはエデンに保管される前に死んでいるので、GCはそれらに気付くことさえありません。

2-GCのオーバーヘッドを減らすことは有用ですか？

いつものように、状況によります。

まず、何が起こっているのかを明確に把握できるように、GCロギングを有効にする必要があります。で有効にでき-Xloggc:gc.log -XX:+PrintGCDetailsます。

アプリケーションがGCサイクルで多くの時間を費やしている場合は、はい、GCを調整します。それ以外の場合は、実際には価値がない場合があります。

たとえば、100ミリ秒ごとに10ミリ秒かかる新しいGCがある場合、時間の10％をGCに費やし、1秒あたり10個のコレクションがあります（これはハウウージです）。そのような場合、10のGC /秒がまだ存在するため、GCのチューニングに時間を費やすことはありません。

3-ある程度の経験

特定のクラスを大量に作成しているアプリケーションでも同様の問題がありました。GCログで、アプリケーションの作成速度が約3 GB /秒であることに気づきました（これは、1秒あたり3ギガバイトのデータです！）。

問題：作成されているオブジェクトが多すぎるために頻繁に発生するGCが多すぎる。

私の場合、私はメモリプロファイラーをアタッチし、クラスがすべてのオブジェクトの大きな割合を占めていることに気付きました。インスタンス化を追跡して、このクラスが基本的にオブジェクトにラップされたブール値のペアであることを確認しました。その場合、2つのソリューションが利用可能でした。

• ブール値のペアを返さないようにアルゴリズムを作り直しますが、代わりに、各ブール値を個別に返す2つのメソッドがあります。

• オブジェクトがキャッシュされ、4つの異なるインスタンスしかなかったことがわかる

2番目の方法を選択したのは、それがアプリケーションへの影響が最も少なく、導入しやすいためです。スレッドセーフではないキャッシュを備えたファクトリを配置するのに数分かかりました（最終的に4つの異なるインスタンスしかなかったため、スレッドセーフは必要ありませんでした）。

割り当て率は1 GB /秒に低下し、若いGCの頻度も低下しました（3で除算）。

お役に立てば幸いです。

値オブジェクトだけがあり（つまり、他のオブジェクトへの参照がない）、本当に大量のオブジェクトを意味する場合はByteBuffers、ネイティブバイトオーダーで直接使用できます（後者は重要です）。数百行が必要です。割り当て/再利用するコード+ゲッター/セッター。ゲッターは似ていますlong getQuantity(int tupleIndex){return buffer.getLong(tupleInex+QUANTITY_OFFSSET);}

一度だけ、つまり巨大なチャンクを割り当てて、自分でオブジェクトを管理する限り、GCの問題はほぼ完全に解決します。参照の代わりに、渡される必要があるへのインデックス（つまりint）のみByteBufferを指定します。自分でメモリを揃える必要がある場合もあります。

テクニックはを使用するような感じC and void*がしますが、いくつかのラッピングで耐えられます。パフォーマンスの低下は、コンパイラが除去に失敗した場合の境界チェックである可能性があります。主な利点は、ベクトルのようなタプルを処理する場合の局所性です。オブジェクトヘッダーがないため、メモリのフットプリントも減少します。

それ以外の場合、事実上すべてのJVMの若い世代が自明に死に、割り当てコストは単なるポインターバンプであるため、このようなアプローチは必要ない可能性があります。final一部のプラットフォーム（つまり、ARM / Power）でメモリフェンスが必要なフィールドを使用する場合、割り当てコストは少し高くなる可能性がありますが、x86では無料です。

GCが問題であると考える場合（他の人はそうではないかもしれないように指摘します）、特別なケース、つまり大量のチャーンを受けるクラスのために独自のメモリ管理を実装します。オブジェクトのプールを試してみると、かなりうまくいくケースを見てきました。オブジェクトプールの実装は十分に踏み込まれたパスであるため、ここに再度アクセスする必要はありません。以下に注意してください。

• マルチスレッディング：スレッドローカルプールを使用すると、問題が解決する場合があります
• バッキングデータ構造：削除時に十分に機能し、割り当てオーバーヘッドがないため、ArrayDequeの使用を検討してください
• プールのサイズを制限します:)

前/後などを測定

同様の問題に遭遇しました。まず、小さなオブジェクトのサイズを小さくしてみてください。各オブジェクトインスタンスでそれらを参照するデフォルトのフィールド値をいくつか導入しました。

たとえば、MouseEventにはPointクラスへの参照があります。新しいインスタンスを作成する代わりに、ポイントをキャッシュして参照しました。たとえば、空の文字列でも同じです。

別のソースは、1つのintに置き換えられた複数のブール値であり、ブール値ごとに1バイトのintを使用しました。

少し前に、このシナリオをいくつかのXML処理コードで扱いました。非常に小さく（通常は文字列のみ）非常に短期間（XPathチェックの失敗は一致しないため、破棄される）数百万のXMLタグオブジェクトを作成していることに気付きました。

私はいくつかの真剣なテストを行い、新しいタグを作成する代わりに、破棄されたタグのリストを使用して速度を約7％向上させることができるだけであるという結論に達しました。ただし、実装すると、フリーキューが大きくなりすぎた場合、それをプルーニングするメカニズムを追加する必要があることがわかりました。これにより、最適化が完全に無効になり、オプションに切り替えました。

要約すると、おそらくそれだけの価値はないでしょうが、あなたがそれについて考えているのを見てうれしいです。

あなたがチェスプログラムを書いているとすれば、まともなパフォーマンスのために使用できるいくつかの特別なテクニックがあります。単純なアプローチの1つは、long（またはバイト）の大きな配列を作成し、それをスタックとして扱うことです。ムーブジェネレーターがムーブを作成するたびに、2、3の数値をスタックにプッシュします。たとえば、正方形から移動して正方形に移動します。検索ツリーを評価すると、動きが飛び出し、ボード表現が更新されます。

表現力が必要な場合はオブジェクトを使用します。（この場合は）速度が必要な場合は、ネイティブにしてください。

このような検索アルゴリズムで使用した1つの解決策は、Moveオブジェクトを1つだけ作成し、それを新しいmoveで変更してから、スコープを離れる前に移動を元に戻すことです。おそらく、一度に1つの動きだけを分析してから、どこかに最良の動きを保存するだけです。

それが何らかの理由で実行不可能であり、ピーク時のメモリ使用量を減らしたい場合は、メモリ効率に関する優れた記事がここにあります：http : //www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java- tutorial.pdf

何百万ものオブジェクトを作成し、適切な方法でコードを記述してください。これらのオブジェクトへの不要な参照を保持しないでください。GCはあなたのために汚い仕事をします。前述のように冗長GCを試して、実際にGCされているかどうかを確認できます。Javaはオブジェクトの作成と解放についてです。:)

Javaでのスタック割り当てとエスケープ分析について読むべきだと思います。

このトピックをさらに掘り下げると、オブジェクトがヒープに割り当てられておらず、ヒープ上のオブジェクトと同じようにGCによって収集されない場合があります。

これはJavaでどのように機能するかの例とともに、エスケープ分析のWikipediaの説明があります。

http://en.wikipedia.org/wiki/Escape_analysis

私はGCの大ファンではないので、常にそれを回避する方法を模索しています。この場合、オブジェクトプールパターンを使用することをお勧めします。

後で再利用できるように、スタックに格納して新しいオブジェクトを作成しないようにするのが目的です。

Class MyPool
{
   LinkedList<Objects> stack;

   Object getObject(); // takes from stack, if it's empty creates new one
   Object returnObject(); // adds to stack
}

オブジェクトプールは、ヒープ上のオブジェクトの割り当てを大幅に（場合によっては10倍）改善します。しかし、リンクされたリストを使用した上記の実装は、素朴で間違っています。リンクされたリストは、内部構造を管理するためのオブジェクトを作成して、努力を無効にします。オブジェクトの配列を使用するリングバッファはうまく機能します。例では、（移動を管理するチェスプログラム）で、計算されたすべての移動のリストのホルダーオブジェクトにリングバッファーをラップする必要があります。ムーブホルダーオブジェクトの参照のみが渡されます。