問題タブ [garbage-collection]

Java のバックグラウンドを持つ私が慣れ親しんでいることの 1 つは、JVM に最大ヒープ サイズを指定することです。実行中のプログラムが許可されている以上のリソースを飲み込もうとし、ガベージ コレクターがこれ以上リソースを解放できない場合、OutOfMemoryError がスローされ、すべてが爆発します。そのため、Java では最大ヒープ サイズを設定することが重要です。

これは .net に適用されますか? ヒープ サイズの制限を設定できますか? CLR は、マシンの物理的な限界に達するまでヒープを増やし続けますか? それとも、Java ウィンカーが原因で見えなくなったのは、何らかの微妙な理由で .net の問題ではないのでしょうか?

前の質問から、CLR にはガベージ コレクター用のワークステーション モードとサーバー モードがあることがわかりました。gcServerこれらは、要素を使用して構成から設定できることを知っています。

これを指定しない場合、CLR はマジックを使用して、ガベージ コレクターをサーバー モードで実行するかどうかを決定しますか? CPU 数、またはメモリ プロファイリングに基づくものでしょうか。

今日、私の同僚と私はfinal、ガベージ コレクションを改善するために Java でキーワードを使用する方法について話し合いました。

たとえば、次のようなメソッドを記述した場合:

メソッド内で変数を宣言するfinalと、ガベージ コレクションが、メソッドの終了後にメソッド内の未使用の変数からメモリをクリーンアップするのに役立ちます。

これは本当ですか？

オブジェクトがラージ オブジェクト ヒープ(85,000 バイトを超える) に到達するオブジェクトの数を確認するために、オブジェクトがどれだけのメモリを必要とするかを調べようとしています。

int の場合は 4、long の場合は 8、各オブジェクトの参照型などの場合は 4 (または 64 ビットの場合は 8) を追加するのと同じくらい簡単ですか、それともメソッド、プロパティなどのオーバーヘッドがありますか?

JavaMe でガベージ コレクターが動作する方法を微調整して、何らかの方法でパフォーマンスを向上させることができるかどうか疑問に思っていました (パッセージの数を減らす可能性があります)。それに関する記事をいくつか見たことがありますが、ほとんどが Java SE 向けであり、そのほとんどは GC はメーカーに大きく依存していると述べています。それはいくらでしょう。

JVM 1.5.0 (Mac OS X デフォルト) を実行しており、アクティビティ モニターで Java プログラムを監視しています。私は次のものを持っています：

}

では、ガベージ コレクターが正常に動作しているように見えても、物理メモリが解放されないのはなぜでしょうか。

別のページのキャンバスの子として複数の xaml ベースのページが保存されています。アプリケーションの実行時に子ページを追加および削除します。ただし、children コレクションから削除されたページは引き続き実行され、キーボード ショートカットに応答します。古いページを強制的に完全に削除するにはどうすればよいですか?

私が正しく理解していれば、.netランタイムは常に私の後にクリーンアップされます。したがって、新しいオブジェクトを作成し、コードでそれらを参照するのをやめると、ランタイムはそれらのオブジェクトをクリーンアップし、それらが占有していたメモリを解放します。

これが事実なので、なぜいくつかのオブジェクトはデストラクタまたはdisposeメソッドを持っている必要がありますか？それらが参照されなくなったときに、ランタイムはそれらの後でクリーンアップしませんか？

管理されたプロセスが大量のメモリを使用している理由を調べています。GC.Collect(3)実際のメモリ割り当てに集中できるように、WinDbgから実行する方法はありますか?

非常に大量のRAMを搭載したマシン（300GBから15TB、おそらくSGI Altix 4700マシン）でJavaアプリを実行する可能性を模索していますが、JavaのGCがどのように機能するかについて興味があります。このシナリオでは。

これには、IBMまたはJRockitのJVMの方がSunよりも適していると聞いています。この状況でのJVMパフォーマンスに関する調査やデータを知っている人はいますか？