Java Thread Garbage Collected or Not

Java Thread Garbage collected or not

A running thread is considered a so called garbage collection root and is one of those things keeping stuff from being garbage collected. When the garbage collector determines whether your object is 'reachable' or not, it is always doing so using the set of garbage collector roots as reference points.

Consider this, why is your main thread not being garbage collected, no one is referencing that one either.

When thread in Java is removed from memory?

The Thread class is a proxy for the real thread which is in native memory.

I hope my assumption is correct that once thread finishes its run() method it becomes eligible for garbage collection.

There is actually a bit of code after run(), this code handles uncaught exceptions.

Once the thread dies its native memory and stack are freed immediately without needing a GC. However, the Thread object is like any other object and it lives until it is GC has decided it can be free e.g. there is no strong reference to it.

Similarly, a FileOutputStream is a proxy for a file in the operating system. You can still have a reference to the object even after the file has been close() or even deleted.

If it doesn't become eligible for garbage collection after returning from run(), should one set its reference to null to do that?

You rarely need to do this anywhere. In fact it is often simpler not keep a reference to the thread in the first place, or to use an ExecutorService to manage your threads.

When I have an object which has a Thread field I often have this object die when the thread dies, thus the field doesn't need to be nulled out.

I also use the built in thread pool used for Fork/Join. This is a more light weight way to perform tasks in a background thread as it doesn't create and destroy threads so much.

ExecutorService fjp = ForkJoinPool.commonPool();

Being eligible for garbage collection doesn't necessarily mean that the object will be removed from memory. It is at the sole discretion of the underlying operating system / JVM when it is garbage collected. But how can one make sure (either through a Java program or external tool) that the object is completely removed from the memory?

You can't and generally shouldn't try. The GC will clean up resources when it needs to.

If a thread is said to be dead once it finishes its run() method, why can I still be able to execute isAlive() or getState() on the same thread object? Both the calls return false and RUNNABLE respectively.

The thread object is like any other object. You can call methods on it for as long as you hold a reference to it.

Garbage Collection on Island of Isolation

why the thread objects with no reference in the main class are not calling finalize

The garbage collector considers active threads as live, even if nothing else references those threads.

In other words, garbage collection does not make running code suddenly terminate. It would be a major headache if it did.

On top of that, you've only implemented finalize on a class which you never instantiate.

Java threads and garbage collector

1. Any object which is referenced by an active thread may not be de-allocated.
2. Yes, instances will be removed by the GC after the thread in `run()' ends.
3. No prob.

Java thread garbage collection

First, in Java GC is non-deterministic. When the object is no longer referenced, it is suitable to be collected in the next GC run, but it is not mandated. Even calling System.gc() is just a suggestion to the GC system.

Second, what counts is references. In each instance of the loop, you overwrite the reference to the thread object. If the threads have finished, there is no need to exit the method to have them collected (of course, while the threads are running they won't be collected, even if your code has no references to it). The issue of exiting the method where the object was created is not relevant.

Java Threads and Garbage Collection

First, a thread (stack) is only a GC root while it is alive. When the thread terminates, it is no longer a GC root.

My confusion is here: If the objects allocated from within a thread can never be garbage collected until the thread is stopped, how then is anything garbage collected in single-threaded programs where the only thread is the main thread ?

Your premise is incorrect.

It doesn't matter which thread allocates an object. What matters is whether an objects allocated by your thread remains reachable. If it become unreachable (for example, if you didn't put the object's reference into a local variable) ... then it can be collected.

Garbage Collector doesn't immediately collect finished thread

Could it be that you are asking the wrong question? What I mean: is the fact that garbage collection is not happening "immediately" a problem for you?

I am pretty sure - when you start another such thread that needs a lot of memory, the GC will kick in all by itself.

If that "delay" is actually a problem for you, you might consider doing the "very deep dive" in order to understand how GC actually works for your version of the JVM; to then start using the many many command line options that exist to fine-tune GC behavior to your needs.

But if a "delay" in freeing up memory (to other Java objects) is not an issue; then don't start fixing it.

---

Related Topics