1

私の知る限り、旧世代のJVMのスペースでは、2つの目的に利用できます。

  1. 若い世代から古い世代に昇格するオブジェクトに使用されますか？
  2. 特別なユースケースでの新しいオブジェクトの割り当てに使用されます（https://stackoverflow.com/questions/9053144/will-i-encounter-java-lang-outofmemoryerror-even-with-no-lack-of-memory）

私の質問は、

  1. 古い世代のスペースを利用する他のユースケースはありますか？
  2. 若い世代から古い世代へのオブジェクトのコピーにはメモリコピーが含まれていると思いますが、それはディープコピーですか、それともシャローコピーですか。

よろしくお願いします、リン

4

2 に答える 2

1

答えさせてください。2。これは間違いなくディープコピーではありません。GCはオブジェクトを個別のメモリブロックとして処理し、ディープコピーは実際にはオブジェクトグラフに接続されている多くの個別のオブジェクトをコピーすることを意味します。また、コピーではなく、動きを想像することで、より良いサービスを受けることができます。コピーは実際には単なる「実装の詳細」であり、目的の効果は再配置です。

于 2012-12-02T15:40:22.093 に答える
1

@Lin Maのコメントへの質問に答えて、このコードを配置します。

class SomeClass{
    private static List<Object> memoryLeakCulprit = new ArrayList<Object>();



    void someMethod(Object obj){

          //adding the reference of some object in the culprit list
          memoryLeakCulprit.add(obj);

    }

    //supposed to remove the reference passed
    void someOtherMethod(Object obj){

         obj = null;

         //bummer forgot to remove the reference from list

         //now the instance is not reachable by obj
         //so now as new references are added to culprit list the memory will keep on increasing in size

    }

}

UDPATE

このリークを解決する方法

oid someOtherMethod(Object obj){

              //before setting the obj reference to null it must be removed from culprit list
              memoryLeakCulprit.remove(obj);

              //now its safe to set this reference to null
              obj = null;

        }

リークを解決する唯一の方法は、 JProfiler、VisualVMなどのプロファイリングツールを使用してアプリケーションをプロファイリングし、リークの原因となっているクラスを特定することです。

クラスを見つけたら、コードを変更する必要があり、それが唯一の方法です。

プログラムを終了する前に参照を解放する必要はありません。理由は、static変数（ ）がクラスmemoryLeakCulpritオブジェクトにバインドされており、プログラムを終了するとすぐに、クラスオブジェクトを含むすべての参照が自動的に解放されるためです。

まったく別の注意点として、プログラムを終了する前に、必ずシステムリソース（ソケット、DB接続）を閉じてください。

于 2012-12-03T13:20:57.977 に答える