Question on Java Thread, output consistent

In th开发者_如何学Pythone below code the answer is always Started 0 1 2 3 Complete. Im just wondering how it is possible.

If someone could help with the consistency of the output, it would be nice

public class TestOne extends Thread {

/**
 * @param args
 */
public static void main(String[] args)throws Exception {
    // TODO Auto-generated method stub

    Thread t = new Thread(new TestOne());
    t.start();
    System.out.println("started");
    t.join();
    System.out.println("Complete");




}

public void run(){
    for(int i=0;i<4;i++){
        System.out.println(i);
    }
}

---

Most likely you're getting the same results because, most of the time, the main thread starts a new thread then, before that new thread has a chance to print anything, the main thread prints its started message. The join in the main thread then forces it to wait until the other thread has finished, then it prints Complete.

You have a race condition here. The instant you start the second thread, it's indeterministic as to which order the lines will be output (other than the complete line which is made deterministic by virtue of the wait call, as previously mentioned).

But a race condition doesn't guarantee that you'll get different results on multiple runs, only that it is possible. You still shouldn't rely on that behaviour, of course.

For example, the following code:

public class TestOne extends Thread {
    public static void main (String[] args) throws Exception {
        Thread t = new Thread (new TestOne());
        t.start();

        Thread.sleep (1000);  // <- Added this.

        System.out.println ("Started");
        t.join();
        System.out.println ("Complete");
    }

    public void run() {
        for (int i = 0; i < 4; i++) {
            System.out.println (i);
        }
    }
}

will output:

0
1
2
3
Started
Complete

Although, even then, the order is not guaranteed as it may take more than a second for the thread to "warm up" - sleep is rarely a good solution to race conditions. I've just used it here for illustrative purposes.

---

When you say Thread t = new Thread(); nothing special happens because you are not creating a "Thread" per se. It is just an object that has the "characteristics" to become a thread of execution. For the object to be a "Thread" you have to call t.start(); and this is where the magic lies.

When you say t.start() the JVM creates a new stack for the newly created thread to run. It associates that stack to the thread object in question. And then makes it available for scheduling. Basically this means that it queues the thread in the JVM scheduler and in the next time slice it is also available for execution. The JVM actually does a lot more than this, my answer is just oversimplified for your example.

Invariably, meanwhile all these thread + stack creation, your main thread has the opportunity to move to its next instruction which in your case is System.out.println("started");.

Theoretically, what you say is true, "Started" could come anywhere in between 0, 1, 2, 3. However in reality, since your t.start() is an "expensive" method, it takes some time to complete, during which the main thread generally gets the chance to execute its next instruction.

If you want to know the details of t.start(); look into the Java source code.

---

Clearly, you are seeing a consistent result (and this particular result) because on your machine the call to the child thread's run method is consistently happening after the println in the main thread.

Why is it consistent?

Well, simply because your platform's native thread library is behaving in a consistent fashion!

Typical modern Java virtual machine implementations use the host operating system's native thread support to implement Java threads, and to perform Java thread scheduling. On your machine, the native thread implementation appears to be consistently allowing the current thread to return from the Thread.start() call immediately and keep executing.

However, it is not guaranteed that this will always happen. For instance, if the machine was heavily loaded and the main thread had just about exhausted its current timeslice, it could get descheduled during or immediately after the start call, allowing the new thread to run first.

Furthermore, on another platform the normal scheduler behaviour could be different. The scheduler could consistently cause the current thread to deschedule and let the new one go first. Or it could happen "randomly".

The JVM and Java library specs deliberately do not specify which thread "goes first" precisely to allow for differences in the thread implementation ... and variation due to differences in hardware, system load and so on.

---

Bottom line - the apparent consistency you are seeing is an "artifact", and you shouldn't rely on it, especially if you want your application to work on a wide range of JVMs.

---

Simply put, the scheduling of the started thread with respect to the main thread is JVM implementation dependent. But that being said, most implementations, if not all, will leave the starting thread running to the completion of its timeslice, until it blocks on something, or until it is preempted by a higher priority thread (if preemptive scheduling is being used, also JVM implementation dependent).

The Java spec just does not say very much which is very specific about threading, deliberately to grant JVM writers the most scope for their implementation.

---

t.join() means "block until thread t has finished", which explains the "Completed" being last.

EDIT: In answer to question re "Started"...

The call to Thread.start() means "please schedule this thread to run", and it will start when java feels like starting it. The chance of that happening between t.start() the println() is platform dependant, but small on systems I've used (thx to @ Stephen C for platform info).

This code however outputs 0, Started, 1, 2, 3, Completed:

    Thread t = new Thread(new TestOne());
    t.start();
    try
    {
        Thread.sleep(100); // Added sleep between t.start() and println()
    }
    catch (InterruptedException e)
    {
        e.printStackTrace();
    }
    System.out.println("Started");
    t.join();
    System.out.println("Complete");

---

When you start a thread it takes time (nothing comes for free or occurs instantly) The thread which is already running will almost always be quicker to print out than a thread which has just started.

If you really want to the order to be different every time you can use run() instead of start() This works because you only have one thread.