一:初始状态
实现Runnable接口和继承Thread可以得到一个线程类，new一个实例出来，线程就进入了初始状态
二:可运行状态
- 可运行状态只是说你资格运行，调度程序没有挑选到你，你就永远是可运行状态。
- 调用线程的start()方法，此线程进入可运行状态。
- 当前线程sleep()方法结束，其他线程join()结束，等待用户输入完毕，某个线程拿到对象锁，这些线程也将进入可运行状态。
- 当前线程时间片用完了，调用当前线程的yield()方法，当前线程进入可运行状态。
- 锁池里的线程拿到对象锁后，进入可运行状态。
三:运行状态
线程调度程序从可运行池中选择一个线程作为当前线程时线程所处的状态。这也是线程进入运行状态的唯一一种方式。
四:死亡状态
- 当线程的run()方法完成时，或者主线程的main()方法完成时，我们就认为它死去。这个线程对象也许是活的，但是，它已经不是一个单独执行的线程。线程一旦死亡，就不能复生。
- 在一个死去的线程上调用start()方法，会抛出java.lang.IllegalThreadStateException异常。
五:阻塞状态
- 当前线程T调用Thread.sleep()方法，当前线程进入阻塞状态。
- 运行在当前线程里的其它线程t2调用join()方法，当前线程进入阻塞状态。
- 等待用户输入的时候，当前线程进入阻塞状态。
六:等待队列(本是Object里的方法，但影响了线程)
- 调用obj的wait(), notify()方法前，必须获得obj锁，也就是必须写在synchronized(obj) 代码段内（后面会说明）。
-
与等待队列相关的步骤和图
线程1获取对象A的锁，正在使用对象A。
线程1调用对象A的wait()方法。
线程1释放对象A的锁，并马上进入等待队列。
锁池里面的对象争抢对象A的锁。
线程5获得对象A的锁，进入synchronized块，使用对象A。
线程5调用对象A的notifyAll()方法，唤醒所有线程，所有线程进入锁池。||||| 线程5调用对象A的notify()方法，唤醒一个线程，不知道会唤醒谁，被唤醒的那个线程进入锁池。
notifyAll()方法所在synchronized结束，线程5释放对象A的锁。
锁池里面的线程争抢对象锁，但线程1什么时候能抢到就不知道了。||||| 原本锁池+第6步被唤醒的线程一起争抢对象锁。
image.png
七:锁池状态
- 当前线程想调用对象A的同步方法时，发现对象A的锁被别的线程占有，此时当前线程进入锁池状态。简言之，锁池里面放的都是想争夺对象锁的线程。
- 当一个线程1被另外一个线程2唤醒时，1线程进入锁池状态，去争夺对象锁。
- 锁池是在同步的环境下才有的概念，一个对象对应一个锁池。
八:几个方法的比较
- Thread.sleep(long millis)，一定是当前线程调用此方法，当前线程进入阻塞，但不释放对象锁，millis后线程自动苏醒进入可运行状态。作用：给其它线程执行机会的最佳方式。
- Thread.yield()，一定是当前线程调用此方法，当前线程放弃获取的cpu时间片，由运行状态变会可运行状态，让OS再次选择线程。作用：让相同优先级的线程轮流执行，但并不保证一定会轮流执行。实际中无法保证yield()达到让步目的，因为让步的线程还有可能被线程调度程序再次选中。Thread.yield()不会导致阻塞。
- t.join()/t.join(long millis)，当前线程里调用其它线程1的join方法，当前线程阻塞，但不释放对象锁，直到线程1执行完毕或者millis时间到，当前线程进入可运行状态。
- obj.wait()，当前线程调用对象的wait()方法，当前线程释放对象锁，进入等待队列。依靠notify()/notifyAll()唤醒或者wait(long timeout)timeout时间到自动唤醒。
- obj.notify()唤醒在此对象监视器上等待的单个线程，选择是任意性的。notifyAll()唤醒在此对象监视器上等待的所有线程。
为什么wait()方法要放在同步块?
事情得从一个多线程编程里面臭名昭著的问题"Lost wake-up problem"说起。
这个问题并不是说只在Java语言中会出现，而是会在所有的多线程环境下出现。
假如有两个线程，一个消费者线程，一个生产者线程。生产者线程的任务可以简化成将count加一，而后唤醒消费者；消费者则是将count减一，而后在减到0的时候陷入睡眠：
生产者伪代码：
count+1;
notify();
消费者伪代码：
while(count<=0){
wait();
}
count--;
熟悉多线程的朋友一眼就能够看出来，这里面有问题。什么问题呢？
生产者是两个步骤：
count+1;
notify();
消费者也是两个步骤：
检查count值；
睡眠或者减一；
万一这些步骤混杂在一起呢？比如说，初始的时候count等于0，这个时候消费者检查count的值，发现count小于等于0的条件成立；就在这个时候，发生了上下文切换，生产者进来了，噼噼啪啪一顿操作，把两个步骤都执行完了，也就是发出了通知，准备唤醒一个线程。这个时候消费者刚决定睡觉，还没睡呢，所以这个通知就会被丢掉。紧接着，消费者就睡过去了……
这就是所谓的lost wake up问题。
那么怎么解决这个问题呢？
现在我们应该就能够看到，问题的根源在于，消费者在检查count到调用wait()之间，count就可能被改掉了。
这就是一种很常见的竞态条件。
很自然的想法是，让消费者和生产者竞争一把锁，竞争到了的，才能够修改count的值。
于是生产者的代码是:
tryLock();
count+1;
notify();
releaseLock();
消费者的代码是:
tryLock();
while(count<=0){
wait();
}
count--;
releaseLock();
注意的是，我这里将两者的两个操作都放进去了同步块中。
小结
所以，我们可以总结到，为了避免出现这种lost wake up问题，在这种模型之下，总应该将我们的代码放进去的同步块中。
Java强制我们的wait()/notify()调用必须要在一个同步块中，就是不想让我们在不经意间出现这种lost wake up问题。
不仅仅是这两个方法，包括java.util.concurrent.locks.Condition的await()/signal()也必须要在同步块中。
准确的来说，即便是我们自己在实现自己的锁机制的时候，也应该要确保类似于wait()和notify()这种调用，要在同步块内，防止使用者出现lost wake up问题。
