public class WaitTest {
static class ThreadA extends Thread {
public ThreadA(String name){
super(name);
}
@Override
public void run() {
synchronized (this){
System.out.println(Thread.currentThread().getName()+" call notify()");
//notify();//notify之后 要等到这个代码块结束之后才会把锁让出去,当然如果在notify之后又有wait,那就会主动把锁让出去
try {
System.out.println(Thread.currentThread().getName()+" wait");
//wait();
//Thread.sleep(10000);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName()+" after notify");
}
}
}
public static void main(String[] args) throws InterruptedException {
ThreadA t1 =new ThreadA("t1");
synchronized (t1){
System.out.println(Thread.currentThread().getName()+" start t1");
t1.start();
System.out.println(Thread.currentThread().getName()+" wait");
t1.wait();//
//System.out.println(Thread.currentThread().getName()+" notify");
// t1.notify();
System.out.println(t1.getName());
System.out.println(Thread.currentThread().getName()+" continue");
//t1.notify();
}
}
}
Logiquement parlant, t1.wait() devrait bloquer le thread principal, et il n'y a aucun autre endroit pour le notifier
Et après avoir supprimé t1.start(), il sera bloqué
Qu'est-ce que cela signifie ? Optimisation du compilateur ? Ou si le moniteur n'est pas utilisé dans le bloc de code synchronisé, la notification active prendra fin ? ?
Ce n'est pas de l'optimisation. En fait, c'est lié à l'exécution des threads. Dans la doc java,
public final synchronized void join(long millis)
Le commentaire de cette méthode comporte une phrase écrite dessusVoir en gras, c'est en fait le notifyAll appelé après la fin du fil qui provoque l'attente du réveil. Cela n’est dû à aucune optimisation de machine virtuelle. J'espère que cela pourra répondre à votre confusion