こんにちは私はa[dynamic], b[dynamic], c[dynamic]
の3つの配列変数を持っていると考えてください。それらは任意のサイズにすることができます。変数を破棄したいのですが。私はもう変数を使用しないと確信しています。どんなアイデアや提案も歓迎します。
配列にnull
を割り当てることで、配列を解放できることをガベージコレクタに示すことができます。
_ int[] a = new int[someSize];
int[] b = new int[someSize];
....
// I no longer need 'a'
a = null;
// ... but I can still use 'b'
_
ただし、注意すべき点がいくつかあります。
これはスペースを解放しません。むしろ、配列eligibleをガベージコレクターによって解放されるようにしています。 GCは、長時間解放されない場合があります。
実際、配列は到達不能の場合にのみガベージコレクションの対象となります。配列への参照を別の(まだ生きている)変数または到達可能なオブジェクトに割り当てた場合、GCはそれを再利用しません。
実際のJavaアプリケーションでこれを行うことに意味があることはめったにありません。通常の計算過程で変数がスコープ外になることを単に許可するのが通常の方法です。1。変数が長期間スコープ外に出ることはなく、大きな配列/オブジェクトまたはネットワークを参照している場合にのみ、そのような変数(またはオブジェクトフィールドまたは配列要素)を明示的にnull
します。
null
を割り当てた後、またはこれまでにSystem.gc()
を呼び出して、GCを強制的に実行しようとすることは強くお勧めしません。2。通話に影響がある場合は、高額になる可能性があります。 JVMに最適な時間にGCをスケジュールさせることをお勧めします。
1-妥当なJVM実装は、メソッドが終了するとローカル変数がスコープ外になることを認識します。 JVMがスコープをより細かく追跡するかどうかは、実装固有であり、(正直に言うと)I わからない JVMが実際にこれをどのように処理するかです。
GCが到達可能な(つまり、ガベージ以外の)オブジェクトを削除しない限り、ほぼすべてが技術的に JLS要件に準拠していることに注意してください。これには、Epsilon no-op GCを使用するJVMが含まれます。これは、ガベージを収集せず、スペースが不足するとJVMを終了します。
2-唯一の正当な理由は次のとおりです。1)GC関連機能の動作をテストする。例えばファイナライザー、参照キュープロセッサーなど、または2)リアルタイムアプリケーションでの有害なGC一時停止の回避。例えばリアルタイムゲームで「レベル」を変更するときにGCを実行します。
Stephen Cがあなたの質問に答えましたが、非プリミティブ型の場合、配列内のすべてのオブジェクトが不要な場合はnullとしてマークされるようにします。これにより、メモリリークが発生しなくなります。
何かのようなもの:
for(Object obj : myObjectArray){
obj = null;
}
次に、配列参照をnullにします
myObjectArray = null;
ArrayListからすべての要素を削除するには
arrayList.removeAll(arrayList);