参考文章：[高并发Java 二] 多线程基础 线程的几种状态转换
1.线程概念
线程是进程内的执行单元。
使用线程的原因是，进程的切换是非常重量级的操作，非常消耗资源。如果使用多进程，那么并发数相对来说不会很高。而线程是更细小的调度单元，更加轻量级，所以线程会较为广泛的用于并发设计。
在Java当中线程的概念和操作系统级别线程的概念是类似的。事实上，Jvm将会把Java中的线程映射到操作系统的线程区。
2.线程的基本操作
2.1 新建线程
Thread thread = new Thread();
thread.start();
需要注意的是
Thread thread = new Thread();
thread.run();
直接调用run方法是无法开启一个新线程的。
start方法其实是在一个新的操作系统线程上面去调用run方法。换句话说，直接调用run方法而不是调用start方法的话，它并不会开启新的线程，而是在调用run的当前的线程当中执行你的操作。
Thread thread = new Thread("t1")
{
@Override
public void run()
{
// TODO Auto-generated method stub
System.out.println(Thread.currentThread().getName());
}
};
thread.start();
如果调用start，则输出是t1
Thread thread = new Thread("t1")
{
@Override
public void run()
{
// TODO Auto-generated method stub
System.out.println(Thread.currentThread().getName());
}
};
thread.run();
如果是run,则输出main。（直接调用run其实就是一个普通的函数调用而已，并没有达到多线程的作用）
run方法的实现有两种方式
第一种方式，直接覆盖run方法，就如刚刚代码中所示，最方便的用一个匿名类就可以实现。
Thread thread = new Thread("t1")
{
@Override
public void run()
{
// TODO Auto-generated method stub
System.out.println(Thread.currentThread().getName());
}
};
第二种方式
Thread t1=new Thread(new CreateThread3());
CreateThread3()需要实现Runnable接口。
2.2 终止线程
- Thread.stop() 不推荐使用。它会释放所有monitor
在源码中已经明确说明stop方法被Deprecated，在Javadoc中也说明了原因。
原因在于stop方法太过"暴力"了，无论线程执行到哪里，它将会立即停止掉线程。
当写线程得到锁以后开始写入数据，写完id = 1，在准备将name = 1时被stop,释放锁。读线程获得锁进行读操作，读到的id为1，而name还是0，导致了数据不一致。最重要的是这种错误不会抛出异常，将很难被发现。
2.3 线程中断
线程中断有3种方法
public void Thread.interrupt() // 中断线程
public boolean Thread.isInterrupted() // 判断是否被中断
public static boolean Thread.interrupted() // 判断是否被中断，并清除当前中断状态
什么是线程中断呢？
如果不了解Java的中断机制，这样的一种解释极容易造成误解，认为调用了线程的interrupt方法就一定会中断线程。
其实，Java的中断是一种协作机制。也就是说调用线程对象的interrupt方法并不一定就中断了正在运行的线程，它只是要求线程自己在合适的时机中断自己。每个线程都有一个boolean的中断状态（不一定就是对象的属性，事实上，该状态也确实不是Thread的字段），interrupt方法仅仅只是将该状态置为true。对于非阻塞中的线程, 只是改变了中断状态, 即Thread.isInterrupted()将返回true，并不会使程序停止;
public void run(){//线程t1
while(true){
Thread.yield();
}
}
t1.interrupt();
这样使线程t1中断，是不会有效果的，只是更改了中断状态位。
如果希望非常优雅地终止这个线程，就该这样做
public void run(){
while(true)
{
if(Thread.currentThread().isInterrupted())
{
System.out.println("Interruted!");
break;
}
Thread.yield();
}
}
使用中断，就对数据一致性有了一定的保证。
对于可取消的阻塞状态中的线程, 比如等待在这些函数上的线程, Thread.sleep(), Object.wait(), Thread.join(), 这个线程收到中断信号后, 会抛出InterruptedException, 同时会把中断状态置回为false.
对于取消阻塞状态中的线程，可以这样书写代码：
public void run(){
while(true){
if(Thread.currentThread().isInterrupted()){
System.out.println("Interruted!");
break;
}
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
System.out.println("Interruted When Sleep");
//设置中断状态，抛出异常后会清除中断标记位
Thread.currentThread().interrupt();
}
Thread.yield();
}
}
2.5 线程挂起
挂起（suspend）和继续执行（resume）线程
- suspend()不会释放锁
- 如果加锁发生在resume()之前 ，则死锁发生
这两个方法都是Deprecated方法，不推荐使用。
原因在于，suspend不释放锁，因此没有线程可以访问被它锁住的临界区资源，直到被其他线程resume。因为无法控制线程运行的先后顺序，如果其他线程的resume方法先被运行，那则后运行的suspend，将一直占有这把锁，造成死锁发生。
用以下代码来模拟这个场景
package test;
public class Test
{
static Object u = new Object();
static TestSuspendThread t1 = new TestSuspendThread("t1");
static TestSuspendThread t2 = new TestSuspendThread("t2");
public static class TestSuspendThread extends Thread
{
public TestSuspendThread(String name)
{
setName(name);
}
@Override
public void run()
{
synchronized (u)
{
System.out.println("in " + getName());
Thread.currentThread().suspend();
}
}
}
public static void main(String[] args) throws InterruptedException
{
t1.start();
Thread.sleep(100);
t2.start();
t1.resume();
t2.resume();
t1.join();
t2.join();
}
}
让t1,t2同时争夺一把锁，争夺到的线程suspend，然后再resume，按理来说，应该某个线程争夺后被resume释放了锁，然后另一个线程争夺掉锁，再被resume。
结果输出是：
in t1
in t2
说明两个线程都争夺到了锁，但是控制台的红灯还是亮着的，说明t1,t2一定有线程没有执行完。我们dump出堆来看看
发现t2一直被suspend。这样就造成了死锁。
2.6 谦让(yeild)
yeild是个native静态方法，这个方法是想把自己占有的cpu时间释放掉，然后和其他线程一起竞争(注意yeild的线程还是有可能争夺到cpu，注意与sleep区别)。在javadoc中也说明了，yeild是个基本不会用到的方法，一般在debug和test中使用。
2.7 等待结束( join)
join方法的意思是等待其他线程结束，就如suspend那节的代码，想让主线程等待t1,t2结束以后再结束。没有结束的话，主线程就一直阻塞在那里。
package test;
public class Test
{
public volatile static int i = 0;
public static class AddThread extends Thread
{
@Override
public void run()
{
for (i = 0; i < 10000000; i++)
;
}
}
public static void main(String[] args) throws InterruptedException
{
AddThread at = new AddThread();
at.start();
at.join();
System.out.println(i);
}
}
如果把上述代码的at.join去掉，则主线程会直接运行结束，i的值会很小。如果有join,打印出的i的值一定是10000000。
那么join是怎么实现的呢？
join的本质
while(isAlive())
{
wait(0);
}
join()方法也可以传递一个时间，意为有限期地等待，超过了这个时间就自动唤醒。
这样就有一个问题，谁来notify这个线程呢，在thread类中没有地方调用了notify？
在javadoc中，找到了相关解释。当一个线程运行完成终止后，将会调用notifyAll方法去唤醒等待在当前线程实例上的所有线程,这个操作是jvm自己完成的。
所以javadoc中还给了我们一个建议，不要使用wait和notify/notifyall在线程实例上。因为jvm会自己调用，有可能与你调用期望的结果不同。
3. 线程状态转换图
线程在一定条件下，状态会发生变化。线程一共有以下几种状态**：**
1. 新建状态(New)：新创建了一个线程对象。
2. 就绪状态(Runnable)：线程对象创建后，其他线程调用了该对象的start()方法。该状态的线程位于“可运行线程池”中，变得可运行，只等待获取CPU的使用权。即在就绪状态的进程除CPU之外，其它的运行所需资源都已全部获得。
**3. 运行状态(Running)：**就绪状态的线程获取了CPU，执行程序代码。
**4. 阻塞状态(Blocked)：**阻塞状态是线程因为某种原因放弃CPU使用权，暂时停止运行。直到线程进入就绪状态，才有机会转到运行状态。
阻塞的情况分三种：
(1)等待阻塞：运行的线程执行wait()方法，该线程会释放占用的所有资源，JVM会把该线程放入“**等待池”**中。进入这个状 态后，是不能自动唤醒的，必须依靠其他线程调用notify()或notifyAll()方法才能被唤醒，
(2)同步阻塞：运行的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则JVM会把该线程放入**“锁池”**中。
(3)其他阻塞：运行的线程执行sleep()或join()方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。
**5、死亡状态(Dead)：**线程执行完了或者因异常退出了run()方法，该线程结束生命周期。
线程变化的状态转换图如下：
**注：**拿到对象的锁标记，即为获得了对该对象(临界区)的使用权限。即该线程获得了运行所需的资源，进入“就绪状态”，只需获得CPU，就可以运行。因为当调用wait()后，线程会释放掉它所占有的“锁标志”，所以线程只有在此获取资源才能进入就绪状态。
具体解释：
1、 线程的实现有两种方式，一是继承Thread类，二是实现Runnable接口，当new出一个线程时，其实线程并没有工作它只是生成了一个实体，当你调用这个实例的start方法时，线程才真正地被启动，并且进入Runnable状态；
2、 当该对象调用了start()方法，就进入就绪状态；
3、 进入就绪后，当该对象被操作系统选中，获得CPU时间片就会进入运行状态；
4、 进入运行状态后情况就比较复杂了；
4、 1run()方法或main()方法结束后，线程就进入终止状态；
4、 2当线程调用了自身的sleep()方法或其他线程的join()方法，进程让出CPU，然后就会进入阻塞状态（该状态既停止当前线程，但并不释放所占有的资源****即调用sleep()函数后，线程不会释放它的“锁标志”）当sleep()结束或join()结束后，该线程进入可运行状态，继续等待OS分配CPU时间片**典型地，**sleep()被用在等待某个资源就绪的情形：测试发现条件不满足后，让线程阻塞一段时间后重新测试，直到条件满足为止；
4、 3线程调用了yield()方法，意思是放弃当前获得的CPU时间片，回到就绪状态，这时与其他进程处于同等竞争状态，OS有可能会接着又让这个进程进入运行状态；调用yield()的效果等价于调度程序认为该线程已执行了足够的时间片从而需要转到另一个线程yield()只是使当前线程重新回到可执行状态，所以执行yield()的线程有可能在进入到可执行状态后马上又被执行；
4、 4当线程刚进入可运行状态（注意，还没运行），发现将要调用的资源被synchroniza（同步），获取不到锁标记，将会立即进入锁池状态，等待获取锁标记（这时的锁池里也许已经有了其他线程在等待获取锁标记，这时它们处于队列状态，既先到先得），一旦线程获得锁标记后，就转入就绪状态，等待OS分配CPU时间片；
4、 5.suspend()和resume()方法：两个方法配套使用，suspend()使得线程进入阻塞状态，并且不会自动恢复，必须其对应的resume()被调用，才能使得线程重新进入可执行状态典型地，****suspend()和resume()被用在等待另一个线程产生的结果的情形：测试发现结果还没有产生后，让线程阻塞，另一个线程产生了结果后，调用resume()使其恢复；
4、 6.wait()和notify()方法：当线程调用wait()方法后会进入等待队列（进入这个状态会释放所占有的所有资源，与阻塞状态不同），进入这个状态后，是不能自动唤醒的，必须依靠其他线程调用notify()或notifyAll()方法才能被唤醒（由于notify()只是唤醒一个线程，但我们由不能确定具体唤醒的是哪一个线程，也许我们需要唤醒的线程不能够被唤醒，因此在实际使用时，一般都用notifyAll()方法，唤醒有所线程），线程被唤醒后会进入锁池，等待获取锁标记；
wait() 使得线程进入阻塞状态，它有两种形式：
一种允许指定以毫秒为单位的一段时间作为参数；另一种没有参数。前者当对应的 notify()被调用或者超出指定时间时线程重新进入可执行状态即就绪状态，后者则必须对应的 notify()被调用。当调用wait()后，线程会释放掉它所占有的“锁标志”，从而使线程所在对象中的其它synchronized数据可被别的线程使用。waite()和notify()因为会对对象的“锁标志”进行操作，所以它们必须在synchronized函数或synchronizedblock中进行调用。如果在non-synchronized函数或non-synchronizedblock中进行调用，虽然能编译通过，但在运行时会发生IllegalMonitorStateException的异常。
**注意区别：**初看起来wait() 和 notify() 方法与suspend()和 resume() 方法对没有什么分别，但是事实上它们是截然不同的。区别的核心在于，前面叙述的suspend()及其它所有方法在线程阻塞时都不会释放占用的锁（如果占用了的话），而wait() 和 notify() 这一对方法则相反。
上述的核心区别导致了一系列的细节上的区别
首先，前面叙述的所有方法都隶属于 Thread类，但是wait() 和 notify() 方法这一对却直接隶属于 Object 类，也就是说，所有对象都拥有这一对方法。初看起来这十分不可思议，但是实际上却是很自然的，因为这一对方法阻塞时要释放占用的锁，而锁是任何对象都具有的，调用任意对象的 wait() 方法导致线程阻塞，并且该对象上的锁被释放。而调用任意对象的notify()方法则导致因调用该对象的 wait()方法而阻塞的线程中随机选择的一个解除阻塞（但要等到获得锁后才真正可执行）。
其次，前面叙述的所有方法都可在任何位置调用，**但是wait() 和 notify() 方法这一对方法却必须在 synchronized 方法或块中调用，**理由也很简单，只有在synchronized方法或块中当前线程才占有锁，才有锁可以释放。同样的道理，调用这一对方法的对象上的锁必须为当前线程所拥有，这样才有锁可以释放。因此，这一对方法调用必须放置在这样的 synchronized方法或块中，该方法或块的上锁对象就是调用这一对方法的对象。若不满足这一条件，则程序虽然仍能编译，但在运行时会出现IllegalMonitorStateException异常。
wait() 和 notify()方法的上述特性决定了它们经常和synchronized方法或块一起使用，将它们和操作系统的进程间通信机制作一个比较就会发现它们的相似性：synchronized方法或块提供了类似于操作系统原语的功能，它们的执行不会受到多线程机制的干扰，而这一对方法则相当于 block和wake up 原语（这一对方法均声明为 synchronized）。它们的结合使得我们可以实现操作系统上一系列精妙的进程间通信的算法（如信号量算法），并用于解决各种复杂的线程间通信问题。
关于 wait() 和 notify() 方法最后再说明两点：
第一：调用notify() 方法导致解除阻塞的线程是从因调用该对象的 wait()方法而阻塞的线程中随机选取的，我们无法预料哪一个线程将会被选择，所以编程时要特别小心，避免因这种不确定性而产生问题。
第二：除了notify()，还有一个方法 notifyAll()也可起到类似作用，唯一的区别在于，调用 notifyAll()方法将把因调用该对象的 wait()方法而阻塞的所有线程一次性全部解除阻塞。当然，只有获得锁的那一个线程才能进入可执行状态。
谈到阻塞，就不能不谈一谈死锁，略一分析就能发现，suspend()方法和不指定超时期限的wait()方法的调用都可能产生死锁。遗憾的是，Java并不在语言级别上支持死锁的避免，我们在编程中必须小心地避免死锁。