Java 线程状态
定义都在Thread.State里，通过线程对象的getState()可以获取得到。
NEW
新创建的还没有启动的线程所处的状态。
RUNNABLE
在JVM中正在执行的线程的状态。也不一定是正在执行代码，也可能是在处于一个等待调度以获取CPU的状态，不过一般这个调度时间非常短暂，对外界来说线程一直是在连续执行的。这个和操作系统里进程调度相关情况一致。yield可以让出线程当前占用的CPU但是线程还是处于RUNNABLE状态。
BLOCKED
等待获取内部锁时所处的状态。这里的等待和RUNNABLE状态中可能发生的等待就不一样了，它可能会非常的长，在产生死锁的代码上，线程会一直在等待。如下会产生死锁的代码
import java.util.concurrent.*;/** * Created by hegaofeng on 6/29/15. */public class DeadLockThreads { public static void main(String args[]) throws InterruptedException, ExecutionException { final Trouble trouble = new Trouble(); trouble.addOne(); System.out.println(trouble.getCount()); }}class Trouble { private ExecutorService pool = Executors.newCachedThreadPool(); private int cnt = 0; public synchronized void addOne() throws InterruptedException, ExecutionException { Future future = pool.submit(new Callable() { @Override public Object call() throws Exception { System.out.println("try to preparing"); prepare(); System.out.println("prepared."); cnt++; return "done"; } }); System.out.println(future.get()); } private synchronized void prepare() { System.out.println("preparing"); } public synchronized int getCount() { return cnt; }} 注意synchronized对应的内部锁本身是可重入的。也就是说一个线程在一个synchronized修饰的方法里调用其他本类内也被synchronized修饰的方法并不会引起死锁，比如递归。但是两个及多个不同的线程在一个对象上执行被synchronized修饰的方法就要格外小心，因为它们可能会产生相互依赖。在synchronized等待时线程就处于BLOCKED状态。
除了类似上面比较明显的使用方式会使得线程处于BLOCKED状态外，还有一种情况比较隐蔽，不过也是处于获取内部锁的时候。下面是一段典型的使用内置锁类进行条件等待的例子：
synchronized(SomeObject) { while (ConditionCheckNotMeet) { SomeObject.wait() } // modify state protected by SomeObject internal lock SomeObject.notifyAll();} 一个具体的例子：
import java.util.concurrent.*;/** * Created by hegaofeng on 6/29/15. */public class ConditionWait { public static void main(String[] args) throws InterruptedException { ScheduledExecutorService pool = Executors.newSingleThreadScheduledExecutor(); final SimpleBlockingQueue queue = new SimpleBlockingQueue(4); Runnable poper = new Runnable() { @Override public void run() { try { int pop = queue.pop(); System.out.println("poped : " + pop); } catch (InterruptedException e) { e.printStackTrace(); } } }; pool.scheduleAtFixedRate(poper, 1000, 500, TimeUnit.MILLISECONDS); for (int i=0; i<10000; i++) { queue.push(i); System.out.println("pushed: " + i); } }}class SimpleBlockingQueue { private int size = 0; private int cur = 0; private int[] storage; public SimpleBlockingQueue(int cap) { cap = cap > 0 ? cap : 0; storage = new int[cap]; } public void push(int val) throws InterruptedException { synchronized (storage) { while (size >= storage.length) { // 1. we hold the lock of storage storage.wait(); // 2. we lost the lock of storage when entering wait state // 3. when somebody invoke notify or notifyAll: // wait return when we retrieved the lock again } storage[cur] = val; cur = (cur + 1) % storage.length; size++; storage.notifyAll(); } } public int pop() throws InterruptedException { int val; synchronized (storage) { while (size <= 0) { storage.wait(); } int idx = ((cur - size) + storage.length) % storage.length; val = storage[idx]; size--; storage.notifyAll(); } return val; }} 这里实现了一个有界的阻塞队列，在push和pop函数中都使用到了storage.wait()这表示放弃在该对象上的内部锁，并在该对象上等待（进入WAITING状态）。
wait方法来自Object类，所以所有的java对象都可以这样来使用。但在调用wait方法前我们必须获得该对象上的锁。这个原因，需要联系synchronized-wait-notify的使用配合方式。从此调用这个方法的线程只会当其他线程在该对象上调用notify或者notifyAll时可能醒来(除开其他异常情况)。wait的返回并不是在其他线程调用notify后立刻进行的。它先会进行几个阶段的工作
- 重新竞争去获取对象的内部锁，此时状态从
WAITING变为为BLOCKED - 如果获得对象内部锁，切换线程状态到
RUNNABLE，wait返回 - 如果没有获取到内部锁则，切换线程状态重新回到
WAITING，继续等待。
以上是两种处于BLOCKED的线程状态的情况，都是和内置锁相关的。
WAITING
表示线程处于等待的状态，这种等待是没有时间限制的，即可一直等下去，不会超时。能够进入这个状态的调用有：
- Object.wait
- Thread.join
- LockSupport.park
Object.wait
这是Object的实例方法，在调用该方法前必须要获取对象的内置锁，否则会抛出java.lang.IllegalMonitorStateException异常。因为wait方法本身会去释放已经获得的对象内置锁（因为自己要进行睡眠了，拿着锁毫无用处，其他线程没有锁也不敢改由改对象内置锁保护的数据，于是自己也永远醒不了了），然而我们并没有获得锁。基于这个使用场景的要求，wait必然是在synchronized代码块或者方法中使用的。
Thread.join
观察JDK代码可以发现这是个synchronized修饰的方法，也是一个条件等待，内部也是调用了Object.wait
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; } } } 这个是有超时参数的版本，其中参数millis为0时即为无限等待的版本。
LockSupport.park
这个见的比较少，但是它会被许多的基础的并发同步类用到，如CountDownLatch，Semaphore，ReentrantLock等，也就说并发包里几乎所有同步工具类都使用了LockSupport类。这个类也不是直接被使用而是通过一个叫做AbstractQueuedSynchronizer的抽象类。
LockSupport.park可以使得线程进入WAITING状态，它不像Object.wait需要获得对象锁，它只是使线程进入睡眠状态WAITING，不进行额外的操作（如放入某个等待队列，这是使用LockSupport那些类需要做的）。park只能由要进入WAITING状态的线程自己执行。另外可以通过LockSupport.unpark唤醒指定进程。
注意unpack不能唤醒不是通过LockSupport进入睡眠的线程（如不能唤醒调用sleep而睡眠的线程），下面是一个例子：
import java.io.BufferedInputStream;import java.io.IOException;import java.util.concurrent.locks.LockSupport;/** * Created by hegaofeng on 6/29/15. */public class LockSupportTry { public static void main(String[] args) throws IOException { Thread other = new Thread(new Runnable() { @Override public void run() { while (true) { System.out.println("go sleeping"); LockSupport.park(); for (int i=0; i<10; i++) { System.out.println("."); } } } }); other.setDaemon(true); other.start(); BufferedInputStream is = new BufferedInputStream(System.in); int n = 0; while ((n = is.read()) > 0) { System.out.println("last state:" + other.getState()); LockSupport.unpark(other); } }}每按一次回车可以唤醒other线程。 另外直接贴一个LockSupport的javadoc中的例子：
class FIFOMutex { private final AtomicBoolean locked = new AtomicBoolean(false); private final Queue waiters = new ConcurrentLinkedQueue (); public void lock() { boolean wasInterrupted = false; Thread current = Thread.currentThread(); waiters.add(current); // Block while not first in queue or cannot acquire lock while (waiters.peek() != current || !locked.compareAndSet(false, true)) { LockSupport.park(this); if (Thread.interrupted()) // ignore interrupts while waiting wasInterrupted = true; } waiters.remove(); if (wasInterrupted) // reassert interrupt status on exit current.interrupt(); } public void unlock() { locked.set(false); LockSupport.unpark(waiters.peek()); } } TIMED_WAITING
此状态是有时间限制的睡眠即超过该时间后线程醒来。能够使得线程进入这个状态的和WAITING类似：
- Object.wait
- Thread.join
- LockSupport.parkUntil
- sleep
只不过相比WAITING中的那些多了一个超时时间值。使用方法一致。
TERMINATED
线程结束运行后即为此状态
状态转换
LockSupport.unpark做到的。 JStack 查看当前线程状态
先用jps命令查看当前运行的JVM，然后通过jstack jvm_pid来打印该JVM中所有线程的状态和栈。此时我们会发现WAITING一个状态中有些小的备注信息如：
- WAITING (parking)
- WAITING (on object monitor)
两者代表了两类进入WAITING状态的途径即Object.wait和LockSupport.park 。由于JDK并发包种的工具类大量使用了LockSupport，在一些阻塞的地方基本上都是第一类的情况。
一些问题
进行网络I/0时线程状态
下面是一个简单的echo服务（端口为2015），可以发现不管是accept阻塞时还是read阻塞时线程状态总是为RUNNABLE，凭感觉来讲应该是处于WAITING之类的才是。
import java.io.IOException;import java.io.InputStream;import java.io.OutputStream;import java.net.ServerSocket;import java.net.Socket;import java.util.concurrent.ExecutorService;import java.util.concurrent.Executors;/** * Created by hegaofeng on 6/29/15. */public class NetworkBlocking { public static void main(String[] args) throws IOException { ExecutorService pool = Executors.newCachedThreadPool(); ServerSocket serverSocket = new ServerSocket(2015); while (true) { System.out.println("Server listening " + serverSocket.getInetAddress()); Socket client = serverSocket.accept(); pool.submit(new ServiceRunnable(client)); } }}class ServiceRunnable implements Runnable { private final Socket clientSocket; public ServiceRunnable(Socket socket) { clientSocket = socket; } @Override public void run() { System.out.println("new echo service for client:" + clientSocket.getInetAddress()); try { InputStream is = clientSocket.getInputStream(); OutputStream os = clientSocket.getOutputStream(); int n = 0; int data; while ((n = is.read()) >= 0) { os.write(n); } } catch (IOException e) { e.printStackTrace(); } }} 如果像一些资料所述的那样把RUNNABLE状态分为两种：
- RUNNING 确实在占用CPU，跑代码
- READY 没有占用CPU，等待调度
但把这个网络IO阻塞的过程划分到后者感觉也是不妥。