Why can't a Java Thread object be restarted?

I know that it is not possible to restart a used Java Thread object, but I don't find an explanation why this is not allowed; even if it is guaranteed that the thread has finished (see example code below).

I don't see why 开发者_运维百科start() (or at least a restart()) method should not be able to somehow reset the internal states - whatever they are - of a Thread object to the same values they have when the Thread object is freshly created.

Example code:

class ThreadExample {

  public static void main(String[] args){

    Thread myThread = new Thread(){
      public void run() {
        for(int i=0; i<3; i++) {
          try{ sleep(100); }catch(InterruptedException ie){}
          System.out.print(i+", ");
        }
        System.out.println("done.");
      }
    };

    myThread.start();

    try{ Thread.sleep(500); }catch(InterruptedException ie){}
    System.out.println("Now myThread.run() should be done.");

    myThread.start(); // <-- causes java.lang.IllegalThreadStateException

  } // main

} // class

I know that it is not possible to restart a used Java Thread object, but I don't find an explanation why this is not allowed; even if it is guaranteed that the thread has finished (see example code below).

My guestimation is that Threads might be directly tied (for efficiency or other constrains) to actual native resources that might be re-startable in some operating systems, but not in others. If the designers of the Java language had allowed Threads to be re-started, they might limit the number of operating systems on which the JVM can run.

Come to think of it, I cannot think of a OS that allows a thread or process to be restarted once it is finished or terminated. When a process completes, it dies. You want another one, you restart it. You never resurrect it.

Beyond the issues of efficiency and limitations imposed by the underlying OS, there is the issue of analysis and reasoning. You can reason about concurrency when things are either immutable or have a discrete, finite life-time. Just like state machines, they have to have a terminal state. Is it started, waiting, finished? Things like that cannot be easily reasoned about if you allow Threads to resurrect.

You also have to consider the implications of resurrecting a thread. Recreate its stack, its state, is is safe to resurrect? Can you resurrect a thread that ended abnormally? Etc.

Too hairy, too complex. All that for insignificant gains. Better to keep Threads as non-resurrectable resources.

I'd pose the question the other way round - why should a Thread object be restartable?

It's arguably much easier to reason about (and probably implement) a Thread that simply executes its given task exactly once and is then permanently finished. To restart threads would require a more complex view on what state a program was in at a given time.

So unless you can come up with a specific reason why restarting a given Thread is a better option than just creating a new one with the same Runnable, I'd posit that the design decision is for the better.

(This is broadly similar to an argument about mutable vs final variables - I find the final "variables" much easier to reason about and would much rather create multiple new constant variables rather than reuse existing ones.)

Because they didn't design it that way. From a clarity standpoint, that makes sense to me. A Thread represents a thread of execution, not a task. When that thread of execution has completed, it has done its work and it just muddies things were it to start at the top again.

A Runnable on the other hand represents a task, and can be submitted to many Threads as many times as you like.

Why don't you want to create a new Thread? If you're concerned about the overhead of creating your MyThread object, make it a Runnable and run it with a new Thread(myThread).start();

Java Threads follow a lifecycle based on the State Diagram below. Once the thread is in a final state, it is over. That is simply the design.

You can kind of get around this, either by using a java.util.concurrent.ThreadPoolExecutor, or manually by having a thread that calls Runnable.run() on each Runnable that it is given, not actually exiting when it is finished.

It's not exactly what you were asking about, but if you are worried about thread construction time then it can help solve that problem. Here's some example code for the manual method:

public class ReusableThread extends Thread {
    private Queue<Runnable> runnables = new LinkedList<Runnable>();
    private boolean running;

    public void run() {
        running = true;
        while (running) {
            Runnable r;
            try {
                synchronized (runnables) {
                    while (runnables.isEmpty()) runnables.wait();
                    r = runnables.poll();
                }
            }
            catch (InterruptedException ie) {
                // Ignore it
            }

            if (r != null) {
                r.run();
            }
        }
    }

    public void stopProcessing() {
        running = false;
        synchronized (runnables) {
            runnables.notify();
        }
    }

    public void addTask(Runnable r) {
        synchronized (runnables) {
            runnables.add(r);
            runnables.notify();
        }
    }
}

Obviously, this is just an example. It would need to have better error-handling code, and perhaps more tuning available.

If you are concerned with the overhead of creating a new Thread object then you can use executors.

import java.util.concurrent.Executor;
import java.util.concurrent.Executors;
public class Testes {
    public static void main(String[] args) {
        Executor executor = Executors.newSingleThreadExecutor();
        executor.execute(new Testes.A());
        executor.execute(new Testes.A());
        executor.execute(new Testes.A());
    }   
    public static class A implements Runnable{      
        public void run(){          
            System.out.println(Thread.currentThread().getId());
        }
    }
}

Running this you will see that the same thread is used for all Runnable objects.

A Thread is not a thread. A thread is an execution of your code. A Thread is an object that your program uses to create and, manage the life-cycle of, a thread.

Suppose you like playing tennis. Suppose you and your friend play a really awesome set. How would your friend react if you said, "That was incredible, let's play it again." Your friend might think you were nuts. It doesn't make sense even to talk about playing the same set again. If you play again you're playing a different set.

A thread is an execution of your code. It doesn't make sense to even talk about "re-using" a thread of execution for same reason that it makes no sense to talk about re-playing the same set in tennis. Even if another execution of your code executes all the same statements in the same order, it's still a different execution.

Andrzej Doyle's asked, "Why would you want to re-use a Thread?" Why indeed? If a Thread object represents a thread of execution---an ephemeral thing that you can't even talk about re-using---then why would you want or expect the Thread object to be re-useable?

i've been searching the same solution which you seem to be looking for, and i resolved it in this way. if you occur mousePressed Event you can terminate it also reuse it, but it need to be initialized, as you can see below.

class MouseHandler extends MouseAdapter{
    public void mousePressed(MouseEvent e) {            
        if(th.isAlive()){
            th.interrupt();
            th = new Thread();
        }
        else{
            th.start();
        }
    }

}