Thread Instantiation

[Shouvik Bhattacharya]

class MyThread extends Thread{
public void run(){
System.out.print("Hi");
}
}
public class TestThread{
public static void main(String... a){
//CASE-1:
MyThread mt = new MyThread();
mt.start();


//OR

//CASE-2:
Thread t = new Thread(mt);
t.start();
}
}

I have doubt i.e. what is the difference between CASE-1 and CASE-2. As far as my understanding goes about they both should start run method in MyThread. Apart from this is there any other concept?

[Chan Ag]

One of the 'other things' which is quite important is that inheriting Thread class for the sole purpose of creating an independently executing task is not a good idea. The recommended approach is to implement the Runnable interface. This is also in line with the general inheritance guideline that inheritance should always have a proper reason. Though that is not what you asked, it is quite important.

In the case 1 ( it is not a recommended way ), you are making use of inheritance to create a Thread and your subclass is not really defining new policies for the Threads in your application. So I don't see why it should be used at all. And even if your application needs to define newer policies for the Threads of your application, you don't have to subclass the Thread class. The Thread class and the other classes in the JDK core libraries have good support for define threading policies at very granular levels without you having to subclass the Thread class.

<Edit>
I assume that by case 2, you mean the following.

MyThread mt = new MyThread();  
Thread t = new Thread(mt);  
t.start();  

</Edit>

A Thread is a Thread. So yes, case 2 is similar to case 1 but the Thread class has that constructor so that you can create a Thread from a Runnable. I see no good in passing a Thread to the Thread constructor that takes a Runnable. Remember that this way you might be holding on to a Thread reference longer than you should. I think this may also result in Thread memory leaks which are quite difficult to resolve.

[Shouvik Bhattacharya]

Thank You for this lucid explanation.

[Henry Wong]

Chan Ag wrote:
A Thread is a Thread. So yes, case 2 is similar to case 1 but the Thread class has that constructor so that you can create a Thread from a Runnable. I see no good in passing a Thread to the Thread constructor that takes a Runnable. Remember that this way you might be holding on to a Thread reference longer than you should. I think this may also result in Thread memory leaks which are quite difficult to resolve.

Chan,

Can you elaborate on this a bit? What are the memory leaks that you are referring to?

Henry

[Chan Ag]

Henry Wong wrote:

Chan Ag wrote:
A Thread is a Thread. So yes, case 2 is similar to case 1 but the Thread class has that constructor so that you can create a Thread from a Runnable. I see no good in passing a Thread to the Thread constructor that takes a Runnable. Remember that this way you might be holding on to a Thread reference longer than you should. I think this may also result in Thread memory leaks which are quite difficult to resolve.

Chan,

Can you elaborate on this a bit? What are the memory leaks that you are referring to?

Henry

If we imagine an application with many threads created in the case 2 way, i.e we first create a thread and have a reference to that thread and then create another reference of that Thread by assigning it to the Runnable of another Thread, couldn't we come across a case where a thread cannot be garbage collected because its reference is held by another thread even through the first thread has finished. What if this second thread's reference also couldn't be garbage collected because it was held by another thread.

The OP has a simple example but if we generalize the idea, I thought that this way we are unnecessarily holding on to Thread references ( which like any other object has a state and should be garbage collected once its run method is done ) and I thought we shouldn't do that. But I could be wrong.

Edit : Thread referencesobjects ( which like any other object has a state and should be garbage collected once its run method is done and there are no variables pointing to that Thread object. )

[Henry Wong]

Chan Ag wrote:
If we imagine an application with many threads created in the case 2 way, i.e we first create a thread and have a reference to that thread and then create another reference of that Thread by assigning it to the Runnable of another Thread, couldn't we come across a case where a thread cannot be garbage collected because its reference is held by another thread even through the first thread has finished. What if this second thread's reference also couldn't be garbage collected because it was held by another thread.

The OP has a simple example but if we generalize the idea, I thought that this way we are unnecessarily holding on to Thread references ( which like any other object has a state and should be garbage collected once its run method is done ) and I thought we shouldn't do that. But I could be wrong.

Edit : Thread references ( which like any other object has a state and should be garbage collected once its run method is done and there are no variables pointing to that Thread object. )

Oh, I see... first, lets distinguish between creating a thread and creating a thread object. The example creates a thread object, but doesn't actually create a thread -- that happens when the start() method is called. So, the MyThread object is merely being used as a Runnable object in the example... Now, granted the MyThread instance won't be GC, but it is being used by the thread (as a runnable), so it shouldn't be garbage collected.

Hope this helps,
Henry