-1

I am having this snippet of code

A = new int[100];
B = new int[100];
C = boolean[100];

for(int i=1;i<=10000000;i++)
{
     A = new int[100];
     B = new int[100];
     C = boolean[100];

     // Do Something

     // Now i don't need A,B,C Array
}

How many times does i am using memory to create array , can i efficiently use memory ? I don't need previous arrays , i only need the current one.

I don't want to use any extra memory to store previous arrays ? Is my code memory efficient ?

Narendra Modi
  • 851
  • 1
  • 13
  • 29
  • I assume this code is part of a method? If so, `A`, `B` and `C` will go out of scope as soon as your code leaves the method. The garbage collector will then take care of it, so you are good. Of course, you can always explicitly set them to `null`. – domsson Apr 15 '17 at 13:33
  • Have a look at *java garbage collector* to understand how objects are managed. Primitive types variables are just deleted when they go out of scope. – Jean-Baptiste Yunès Apr 15 '17 at 13:34
  • Please follow the naming conventions. – Lew Bloch Apr 15 '17 at 16:28

1 Answers1

8

As soon as A, B and C are out of scope, these are eligible to be garbage collected. In your example it means at the end of the for statement.

Now if these are not referenced by any other variables, you can make them eligible to be garbage collected right now after using it and without waiting for the end of the for statement by setting them to null ;

 A = new int[100];
 B = new int[100];
 C = boolean[100];

// processing where these are required
...
// processing where these are not required
 A = null;
 B = null;
 C = null;

It doesn't mean that it will free the memory right now but at least these objects will be considered as unused in the next collection of the GC.

EDIT

Recent JVM versions performs multiple optimizations at runtime (JIT).
You can found on the Oracle website some explanations about Just-In-Time Compilation and Optimization.
You can also found on the same page, some examples of JRockit optimizations runtime.

So, according to the used JVM versions, the assignment to null may be useless as the JVM may consider the objects as out of scope as soon as these are not used any longer in their scope, so before the end of the for statement.

The Stephen's answer to a close enough question suggests it.
Unfortunately, I have not found any concrete information about this specific optimization.

Community
  • 1
  • 1
davidxxx
  • 125,838
  • 23
  • 214
  • 215
  • 3
    There's no need to assign references to null. They will be garbage collected when they get out of scope and when the garbage collector wants. It's unpredictable. – fps Apr 15 '17 at 13:43
  • 3
    @Federico Peralta Schaffner Of course but if the end of the scope is "far" in the executed code, the objects will stay as referenced and potentially not collected while these are not required. It is the OP use case . – davidxxx Apr 15 '17 at 13:48
  • 1
    @Federico Peralta Schaffner "As soon as A, B and C are out of scope, these are eligible to be garbage collected. In your example it means at the end of the for statement. " is the first sentence of my answer. – davidxxx Apr 15 '17 at 13:49
  • See [this question](http://stackoverflow.com/questions/5690309/garbage-collector-in-java-set-an-object-null). – fps Apr 15 '17 at 13:55
  • 1
    @Federico Peralta Schaffner Thank you for this interesting link. It seems that some JVM versions may consider "unreachable" an object as soon as it is not used any longer. – davidxxx Apr 15 '17 at 14:03
  • 1
    Brian Goetz, author of much of the API and acknowledged Java guru, has written on the futility and harm of trying to "help" GC by nulling references. There are specific cases where you need to, otherwise it's a bad idea. @davidxxx if the end of scope is far enough away to affect GC adversely it's badly-written code. Anyway, GC isn't supposed to remove objects until they're not needed​. The key is to declare references in the minimum necessary scope and manage object lifetime. Nulling references is a hack for lazy programmers who don't think things through. – Lew Bloch Apr 15 '17 at 16:33
  • 1
    @Lew Bloch i agree with totally about a bad smell. Here a refactoring with an extracted method seems better than tricky code. – davidxxx Apr 15 '17 at 17:16