3

長いSQLクエリを実行し、処理された結果をHashMapに格納するプログラムを使用しています。現在、20〜200の各クエリの実行時間が遅いことを回避するために、固定スレッドプールとカスタム呼び出し可能オブジェクトを使用して検索を行っています。その結果、各呼び出し可能オブジェクトはデータのローカルコピーを作成し、それをメインプログラムに戻してレポートに含めます。

以前は問題なく実行されていた100個のクエリレポートにより、メモリが不足していることに気付きました。私の推測では、これらの呼び出し可能オブジェクトはデータの独自のコピーを作成しているため、それらを別の大きなHashMapに結合すると、メモリ使用量が2倍になります。呼び出し可能オブジェクトのテーブルのスコープを縮小することで、ガベージコレクターを実行するように誘導できることはわかっていますが、回避できるのであれば、そのレベルの再構築は実際にはやりたいことではありません。

呼び出し可能オブジェクトを、データを格納する代わりに同時HashMapに書き込む実行可能オブジェクトに置き換えることで、メモリ使用量を改善できますか？それとも、ここで他の問題があるように聞こえますか？

4

3 に答える 3

3

データのコピーを作成せず、参照を渡すだけで、必要に応じてスレッド セーフを確保します。データをコピーしないでまだ OOM がある場合は、アプリケーションで使用可能な最大ヒープを増やすことを検討してください。

ただし、データのコピーを使用しない上記のアプローチの欠点は、スレッドセーフを達成するのが難しいことです。

于 2011-08-31T14:56:28.763 に答える
1

本当に100〜200のレポートすべてを同時に必要としますか？

May be it's worth to limit the 1st level of caching by just 50 reports and introduce a 2nd level based on WeakHashMap? When 1st level exceeds its size LRU will be pushed to the 2nd level which will depend on the amount of available memory (with use of WeakHashMap).

Then to search for reports you will first need to query 1st level, if value is not there query 2nd level and if value is not there then report was reclaimed by GC when there was not enough memory and you have to query DB again for this report.

于 2011-08-31T15:02:58.763 に答える
0

クエリの結果は、他のクエリの結果に依存しますか? そうでない場合は、別のスレッドで結果を発見するたびに、暗示しているように ConcurrentHashMap を使用してください。データの不必要なコピーをいくつか作成することがプログラムのメモリ不足を引き起こしているかどうか、本当に質問する必要がありますか? これはほとんど明らかなはずです。

于 2011-08-31T16:04:48.800 に答える