特に何もしなくても、Eclipse のフットプリントは 500MB から 1GB を超えるまで着実に増加しています。ログの重いプログラムをいくつか実行しているだけです。手動 GC を実行し、プロジェクトを閉じて再度開くことはまったく役に立ちません。1GB を超えると、そこにとどまります。
jvisualvm を実行したところ、ヒープダンプから数百メガバイトがログ出力を表す char[] であることがわかりました。
停止したプロセスのすべてのコンソールを閉じることを習慣にしているので、そうではありません。コンソール バッファは 1MB (文字) に設定されます。コンソール ビューを閉じて、もう一度開きました。
特定の eclipse.ini を貼り付けることができますが、さまざまな GC とメモリ設定、さまざまな JVM、さまざまな Eclipse バージョンを試しましたが、動作は同じです。
私には、ログがどこかで参照に引っかかっており、解放されていないようです。他の誰かがこの問題を抱えていますか? 古いコンソール ビューからメモリを解放する設定はありますか?
While I thought about something smart to write here I found this: How to reduce Eclipse's memory usage? Where the suggestion to disable spellchecking actually made a lot of difference.
So.. here is my own contribution: This might sound strange, but I've also noticed myself having a lot of unused breakpoints makes Eclipse sluggish. Regularly clearing all break points is a sound habit.
This is just a tip related to this, there's an option to show memory and to force an GC from within Eclipse. Under
Preferences>General>Show Heap Status
簡単な答え: ヒープ サイズは縮小していません。拡大しているだけです。
長い回答: 最終的には、複数の要因が組み合わさったように見えました。JVM のデフォルト オプションがどうあるべきか完全にはわかりませんが、私の XP マシンでは Windows パフォーマンスの最適化が「サーバー」/「バックグラウンド アプリケーション」に設定されています。これにより、JVM が「-client」ではなく「-server」オプションにデフォルト設定されることもあると思います。-server オプションでは、ヒープを縮小できません。
私の知る限り、parallelGC ではヒープを縮小できません。
XX:MaxHeapFreeRatio (70) と XX:MinHeapFreeRatio (30) のデフォルト値は、空きメモリを放棄するのがかなり面倒です。それらを 20/10 に設定すると、実際の使用量に近いヒープ サイズになります。
なぜこれらすべてが重要なのでしょうか? Java でデスクトップ アプリケーションを開発している場合、クライアントは増え続けるメモリ使用量に腹を立て、悪いプログラミングを非難するかもしれません。Firefoxで何が起こるかのようなものです。