Group objects by reachability scope

When optimizing Java applications, understanding object reachability is very important for effective memory management and application performance. Java's garbage collector (GC) works on the premise of reachability, removing objects that are no longer reachable. In this context, reachability scopes can be categorized as strong reachable, soft reachable, weak reachable, and unreachable. Understanding these categories can provide valuable insights into the object lifecycle, helping to improve application performance.

• Understanding reachability scopes
• How to use grouping objects by their reachability scopes
• Tips and tricks
• Object reachability scopes in the profiler UI

Understanding reachability scopes

Strong reachable objects

In the context of Java's garbage collection, being strongly reachable ensures that an object will not be garbage-collected, since the garbage collector identifies such objects as still in use. Strongly reachable object in Java is an object that is accessible through a chain of strong references from any of the root objects, ensuring that it is not eligible for garbage collection.

Soft or weak reachable

In Java, objects that are not strongly reachable but are still accessible in some manner are categorized as either weakly reachable or softly reachable, depending on the type of references that point to them. Both weak and soft references are specialized reference types provided by the Java standard library, designed to allow more flexible memory management and garbage collection behavior.

An object is considered softly reachable if it is not strongly reachable but can be reached by traversing a soft reference. A soft reference is represented by the java.lang.ref.SoftReference class in Java. Softly reachable objects are generally cleared by the garbage collector only when the JVM is low on memory. This makes soft references useful for implementing memory-sensitive caches; the JVM will hold onto softly reachable objects as long as memory is plentiful, but will reclaim them when memory becomes scarce.

An object is considered weakly reachable if it is not strongly or softly reachable but can be reached by traversing a weak reference. A weak reference is represented by the java.lng.ref.WeakReference class in Java. Unlike soft references, weak references do not prevent their referents from being garbage-collected. This means that the garbage collector can reclaim an object that is only weakly reachable at any time, regardless of the current memory status. Weak references are often used in mappings and collections to allow for automatic removal of elements that are no longer in use.

Unreachable or dead objects

In Java, an object is considered unreachable or dead when no strong, soft, or weak references to it exist, and no threads can access it by any means. In simpler terms, an object is unreachable when there's no way for the program to use or manipulate it. Such an object is eligible for garbage collection, meaning that its memory can be reclaimed by the Java Virtual Machine (JVM) to be used for other objects. Unreachable objects are the primary candidates for garbage collection because they no longer serve any purpose in the program and retaining them would constitute a memory leak.

Objects pending finalization

In Java, an object may have a finalize() method, which is a mechanism to perform cleanup activities before the object is garbage-collected. When an unreachable object has a non-trivial finalize() method (i.e., one that has been overridden to provide some functionality), the object is placed in the "finalization queue." Objects in this queue are considered pending finalization.

The garbage collector sets aside such objects to allow their finalize() methods to run one last time before being collected. Once the finalize() method has been invoked and executed, the object is then moved out of the finalization queue and becomes eligible for garbage collection again. At this point, if the object becomes unreachable once more, it will be collected without a further delay, as the finalize() method is only invoked once by the garbage collector for any given object.

Note: The use of finalize() is generally discouraged in modern Java programming due to its unpredictable behavior and performance implications. Java's try-with-resources and other cleanup mechanisms are usually preferable for resource management.

How to use grouping objects by their reachability scopes?

1. Identify memory leaks: Objects that are intended to be short-lived but remain strongly reachable are signs of a memory leak.

2. Fine-tuning GC: By analyzing the kinds of objects in different scopes, you can make better decisions on garbage collection tuning, including choosing the right GC algorithm.

3. Caching decisions: Understanding that some objects move between soft reachable and strong reachable states can be useful for implementing or optimizing a cache.

Tips and tricks

1. Avoid premature optimization: Always measure before optimizing. Use profiler to identify which objects are in which reachability scope.

2. Strong reachability with caution: Only keep objects strongly reachable if they are actually needed. Keeping unnecessary objects as strongly reachable prevents them from being garbage-collected.

3. Automate analysis: Integrate memory profiling and object reachability analysis into your CI/CD pipeline, if possible, to catch issues early.

Object reachability scopes in the profiler UI

The main view where object reachability scopes are displayed is Memory > Objects by category > Reachability:

The reachability scope for individual objects (except strong reachable) is shown in object explorer:

Action Memory | Instances by Class... (Ctrl+N) allows you to choose the reachability scope of objects to open: