Circular References in Java

JavaMemoryMemory ManagementMemory LeaksGarbage Collection

Java Problem Overview


Given an aggregation of class instances which refer to each other in a complex, circular, fashion: is it possible that the garbage collector may not be able to free these objects?

I vaguely recall this being an issue in the JVM in the past, but I thought this was resolved years ago. yet, some investigation in jhat has revealed a circular reference being the reason for a memory leak that I am now faced with.

Note: I have always been under the impression that the JVM was capable of resolving circular references and freeing such "islands of garbage" from memory. However, I am posing this question just to see if anyone has found any exceptions.

Java Solutions


Solution 1 - Java

Only a very naive implementation would have a problem with circular references. Wikipedia has a good article on the different GC algorithms. If you really want to learn more, try (Amazon) Garbage Collection: Algorithms for Automatic Dynamic Memory Management . Java has had a good garbage collector since 1.2 and an exceptionally good one in 1.5 and Java 6.

The hard part for improving GC is reducing pauses and overhead, not basic things like circular reference.

Solution 2 - Java

The garbage collector knows where the root objects are: statics, locals on the stack, etc and if the objects aren't reachable from a root then they will be reclaimed. If they are reachable, then they need to stick around.

Solution 3 - Java

Ryan, judging by your comment to https://stackoverflow.com/questions/176745/circular-references-in-java#176767, you fell into the trap of referencing objects from a class, which was probably loaded by the bootstrap/system classloader. Every class is referenced by the classloader that loaded the class, and can thus be garbage-collected only if the classloader is no longer reachable. The catch is that the bootstrap/system classloader is never garbage collected, therefore, objects reachable from classes loaded by the system classloader cannot be garbage-collected either.

The reasoning for this behavior is explained in JLS. For example, Third Edition 12.7 http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.7.

Solution 4 - Java

If I remember correctly, then according to the specifications, there are only guarantees about what the JVM can't collect (anything reachable), not what it will collect.

Unless you are working with real-time JVMs, most modern garbage collectors should be able to handle complex reference structures and identify "subgraphs" that can be eliminated safely. The efficiency, latency, and likelihood of doing this improve over time as more research ideas make their way into standard (rather than research) VMs.

Solution 5 - Java

No, at least using Sun's official JVM, the garbage collector will be able to detect these cycles and free the memory as soon as there are no longer any references from the outside.

Solution 6 - Java

The Java specification says that the garbage collector can garbage collect your object ONLY If it is not reachable from any thread.

Reachable means there is a reference, or chain of references that leads from A to B, and can go via C,D,...Z for all it cares.

The JVM not collecting things has not been a problem for me since 2000, but your mileage may vary.

Tip: Java serialization caches objects to make object mesh transfer efficient. If you have many large, transient objects, and all your memory is getting hogged, reset your serializer to clear it's cache.

Solution 7 - Java

A circular reference happens when one object refers to another, and that other one refers to the first object. For example:

class A {
private B b;

public void setB(B b) {
    this.b = b;
}
}

class B {
private A a;

public void setA(A a) {
    this.a = a;
}
}

public class Main {
public static void main(String[] args) {
    A one = new A();
    B two = new B();

    // Make the objects refer to each other (creates a circular reference)
    one.setB(two);
    two.setA(one);

    // Throw away the references from the main method; the two objects are
    // still referring to each other
    one = null;
    two = null;
}
}

Java's garbage collector is smart enough to clean up the objects if there are circular references, but there are no live threads that have any references to the objects anymore. So having a circular reference like this does not create a memory leak.

Solution 8 - Java

Just to amplify what has already been said:

The application I've been working on for six years recently changed from Java 1.4 to Java 1.6, and we've discovered that we've had to add static references to things that we didn't even realize were garbage collectable before. We didn't need the static reference before because the garbage collector used to suck, and it is just so much better now.

Solution 9 - Java

Reference counting GCs are notorious for this issue. Notably, Suns JVM doesn't use a reference counting GC.

If the object can not be reach from the root of the heap (typically, at a minimum, through the classloaders if nothing else0, then the objects will be destroyed as they are not copied during a typical Java GC to the new heap.

Solution 10 - Java

The garbage collector is a very sophisticated piece of software -- it has been tested in a huge JCK test-suite. It is NOT perfect BUT there is a very good chance that as long as the java compiler(javac) will compile all of your classes and JVM will instantiate it, then you should be good.

Then again, if you are holding references to the root of this object graph, the memory will NOT be freed BUT if you know what you're doing, you should be OK.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionRyan DelucchiView Question on Stackoverflow
Solution 1 - JavaDavid GView Answer on Stackoverflow
Solution 2 - JavaRob WalkerView Answer on Stackoverflow
Solution 3 - JavaAlexanderView Answer on Stackoverflow
Solution 4 - JavaUriView Answer on Stackoverflow
Solution 5 - JavaThiloView Answer on Stackoverflow
Solution 6 - JavaTim WilliscroftView Answer on Stackoverflow
Solution 7 - JavaRupeshView Answer on Stackoverflow
Solution 8 - JavaPaul TomblinView Answer on Stackoverflow
Solution 9 - JavaWill HartungView Answer on Stackoverflow
Solution 10 - JavaanjanbView Answer on Stackoverflow