How to prevent Circular References with Dependency Injection and Garbage Collection?

I think I'm still trying to understand Dependency Injection and the role of the DI container.

If DI means a lower level component depends on a higher level one, and there's no circular reference, won't that object get garbage collected? As I see garbage collection (mark-and-sweep), it keeps only the objects that can be traced with a chain of references starting from the program root.

Since I'm having difficulty explaining myself, here are two UML diagrams, which present conflicting views of Dependency Injection, as I see it:

My original interpretation of DI

The DI Container injects components with their required references, and they each store a reference to their next-highest-in-command. The Main class has no way of reaching them, so they should be garbage collected.

My reconsideration of DI

The DI Container injects components with their required references and also maintains a r开发者_高级运维eference to each of them. They each store a reference to their next-highest-in-command. The Main class can reach any of them via the DI Container, so they shouldn't be garbage collected.

It is hard to understand what you are actually asking:

• All mainstream Java implementations have garbage collectors that can collect garbage with circular references ... or as they are more commonly called, reference cycles. So there's no particular reason to avoid reference cycles in DI from a GC perspective.

• If an object contains a reference to another object, then the second object won't be collected as long as the first object is reachable. Objects created by DI are no different to others in the respect.

• Explicitly declared dependencies tell the DI framework that certain objects need to be constructed and wired before others. They don't say what needs to be wired to what, and whether or not there are (Java level) reference cycles.

@JonnyReeve's answer says this:

"broadly speaking, a reference (object) will only be eligible for garbage collection when zero references remain (eg: you are not able to programmatically access it)"

This is misleading. Obviously, an object which contains a reference to itself has (at least) one reference remaining, yet if that is the only existing reference, the object is eligible for garbage collection nevertheless.

In fact, an object is eligible for collection if it is not reachable. For Java, this is defined (JLS 12.6.1) as follows:

"A reachable object is any object that can be accessed in any potential continuing computation from any live thread."

Note the careful way that this is worded. It means that an object can be garbage collected while local variables still refer to it ... provided that the JVM can tell that no future computation will access the object.

Garbage collection in the AVM is a pretty large subject; rather than attempt to go over the finer points here I would suggest you start off by reading Grant Skinner's article on Resource Management.

To answer your question about references; broadly speaking, a reference (object) will only be eligible for garbage collection when zero references remain (eg: you are not able to programmatically access it); often times this is achieved by simply nulling out a reference; for example:

public class Client {
    private var myFoo : Foo;

    public function Client() {
        // myFoo will count as a reference; it will not be 'swept'
        myFoo = new Foo();

        // Business as usual.
        myFoo.bar();
    }

    public function destroy() : void {
        // Remove the reference to myFoo, it can now be 'swept' as no other
        // references remain to it and there is no way to access it.
        myFoo = null;

        // This will trip a Null Reference Error because myFoo is no longer a
        // reference to the 'Foo' instance.
        myFoo.bar();
    }
}