JVM如何通知被`join（）`阻塞的线程？

Question

The join() method waits for a thread to die. it use wait to do this.

if (millis == 0) {
            while (isAlive()) {
                wait(0);
            }
        }

So when the thread exits, how can it notify threads in wait set.

1. I try to find code in JDK source code, but failed. Can anyone show me the relevant code snippets?

2. when a thread in wait set, it may check isAlive() so many times for its timeslice, is this a waste?

3. if isAlive() is false, it just return, that thread is already in wait set. Is the while(isAlive()) necessary?

Answer 1

1) I try to find code in JDK source code, but failed. Can anyone show me the relevant code snippets?

The pathname for the Thread class in the OpenJDK jdk8u source tree is jdk/src/share/classes/java/lang/Thread.java . The code for join() is below.

The native code where the notifyAll occurs is in Thread::exit in hotspot/src/share/vm/runtime/thread.cpp .

For other releases the paths may be different. (The find command is your friend.)

2) When a thread in wait set, it may check isAlive() so many times for its timeslice, is this a waste?

That is incorrect.

• The "wait set" argument is incorrect. If the current thread can call isAlive() it is not in any wait set. It will only be in the "wait set" for the target Thread when it is in a wait(...) call. It is removed from the "wait set" when the current thread is notified.

  To reiterate, a thread t1 is in the "wait set" of another thread t2 when t1 is executing t2.wait(...) .

• A wait(...) call with a zero timeout means "wait until notified without a timeout ". Therefore, this is not a busy loop.

• The loop will usually go around zero or one time only. (But see the next part of my answer.)

3) If isAlive() is false, it just return, that thread is already in wait set. Is the while(isAlive()) necessary?

• Your "wait set" logic is incorrect (as above).

• The loop is necessary. It is possible for any application code that has a reference to the target Thread object to call Object.notify() on that it. That causes the wait(0) to return. But since this "wake up" is spurious, it is necessary to check that the target Thread has actually ended (by calling isAlive() ) and maybe waitinf again.

  This could happen repeatedly ... if application code is doing something silly ... but it shouldn't.

---

public final synchronized void join(long millis)
throws InterruptedException {
    long base = System.currentTimeMillis();
    long now = 0;

    if (millis < 0) {
        throw new IllegalArgumentException("timeout value is negative");
    }

    if (millis == 0) {
        while (isAlive()) {
            wait(0);
        }
    } else {
        while (isAlive()) {
            long delay = millis - now;
            if (delay <= 0) {
                break;
            }
            wait(delay);
            now = System.currentTimeMillis() - base;
        }
    }
}

Most of the implementation of Thread is in native code. That is where the notifyAll that wakes up the joining threads is made.

Answer 2

To answer your questions:

1. wait() is a native method and uses System code. There is no Java code for that.

2. wait() is not a means to wait for a Thread but to synchronize on a certain object. Wait() is the wrong method to pause a thread, you need to use sleep().

3. The counterpart of wait() is notify() or notifyAll(). This will wake up Threads which wait for the calling object. Wait() and notify are part of the Object.class and need a synchronization on the object.

A Thread is alive as long as its run method is executing. If you join a thread the calling thread will automatically halt. If you want to let a thread wait then use Thread.sleep.

Thread t1 = new Thread(){
  public void run(){
     try {
        sleep(5000);
     } catch (InterruptedException e){
       e.printStackTrace();
     }
     System.out.println("I'm done");
  }
}

t1.start();
//The calling thread will wait here for 5 sec.
t1.join();