10

Suppose there is an object a of class A, which holds a reference to another object b of class B. And this is the only reference to b. So now, if all references to a is removed, then a is ready to GC. Does this mean that b is also ready to get garbage collected? because, though b has a reference ( inside a ), it is unreachable, because a is unreachable.

So how exactly does this scenario works? I mean the order of garbage collection.

Raedwald
  • 46,613
  • 43
  • 151
  • 237
shar
  • 1,988
  • 2
  • 18
  • 25
  • possible duplicate of [Garbage Collection in Java and Circular References](http://stackoverflow.com/questions/1910194/garbage-collection-in-java-and-circular-references) –  Jul 06 '13 at 17:28
  • 1
    Its better to think of the garbage collector figuring out what **isnt** eligable for garbage collection and collecting the rest. If it can be seen from the root then it isnt eligable – Richard Tingle Jul 06 '13 at 17:55

5 Answers5

13

Once an object is unreachable from a root, it will be collected. See this question for an explanation of GC roots.

Entire subgraphs will be collected (as you describe) presuming no node within that subgraph may be reached.

Java (and .NET) use mark and sweep garbage collection which deals with this kind of problem.

Reference count-based systems (such as C++'s std::shared_ptr<T>) may fail in the case of circular dependencies that remain unreachable. This is not a problem for Java/.NET GC.

Community
  • 1
  • 1
Drew Noakes
  • 300,895
  • 165
  • 679
  • 742
  • 3
    If there is one downvoter who downvotes for no reason, then there are other people like me who upvote for a good answer :) – Prasad Kharkar Jul 06 '13 at 19:03
1

Java GC is smart enough to collect islands of isolated objects though they maybe pointing to each other. Hence, b also becomes eligible for garbage collection. The point to note here is that although you have a reference to b it's not live in the sense that it cannot be reached from your program's root.

Ravi K Thapliyal
  • 51,095
  • 9
  • 76
  • 89
0

It depends on the GC. A JVM can be told to use different GC's and typically uses 3 GC's as one (eden, copy, markcompact).

In any typical GC and in refcounting the situation you described is handled cleanly, both objs are collected. Think of it in 2 stages: first "a" gets noticed and collected then "b" gets noticed and collected. Again: the specific means of noticing depends on the GC.

Bernd Elkemann
  • 23,242
  • 4
  • 37
  • 66
  • It's my experience that refcounting fails if you have circular references. That is, if A->B and B->A, both have a count of one, yet neither is reachable. – Drew Noakes Jul 06 '13 at 17:27
  • 2
    There is no reference from "b" to "a" in what the OP described. – Bernd Elkemann Jul 06 '13 at 17:28
  • True, but if I'm not mistaken your answer didn't take that emphasis before your edit. At any rate, GC is a huge topic that OP is apparently new to and we may be getting away from the introductory aspects :) – Drew Noakes Jul 06 '13 at 17:49
  • @DrewNoakes my answer has not been edited maybe you saw the one 2 minutes before mine (Ravi's answer) – Bernd Elkemann Jul 06 '13 at 17:52
0

Even if the objects reference internally to each other, and they do not have a reachable reference from program, they will be eligible for GC. THere is a good explanation with diagrams here

http://www.thejavageek.com/2013/06/22/how-do-objects-become-eligible-for-garbage-collection/

Prasad Kharkar
  • 13,410
  • 5
  • 37
  • 56
-1

That is exactly the point of GC. Since b is unreachable from main thread, it will be garbage collected. It is not just the count that matters.

fastcodejava
  • 39,895
  • 28
  • 133
  • 186