The question has matured by chance when I switched from Eclipse to AS. The compiler writes a warning (indicated in the topic). But it confuses me. The point is this. There is a class, I get a copy of it. I use his methods. After using the variable that received this instance, I reset (= null).

MyPreferences pref = new MyPreferences(); pref.loaddata(); ...использую методы класса MyPreferences pref = null;

Here on the last line AS warns. But I used to read such a phrase that "Android does not like resource leaks, so we release the variable .... and assign null to it". Help me figure out how to write correctly ... thanks.

  • The [android studio] tag is indicated for questions about work and problems directly with this IDE. Your question does not apply to such. - pavlofff

5 answers 5

That is the interest of the scope and memory management in the JVM. For example, you execute everything described above in your method, after executing the code and exiting the method, the references to the object are lost and after a while it is destroyed by the garbage collector. Essentially, you add something extra, which the AS points to. It is a completely different story if you specify the MyPreferences pref outside the method, a class variable. Here then pref = null; really necessary for zeroing links for the subsequent destruction of the object by the garbage collector.

 private void myMethod() { MyPreferences pref = new MyPreferences(); pref.loaddata(); ...использую методы класса MyPreferences }

vs

 public class MyClass extends NotMyClass { MyPreferences pref; ... private void myMethod() { pref = new MyPreferences(); pref.loaddata(); ...использую методы класса MyPreferences pref=null; } }
  • 3
    Slightly ahead of me with the answer) yes that's right. This line will be considered redundant - unnecessary, since the garbage collector will do this work anyway, you can even check it by calling System.gc (); , for example, in different cycles of activating and testing, where all the data is running away, then you will need to use = null to understand how memory is freed. With me + 1, for a quick response. - Shwarz Andrei

Setting null only indicates to the collector that you are not using the object. It does not cause GC immediately, etc.

As VAndrJ correctly wrote, it all depends on the visibility of the variable. Here only his example should not be used in a real project:

 public class MyClass extends NotMyClass { MyPreferences pref; ... private void myMethod() { pref = new MyPreferences(); pref.loaddata(); ...использую методы класса MyPreferences pref=null; } }

This is a problem of architecture. It is difficult to imagine a case when this might be necessary. Usually, class fields live with the class itself (consistency, everything). And when you no longer have a link to the object itself, then all its internal fields will be destroyed.

As for setting variables to null , sometimes it is even harmful. If you always explicitly set objects to null in games, then gc will work longer, since you need to release more. In order to optimize the game in this respect, it is necessary to use object pools so that gc is not called on them at all.

In general, read a good article from ibm . It makes it clear that sometimes the zeroing of links can even make things worse.

  • I agree that it should not be used, but this example showed for clarity and understanding of the difference. - VAndrJ
  • Proxy works like this - Shwarz Andrei
  • @ShwarzAndrei, so the object lives in it the entire lifetime of the proxy class itself. And there is no need to zero the internal object. - Suvitruf ♦
  • I'm talking about the structure, but yes, zeroing is not - right. But you can use, why not, right? and this will be the meaning of the matter. - Shwarz Andrei

forcibly assign null when the field is no longer needed \ class is not used \ activation is closed, you only need static-fields set with Context to avoid memory leaks, since having static on an external class, the garbage collector will not destroy the object.
You also need to monitor the closing of cursors, DB and TP. The garbage collector will deal with the rest.

    It is the responsibility of the garbage collector to find unused more objects and delete them. Forced zeroing of variables does not give any advantages and simply does not make sense, in my opinion.

    The only option when this may be required: when performing a lengthy process, when a local object is no longer required, but is still in scope. However, in modern JVMs, even this kind of zeroing is no longer required, since the JVM can independently handle such cases.

     void longProcess() { Object obj = new Object(); operationsWith(obj); obj = null; doSomethingElse(); // длительный процесс, и чтобы не держать в памяти obj, мы ранее ее принудительно обнулили. }

    However, this code can be written differently:

     void longProcess() { { Object obj = new Object(); operationsWith(obj); } doSomethingElse(); // принудительное обнуление уже не требуется. }

    Regarding the zeroing of the link, if it is a member of the class: in my opinion, you just need to make such fields local variables and, if necessary, pass them into functions.

      Many do not understand that Java is a pure pass-by-value. Therefore your

       pref = null;

      It means only that the variable pref does not indicate an object in memory. What actually happens to this object in memory depends on many factors.
      This instruction itself is absolutely meaningless and you can remove it. If you can not remove it - you have a mistake elsewhere.