Does using final for variables in Java improve garbage collection?

by

Here’s a slightly different example, one with final reference-type fields rather than final value-type local variables:

public class MyClass {

   public final MyOtherObject obj;

}

Every time you create an instance of MyClass, you’ll be creating an outgoing reference to a MyOtherObject instance, and the GC will have to follow that link to look for live objects.

The JVM uses a mark-sweep GC algorithm, which has to examine all the live refereces in the GC “root” locations (like all the objects in the current call stack). Each live object is “marked” as being alive, and any object referred to by a live object is also marked as being alive.

After the completion of the mark phase, the GC sweeps through the heap, freeing memory for all unmarked objects (and compacting the memory for the remaining live objects).

Also, it’s important to recognize that the Java heap memory is partitioned into a “young generation” and an “old generation”. All objects are initially allocated in the young generation (sometimes referred to as “the nursery”). Since most objects are short-lived, the GC is more aggressive about freeing recent garbage from the young generation. If an object survives a collection cycle of the young generation, it gets moved into the old generation (sometimes referred to as the “tenured generation”), which is processed less frequently.

So, off the top of my head, I’m going to say “no, the ‘final’ modifer doesn’t help the GC reduce its workload”.

In my opinion, the best strategy for optimizing your memory-management in Java is to eliminate spurious references as quickly as possible. You could do that by assigning “null” to an object reference as soon as you’re done using it.

Or, better yet, minimize the size of each declaration scope. For example, if you declare an object at the beginning of a 1000-line method, and if the object stays alive until the close of that method’s scope (the last closing curly brace), then the object might stay alive for much longer that actually necessary.

If you use small methods, with only a dozen or so lines of code, then the objects declared within that method will fall out of scope more quickly, and the GC will be able to do most of its work within the much-more-efficient young generation. You don’t want objects being moved into the older generation unless absolutely necessary.

More Related Contents:

  1. How can I read a large text file line by line using Java?
  2. Change private static final field using Java reflection
  3. Why is it bad practice to call System.gc()?
  4. When is the finalize() method called in Java?
  5. Difference between final and effectively final
  6. How does the “final” keyword in Java work? (I can still modify an object.)
  7. Does GC release back memory to OS?
  8. Does use of final keyword in Java improve the performance?
  9. Is there a destructor for Java?
  10. Why should I use the keyword “final” on a method parameter in Java?
  11. Why would one mark local variables and method parameters as “final” in Java? [closed]
  12. When will a string be garbage collected in java
  13. Why would one declare an immutable class final in Java?
  14. Garbage collector in java – set an object null
  15. In Java, when does an object become unreachable?
  16. final keyword in method parameters [duplicate]
  17. in what order are static blocks and static variables in a class executed? [duplicate]
  18. Circular References in Java
  19. How can I avoid garbage collection delays in Java games? (Best Practices) [closed]
  20. When Is The Object Eligible For Garbage Collection?
  21. Why are all fields in an interface implicitly static and final?
  22. Size of Huge Objects directly allocated to Old Generation
  23. creating final variables inside a loop
  24. Why does the JVM require warmup?
  25. The final local variable cannot be assigned
  26. Garbage collection on intern’d strings, String Pool, and perm-space
  27. How to make a long time Full GC in Java manually
  28. Default garbage collector for Java 8
  29. Measuring time spent on GC
  30. When does Java’s garbage collection free a memory allocation?

Leave a Comment