同一个线程，从操作系统层面和从JVM层面看，状态有可能是不一样的。

关于从JVM层面，线程状态有哪些，可以参考我的如下博客：

https://blog.csdn.net/Tom098/article/details/102873208

从操作系统层面，线程有哪些状态，，可以参考我的如下博客(这篇博客是介绍Linux下进程状态的，但是由于对Linux来说，线程也是一个进程，也有进程控制块，只不过操作系统内核为线程分配的资源比普通的进程要少一些，所以叫他Light Weight Process, 关于从操作系统内核角度看进程和线程的区别，这里不展开说。我们可以用'top -H'命令或者ps命令查看。比如查看进程2605的所有线程的状态，可以用命令 'ps -mp 2605 -o THREAD,pid,tid,state'查看，)：

https://blog.csdn.net/tom098/article/details/118442736

这里有一个用例，我们用如下的java代码来写一个简单的网络服务端程序：

 这个程序的功能就是在9999端口监听客户端请求，如果有客户端连上来，服务端就接受客户端发来的数据并打印出来。程序运行之后，我们故意不让任何客户端来接，这样服务端就会阻塞在第一行的代码 Socket.accept()方法的调用上,一直没有客户端请求练上来，这个方法一直不返回，这也是所谓的阻塞式IO。这时我们在一个新的shell 会话窗口执行命令 'kill -3 2605'， 2605是该java进程的ID，我们会在前一个SSH窗口看到该JVM进程的thread dump：

 可以看到一共有9各线程，"main"这个线程就是我们写的线程，他的nid=0xa2e,他的状态是RUNNABLE的，他正在运行的方法是java.net.PlainSocketImpl.socketAccept(Native Method)，是一个Native方法。剩下的8个线程都是JVM本身的线程，有的是WAITING状态，有的是RUNNABLE状态。按照猜测，如果我们用 'ps -mp 2605 -o THREAD,pid,tid,state'命令从操作系统层面查看各线程的状态，所有这些JVM里边看到的处于RUNNABLE状态的线程，在操作系统里看应该也是RUNNING状态的，其他JVM的thread dump里显示处于WAITING状态的线程，在操作系统层面看应该处于S或D的状态，下边我们看一下实际结果：

可以看到所有的线程都是S状态，也即：   interruptible sleep 状态。这里边的TID就是线程号了，可以看到第一行PID显示2605, TID空，第二行PID是空的，TID是2605，这也从一个侧面反映从操作系统内核角度，线程也是被当作进程的，每个线程都会有一个PCB(task_struct)。

那这些线程ID如何跟我们的JVM中的线程ID对应起来的，我们我们最关心的JVM中我们自己写的main()方法对应的主线程（nid=0xa2e）是ps命令输出中哪个线程呢？其实很好办，ps命令输出的TID都是10进制的，而JVM thread dump的nid都是16进制的，我们可以简单做一下转换，就可以找到了：

 比如我们这里看到2606就是我们自己写的线程，他的状态是S。而其他的JVM自身的线程，不管是WAITING的，还是RUNNABLE的，也都是S状态。这就印证了我们前边的结论，操作系统和JVM对线程的状态的理解还是有一点点不一样的，但不管怎样，最重要是我们自己要明白线程在做什么，至于你给这个线程定义一个什么状态，那都不是很重要，不要被这些状态所迷惑。

另外一个题外话，在这个例子中，我们进程PID是2605，而进程里边的线程是紧接着这个数字从2606到2614，可以看到操作系统在管理PID的号码时，不仅仅分配给了进程，还是分配给了线程的。