AWT GUIを備えたアプリケーションがあり、JTextArea
出力のログ記録に使用しています。setText(null)
またはremoveAll()
またはでテキストを消去してからsetText("")
ガベージコレクターを実行するとSystem.gc()
、テキスト全体がまだメモリに残っていることに気付きます。どうすれば本当にテキストを削除できますか?
私はプロファイラーにあまり精通していません、これは私が後にメモリダンプで見るものですsetText(null)
:
AWT GUIを備えたアプリケーションがあり、JTextArea
出力のログ記録に使用しています。setText(null)
またはremoveAll()
またはでテキストを消去してからsetText("")
ガベージコレクターを実行するとSystem.gc()
、テキスト全体がまだメモリに残っていることに気付きます。どうすれば本当にテキストを削除できますか?
私はプロファイラーにあまり精通していません、これは私が後にメモリダンプで見るものですsetText(null)
:
ガベージコレクションがJavaでどのように機能するかをお読みください。
ドキュメントに よるとSystem.gc()
:
gcメソッドを呼び出すことは、Java仮想マシンが、現在占有しているメモリを迅速に再利用できるようにするために、未使用のオブジェクトのリサイクルに労力を費やすことを示唆しています。制御がメソッド呼び出しから戻ると、Java仮想マシンは、破棄されたすべてのオブジェクトからスペースを再利用するために最善を尽くしました。
NB-提案します。これは、ガベージコレクターがクリーンアップを実行するように提案されているだけで、強制されていないことを意味します。また、要求を完全に無視する可能性があるため、ガベージコレクターがいつ収集されるかを知ることはできません。
注意-破棄されたオブジェクト:これは、他のインスタンス/クラス/フィールド/変数などによって使用されていないstatic
/または使用されていない/参照されていないすべてのオブジェクトを指します。final
これは私がこのトピックで見つけた興味深い質問でもあります:
トップアンサーは次のようになります。
誰もが常に避けるように言う理由
System.gc()
は、それが根本的に壊れたコードのかなり良い指標であるということです。正確さのためにそれに依存しているコードは確かに壊れています。パフォーマンスのためにそれに依存しているものはおそらく壊れています
さらに、ドキュメントの言い回しが悪いためにバグが提出されています。
。
@DavidKのメモSystem.gc()
は、これを調べるのに便利な方法ではありません。ここで説明するメカニズムを使用すると、ほとんどのプロファイラーは、いくつかの制限がありますが、便利なデバッグツールである方法でガベージコレクションを強制できます。
クライアントプログラムにこのコンテンツを保持しているStringオブジェクトがある場合は、それらもnullに設定してください。
また、System.gc()mothodを明示的に呼び出す必要はありません。JVMは、他のオブジェクトに割り当てるためにより多くのメモリが必要になると、孤立したオブジェクトをガベージで収集します。
メモリ不足/連続ヒープメモリの使用量の増加などが見られる場合にのみ心配する必要があります。