How does Java garbage collector work here?

Question

In this query remove() method has following implementation.

 /**
   *  remove() removes "node" from this DList.  If "node" is null, do nothing.
   *  Performance:  runs in O(1) time.
   */
  public void remove(DListNode node) {
    if((node != null) && (node.listp == this)){
        node.prev.next = node.next;
        node.next.prev = node.prev;
    }
    this.size--;
  }

After the execution of this remove() method, There would not be any inward pointer pointing to object unless the user of DList class still points to this node using some reference variable.

My question:

When and How does garbage collector trash this object after none of the reference pointers point to this object? Because How can GC get control of that object without any reference to it?

Do you really want to know _when_ it happens or just _how_ it can work without remaining references to the node? Your question title indicates the former, your text indicates the latter. — random6174, Oct 06 '14 at 18:17
@random6174 How it happens? and when? In C++, when you write such `DList` class we also keep track of memtrack feature on our own to check th health of the memory before allocating more nodes. — overexchange, Oct 06 '14 at 18:20
Java isn't _required_ to have a garbage collector at all, and different implementations do this in different ways. All you're _guaranteed_ is that an object won't be released until you drop all strong references to it. — Joachim Isaksson, Oct 06 '14 at 18:20
There may be no reference to an object available for user code but the JVM still keeps track of every object. In fact at this point, talking about "reference" is becoming wrong, because there are several types of references: strong, soft, weak and phantom and they all affect the way an object interacts with GC. — biziclop, Oct 06 '14 at 18:22
To my knowledge, the Java GC keeps its own references to all objects and uses a Mark-And-Sweep algorithm to remove such objects that the user does not (directly or indirectly) reference anymore. The timing is undefined. — random6174, Oct 06 '14 at 18:22
@random6174 There are quite a few different algorithms in place but yeah, the general idea is that internally the JVM will keep track of every object, not just the live ones. — biziclop, Oct 06 '14 at 18:24
@biziclop the references that are made while instantiating class using what type of reference? GC refers using what type of reference? — overexchange, Oct 06 '14 at 18:24
It's reclaimed precisely *because* there are no references to it. — Hot Licks, Oct 06 '14 at 18:41
With a pure copying garbage collector there's no need to have *any* sort of reference to the object. Rather, all "live" objects in the space are copied elsewhere, then the space is reclaimed. Other GC paradigms work differently. — Hot Licks, Oct 06 '14 at 18:43

score 2 · Answer 1 · edited May 23 '17 at 12:02

An object may be GC'ed/reclaimed at any point after it is no longer strongly reachable. An object is strongly reachable if and only if it can be reached (via strong references) from a GC root. That is, the GC reclaiming an object - if and when it chooses to do so - is merely a consequence of not being able to access said object.

Now, the one thing that Java guarantees is that it will try it's best (which may involve doing nothing) to free memory before throwing an OOM.

Even though there are no strong references from the code doesn't mean that the JVM isn't tracking the object or that it has vanished! The object still exists - even though it is not strongly reachable (read: not accessible) from user code - until/when such is actually GC'ed.

This allows for some interesting cases, eg.

A finalizer has a this - access to the object to be GC'ed! - and can "relife" (or "resurrect") objects, which is bad. Note: while a finalizer being called roughly implies the object is finally going to be GC'ed; a finalizer is not guaranteed to be called, ever, etc.
ReferenceQueues and the *Reference types can be used to track objects that are no longer strongly reachable and thus are elligble to be GC'ed even though a strong reference may still be obtainable - and obtaining such would remove the reclaimable status.

score 1 · Answer 2 · answered Oct 06 '14 at 18:14

1

It is undefined. It could happen the next time the garbage collector runs (it can ONLY happy when the garbage collector runs), but that is not guarenteed - Not all garbage is necessarily cleaned with each gc run

answered Oct 06 '14 at 18:14

ControlAltDel

33,923
10
53
80

score 0 · Answer 3 · answered Oct 06 '14 at 18:16

Java's GC does not trash an object as soon as it's not used anymore. Instead, GC runs from time to time, checking objects' usage and emptying memory.

You cannot tell GC to run arbitrarily, but you can request it to run by calling System.gc(). However, calling gc() does not run GC AT THIS TIME... it will only request the System to run it.

How does Java garbage collector work here?

3 Answers3