0

is there any way to confirm if the thread is killed at the end of execution? If the garbage collector takes long time to destroy the threads even when they are available for GC, out of memory exceptions may arise. to get rid of those kind of issues, it would be good to know if the threads have been destroyed.

As of now, my understanding is that at the end of run method , the thread gets killed and we need not do anything explicitly to kill the thread instance.

Thanks in advance!

class A
{
    public static void main()
    {
        Thread t = new Thread(new TestA());
         t.start();
        Thread t1 = new Thread(new TestB());
         t1.start();
        Thread t2 = new Thread(new TestC());
         t2.start();
    }
}
class TestA implements Runnable {
Thread t;

    public void run() {
           for(...){
           try{

           }catch()
           {
            ....
           }
           } 
        }

 }
user1257836
  • 309
  • 2
  • 5
  • 10

6 Answers6

1

You are absolutely right that "at the end of run method, the thread gets killed and we need not do anything explicitly to kill the thread instance". Simply letting the thread leave its run() method normally is enough.

If you want to make sure that a particular thread has terminated, then Thread.isAlive() will check, and Thread.join() will wait until it happens. If you have a particular set of threads that you're worried about, then keep a reference to them somewhere, and check up on them using these methods.

Tom Anderson
  • 46,189
  • 17
  • 92
  • 133
0
Thread.getAllStackTraces()

gets you a current map of threads/stacktraces. However I would normally expect the JVM to clear up the threads upon exit from run(). Obviously if you're using some sort of thread pooling then that's not the case.

Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
  • thank you so much for your quick response. this is how i create the threads in my program. i have placed it as part of my question. hope i am doing the correct way. i keep reading in many articles that even expert developers find it difficult to develop bug free multithreaded programs.. thanks again! – user1257836 Mar 12 '12 at 18:13
  • Hi Brian, i am not using any thread pooling in my application. i am creating only 3 threads in the main method of my calling program and when the run() terminates, the 3 threads should be destroyed definitely. also, i have given my code snippet above. Please let me know if my understanding is correct. thanks! – user1257836 Mar 13 '12 at 19:58
0

You can use some softwares like visualvm to monitor the thread states . These kind of softwares will give you full flexibility to profile your application in a visual way.

To check the state of a thread , you can call the getState() method on a thread object to see the state of the thread.

Sabya
  • 1,419
  • 1
  • 10
  • 14
0

The javadoc of OutOfMemoryError says:

Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

So, if a thread is not running anymore and is eligible to GC, the GC will try to collect it before throwing an OOM. Like with any other object.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • thank you so much for your quick response. this is how i create the threads in my program. i have placed it as part of my question. hope i am doing the correct way. i keep reading in many articles that even expert developers find it difficult to develop bug free multithreaded programs.. thanks again! – user1257836 Mar 12 '12 at 18:20
  • You should never start a thread from a constructor. That is very bad practice. Construct your object, and then start it. – JB Nizet Mar 12 '12 at 19:05
  • Hi Nizet, thanks for letting me know. i have removed the constructor and changed the main(). I have modified the code in my question above. Please have a look at it and let me know if it is fine. Also, i am curious to know why it is a bad practice to start thread from a constructor? – user1257836 Mar 12 '12 at 19:29
  • http://stackoverflow.com/questions/5623285/java-why-not-to-start-a-thread-in-the-constructor-how-to-terminate – JB Nizet Mar 12 '12 at 19:31
0

is there any way to confirm if the thread is killed at the end of execution?

There's no sense confirming something you know to be true. Whenever the JVM process dies, all its threads are automatically killed by the operating system. Any other behavior is a bug in the OS.

If the garbage collector takes long time to destroy the threads even when they are available for GC, out of memory exceptions may arise.

The garbage collector doesn't kill threads - the JVM wraps operating-system-specific thread libraries into a consistent Java-language thread abstraction, so those thread libraries determine when a thread dies.

my understanding is that at the end of run method, the thread gets killed and we need not do anything explicitly to kill the thread instance.

That is correct.

Adam Mihalcin
  • 14,242
  • 4
  • 36
  • 52
  • thank you so much for your quick response. this is how i create the threads in my program. i have placed it as part of my question. hope i am doing the correct way. i keep reading in many articles that even expert developers find it difficult to develop bug free multithreaded programs.. thanks again! – user1257836 Mar 12 '12 at 18:07
0

If you look up in the javadoc for the Thread class you will see many methods that might help you check what you want, for example:

activeCount() : Returns the number of active threads in the current thread's thread group.

You can use this as a debug method.

isAlive() : Tests if this thread is alive.

To check if a specific thread is alive.

join() : Waits for this thread to die.

If you call this at the end of your method then it will wait for the thread to join (i.e. to end execution) before advancing. If you call for all threads, then you are sure that all have finished when the main() has finished.

destroy() : Destroys this thread, without any cleanup.

Does what it says, but I would never suggest this.

Hope it helps!

PhyBandit
  • 303
  • 2
  • 7