File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes Thread t=null ! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Thread t=null !" Watch "Thread t=null !" New topic
Author

Thread t=null !

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
if a thread t is created in main and set to null
i.e
t=null;
what will happen:
a> thread will continue running
b> thread will terminate
c> none of these
ankit joshi harishkumar
Greenhorn

Joined: Mar 17, 2005
Posts: 3
a


hi thanx for reply
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
I had tested this with a program, the answer should be "the Thread will continue running for a while until it is GCed. Since it is eligible for GC."
Not a good test question anyway.
Roseanne
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
I disagree that the thread is eligible for GC. I'm assuming that the thread has been started successfully, since the answer options include "continue running" and "terminate". In that case, there is no need for any other thread to retain a reference to it - it will remain alive, either executing or waiting, until the run() method completes normally. It doesn't need any references to it to prevent GC. JLS 12.6.1 elaborates on finalization and the garbage collection process, and defines a reachable object: "A reachable object is any object that can be accessed in any potential continuing computation from any live thread." Obviously a live thread can access itself (e.g. through Thread.currentThread()) and so a live thread cannot be garbage collected. We can also see this by executing the following program:

Here you'll see that no matter how many times System.gc() is called, the thread formerly referenced by "t" will not be GC'ed.


"I'm not back." - Bill Harding, Twister
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Jim,
You are right again! I run your program which proved it.
Interesting enough! This means I was wrong last time when I answered a guy's question on Mr. Green's site. That question caused I produced our SCJD group's FlagApplet (a nice byproduct at http://www.geocities.com/roseannezhang/Flag/FlagApplet.html).
I think that I did not test his code (which created too many threads and set them to null whenever user clicked a button) enough and got the wrong conclusion. My answer to him was mostly right except the GC part.
I'm so glad I put the wrong post here, and now get the right answer. Thanks a lot!!!
Roseanne
[This message has been edited by roseannezhang (edited August 13, 2000).]
[This message has been edited by roseannezhang (edited August 13, 2000).]
Rahul Mahindrakar
Ranch Hand

Joined: Jul 28, 2000
Posts: 1859
I think there are two definitions of a Thread
The first is a "Thread Object"
The second is a "Path of execution".
When we talk of Threads we normally talk of path of Execution. The API has introduced the Thread Object as a means to create threads, or a different path of execution.
The thread Object contains the methods and the fields of the Thread Object in memory. By setting a Thread Object to null one cannot invoke or access any of the methods or fields. The object is thus available to the Garbage collector. Any further access of the reference would give you a null pointer exception.
while the path of execution refers to an abstract concept of how the processor goes about doing its job. There is no such thing as Garbage collection to the "Path of Execution".

What happens when you create a new thread by
Thread t=new Thread(this);
Thread t =new Thread(Runnable r);
Thread t=new Thread(Thread x);
One is passing a reference of either a Runnable Object or Thread Object to a new "Path of Execution". This reference is stored by this path as it needs to do its work.
for example the defintion of thread may be as follows
Class Thread {
Runnable run;
Thread(Runnable R){
run=R)
}
}

Thus even when the current thread sets the thread reference to null the Thread Object is not garbage collected nor are the parameters(Runnable or Thread Object) passed GC'd since another reference exists in the new "Path of Execution" created.

Before line 3 (Code 2) there are two theads . The first thread is the main thread and the second thread is the t thread, both are user threads. In the t thread the for loop is being continuously invoked, and value of i is being printed. After line 3 no change has taken in the t thead state. The state of an object can only be changed by invoking methods on it. for example by invoking stop() , which is now deprecated one could have changed the state of the t Object.
Or by keeping a variable example boolean t as in the following code at line 1
Code 1

since this has not taken place here the t object can continue doing its job till it is over.
Code 2

Regds
Rahul
[This message has been edited by Rahul Mahindrakar (edited August 13, 2000).]
rohit kuttappan
Greenhorn

Joined: Oct 10, 2000
Posts: 4
Jim says: "A reachable object is any object that can be accessed in any potential continuing computation from any live thread." Obviously a live thread can access itself (e.g. through Thread.currentThread()) and so a live thread cannot be garbage collected." So true. But what happens when the run method returns and the thread is dead?
mohit joshi
Ranch Hand

Joined: Sep 23, 2000
Posts: 243
Before answering the above question, let me thank Jim for his to the point answer above, it removed some of the misconceptions I was living with. Thanks a lot.
When the run method returns and the thread is dead, it still cannot be gced as long as it can be referenced from any live thread.
mohamed zafer
Ranch Hand

Joined: Nov 03, 2000
Posts: 62
Thanks Jim
I had been in misconception that the thread will terminate when assigned to null, but u proved me wrong. Now let me come to my problem
Here is my code
public void method()
{
if (th!=null)
{
th=null;/*if any thread i want to terminate it, what should i substitute here.*/
}
/* i m creating a new thread */
th = new Thread(this);
th.start();
}
public void run()
{
try
{
while(true)
{
//some code here
}
}
catch (InterruptedException ie)
{
}
}
THere are frequent calls to method() on which i want to terminate the previously existing thread and start a new one.But
in the above situation the thread does not terminate as i had thought. i substituted destroy() but it is giving rise to an Exception. so what is the possible solution for that.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Rohit- if (as in the original example) there are no other living threads which hold a reference to a given thread, then once that thread's run() method finishes it becomes eligible for garbage collection. As Mohit says though, if there are any other references to it in other (living) threads, it isn't eligible for GC, even though it's dead.
Mohamed- you should read Why Are Thread.stop, Thread.suspend,
Thread.resume and Runtime.runFinalizersOnExit Deprecated?
. Basically, it's a bad idea to force a thread to stop fro another thread - you should find a way to signal the thread you need to stop, and write that thread so that it checks periodically to see if it needs to stop itself. You may find some of the books listed at the top of this page helpful - this subject can get complicated.
Rob Whelan
Ranch Hand

Joined: Oct 18, 2000
Posts: 33
I think Jim has explained the original question thoroughly enough -- this is in response to Rahul M's post.
In general, a good summary, but there are a few small things I wanted to clarify:
First of all, there is no constructor "new Thread(Thread x)". This will compile, but only because Thread implements Runnable. I can't think of any reason to ever use this construction.
Second, I do like the "Thread of Execution" idea (an old prof of mine used to say you were creating a "finger in your code" that would walk independantly through each line starting in run()); however, be careful not to mix this idea up with the objects we're actually dealing with:
Thus even when the current thread sets the thread reference to null the Thread Object is not garbage collected nor are the parameters(Runnable or Thread Object) passed GC'd since another reference exists in the new "Path of Execution" created

I think the concepts are getting mixed up here. The new Thread object (in the native side of the implementation) is where that reference exists -- a "Thread of Execution" doesn't have "references". Much of Thread's functionality is handled in native code (including CPU management, but also maintenance of variable copies, lock maintenance, etc.), but that is transparent to the programmer.
Another comment I can add -- your summary definition of "what the Thread class might look like" is perfectly right (though of course there's other stuff in there). The constructor merely sets the Runnable object "target", and the Thread's run() method just calls target.run(). The start() method -- of course -- is natively implemented.
[This message has been edited by Rob Whelan (edited December 03, 2000).]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thread t=null !