2

jvm が時間内に gc を実行できず、アプリケーションがフリーズするという問題があります。そのための「解決策」は、jconsole を使用してアプリケーションに接続し、jvm を提案してガベージ コレクションを作成することです。アプリケーションの動作が非常に悪いとは言えません。jvmがgcをより早く/より頻繁に実行するように提案するオプションはありますか? たぶん、この問題に対する他の本当の解決策があるでしょうか？

問題はメモリ不足ではないようですが、新しいデータがアプリケーションに送信される前に gc が時間内に収集を行うことができません。これは、gc がデータの収集を開始するのが遅れているように見えるためです。jconsole の System.gc() ボタンによって早期に提案された場合、問題は発生しません。

若い世代はパラレルコレクターである「PSスカベンジ」で集めます。古い世代は、平行マークとスイープのコレクターである「PS MarkSweep」によって収集されます。

4

8 に答える 8

2

メモリ リークをチェックする必要があります。解放するメモリがなく、使用可能なメモリがない場合を除き、 OutOfMemoryException が発生することはないと確信しています。

于 2013-09-10T11:34:00.307 に答える
1

サーバーにJava melodyをデプロイしてアプリケーションを追加すると、メモリ リークとメモリ使用量の詳細なレポートが得られます。これにより、システムとコードを正しく最適化することができます。

于 2013-09-10T11:33:26.953 に答える
1

さらに、

多くのクラス (たとえば、 rt.jar に存在するすべてのクラス) をロードしている場合、OOME を受け取ることがあります。ロードされたクラスはヒープ メモリではなく PermGen に存在するため、-XX:MaxPermSize スイッチを使用して PermGen のサイズを増やすこともできます。

そしてもちろん、ParallelGC、ConcMarkSweepGC (CMS)、G1GC (G1) などのガベージ コレクターを自由に選択できます。

Java には、それ自体でメモリ リークを引き起こす可能性のある API があることに注意してください (プログラマのエラーなしで)。たとえば、java.lang.String#substring() (こちらを参照) 。

于 2013-09-10T11:44:13.930 に答える
1

アプリケーションがフリーズしても、強制 GC によってフリーズが解除される場合、問題はおそらくメモリではなく、他のリソース リークであり、デッド オブジェクトに対してファイナライザーを実行することで軽減されます。適切に記述されたコードは、ファイナライザーに依存してクリーンアップを実行してはならないため、アプリケーション内の閉じられていないリソースを見つけるようにしてください。

于 2013-09-12T12:37:11.750 に答える
0

より多くのメモリでjvmを起動できます

java -Xms512M -Xmx1024M

は、512Mb のメモリで jvm を起動し、ギガバイトまで拡張できるようにします。

于 2013-09-10T11:32:55.653 に答える
0

System.gc()ガベージ コレクターを実行するように VM に提案するために使用できます。すぐに実行されるという保証はありません。

それが役立つかどうかは疑問ですが、うまくいくかもしれません。他に検討できることは、JVM の最大メモリ サイズを増やすことです。これを行うには、コマンド ライン引数を指定します-Xmx512m。これにより、デフォルトの 128 メガバイトではなく、512 メガバイトのヒープ サイズが得られます。

JConsole を使用して、アプリケーションのメモリ使用量を表示できます。これは、メモリ使用量がどのように変化するかを確認するのに役立ち、メモリ リークの検出に役立ちます。

于 2013-09-10T11:36:00.157 に答える