これをJava教科書（SL-275）で読んだ
メモリの割り当てを解除しないプログラムは、システムに割り当てるメモリが残っていない場合、最終的にクラッシュする可能性があります。これらのプログラムにはメモリリークがあると言われています。
なぜメモリが残っていないのですか？システムには通常、数百ギガバイトのメモリがあり、変数は2〜8バイトのデータを取ります。破壊されていない変数が1000個あるとしましょう。これは、わずか8KBです。では、なぜガベージコレクションがそれほど重要なのでしょうか。
ウェブで答えを探してみたところ、講師に相談しても満足のいく答えが見つかりませんでした。
プログラムが変数の使用を終了した後、システムがメモリを再利用できない場合は、メモリ リークです。
それは重要です。なぜなら、
実話: 私はかつて、ASP .NET システムをデバッグしたことがありますが、そのメモリ リークはごくわずかでした (特定の Web ページへの要求ごとに約 60 バイトだったと思います)。しかし、そのページには多くのヒットがあり、サーバーの RAM を使い果たすのを避けるために、1 時間ごとにアプリケーション プールをリサイクルする必要がありました。これは非常によくスペックされたサーバー上にありました。また、ガベージ コレクション環境でもリークが発生する可能性があることを示しています。常にメモリの消費に注意する必要があります。
変数には 1 語または 2 語のデータのみが含まれる場合がありますが、型が Java オブジェクトである変数の場合、その語は実際にはガベージ コレクションされたデータ (オブジェクトの状態) へのポインターです。そして、そのオブジェクトの状態には、他のオブジェクト (またはそれらの配列) へのポインター、それ自体が他のオブジェクト、または前のオブジェクト (循環参照!) などを指すポインターが含まれる場合があります。
ガベージ コレクタは、(ローカル変数またはグローバル変数からの) 参照チェーンがメモリを指していないことを確認した後でのみ、メモリを解放します (つまり、JVM に再利用させます)。
少なくともガベージ コレクションに関するウィキペディアのページを注意深く読み、可能であればガベージ コレクション ハンドブックのような教科書を読むことを強くお勧めします。1992 年の Paul Wilson のGC 調査記事も読むことができます。
また、RAM の使用に注意する必要があります。アプリケーションの観点から見ると、ハードディスクへのアクセスには非常に長い時間がかかります (ディスク上のキロバイト ブロックへのアクセスは約 10 ミリ秒です。RAM 上のアクセスは数マイクロ秒で数千倍高速です。オンチップ キャッシュはナノ秒単位でアクセスできます。) SSDはそれを少し改善します。
まず、すべての変数が 2 から 8 バイトであることは大前提です。一部のアプリケーションでは、かなり大きなデータ構造であり、メガバイトに達するものもあります。
第 2 に、2 バイトの変数のリークでも、数百万回または数十億回実行されるループ内にある場合、特に長寿命のプログラムでは大混乱を引き起こします。
第 3 に、使用している物理メモリの量は、プロセスのアドレス空間とは無関係である可能性があります。たとえば、32 ビット プロセスは、マシンが数百ギガバイトあるという事実に関係なく、4G にしか対応できない場合があります。
最後に、リークを処理できたとしても、この種の潜在的なバグを持たない方が良いコーディング スタイルです。他のものはただずさんです:-)
4Gb RAM の Web サーバーがあるとします。この Web サーバーには、小さなメモリ リークが発生している Web サイトが 1 つあります。
この例では、RAM で 1Mb のメモリを必要とするファイルをそれぞれ消費し、使用後にクリーンアップしないとします。
おそらく、リークのあるページは 1 日あたり 100 回呼び出されます。突然、サーバーが毎日 100 MB を失っています。これは悪いです。
メモリ リークは小さいかもしれませんが、すべての RAM を占有しているため、30 日ごとにアプリを再起動する必要はありません。