First - you can't "kill the Object "A" explicitly"; you can clear the reference to it, but that just sets a local variable to null
, and has nothing to do with the actual object on the managed heap. You can Dispose()
it, but that is nothing to do with GC.
It all depends; can anything else see B
/ C
? If not, they are eligible for collection. But GC is non-deterministic; it only happens when it chooses. At some indeterminate time, GC will kick in, detect that these objects are unreachable, and remove them. In the process, it will check for any that have finalizers (that are still outstanding), and execute the finalizers (in a 2-step process).
One thing people often forget about in terms of reachability is events; if B
/C
subscribe to events on a long-lived object, then B
/C
are reachable (by the event publisher).
To clarify; GC works by building a tree from the root objects (threads, etc). It walks every reference, flagging all the objects that can be reached. Anything that isn't flagged at the end is eligible for collection. This avoids the COM/COM+ issue of getting memory leaks due to disconnected islands of data, where X => Y and Y => X (so both X and Y have positive ref-counts, so neither gets cleared).