事情是这样了，一个月黑风高的晚上，窗外的冷空气是那么的可口解渴，让人沉浸地无法自拔，人们都沉沉的睡去了，它正贪婪地，，，，突然，，，，
我这kafka不消费数据，是这个问题引起的？看着不像，正说着发来了线程堆栈
看着不像kafkaConsumer的线程栈啊，其实另一张图有就不发了没啥看头
如此如此
这般这般
，，，，，，，，，，，，，，，，，，，，，，
最后同事那边说是卡在与数据库通信上了也不是kafka消费的问题
但是，我看那个java线程的函数调用栈跟状态有点怪啊，明明是调用socket的read接口，top下任务状态又是S，除非是非阻塞的（如果是阻塞的strace会卡住），我想也没有人会搞个非阻塞的轮询加个sleep吧！既然是阻塞IO，这个java线程的状态不该是RUNNABLE，应该是BLOCKED阻塞状态才对啊，被read block住才对
在我的记忆里一个正常运行的linux任务基本上只要不运行卡住了大多数就是STD这三个状态，STD都称为阻塞状态，但我隐约记得以前看jstack时看到java线程有个BLOCKED状态，这个java线程是在read socket时卡住了与之对应的linux任务状态是S，那这个java线程不该是BLOCKED状态？都阻塞了跑不了了，怎么还成了RUNNABLE状态
于是带着疑惑来看看这个RUNNABLE状态到底是个哈
如上图java线程一共有6种状态
NEW：创建了一个线程但还未调用start启动
RUNNABLE：java任务的字节码正在被jvm的字节码解释器解释执行（什么时候才不在jvm上执行？等待monitor lock，调用wait，join,被LockSupport.park时?）或等待 “操作系统的资源“，这个”操作系统的资源“是指什么？除了等待被调度到物理CPU上运行外，
我想是不是还应当包括jvm调用os提供的接口？如accept一个新连接，从磁盘，网络读写数据等，
调用os的接口也是所谓的 “操作系统的资源“ 的一部分？就算调用的接口将会阻塞与之对应的os线程，
对jvm而言这个线程还是可运行的，因为调用一个os阻塞的系统调用而被阻塞，这对jvm而言是无法感知的，
而因jdk的LockSupport.park，或jvm的monitor lock被阻塞，都是在jvm的管控下，
因此可以在阻塞线程前根据调用的接口修改与之对应的java线程的状态，java线程的阻塞是jvm操作的，
os线程的阻塞是os操作的，java的线程模型是1:1的，一个java线程对应一个os线程，jvm只是把os线程封装了一下
BLOCKED：线程等待获取monitor lock时的状态
WAITTING：线程wait ，join或被LockSupport.park等待被唤醒时的状态
对于BLOCKED与WAITTING状态的java线程，在操作系统原理中都称为阻塞态，不知道为什么还要做区分
TIMED_WAITTING：线程sleep，wait，join，LockSupport.park带超时等待被唤醒时的状态
TERMINATED：线程运行结束退出
因此java线程因等待IO而被阻塞时状态是RUNNABLE而不是BLOCKED，java线程只有被特定的接口操作后才会转变为特定的状态，就算被一个os的系统调用阻塞，一个的RUNNABLE状态的java线程仍是RUNNABLE，java线程状态与之对应的os线程状态并没有多大关系，其状态是独立于os线程的，要想知道一个处于RUNNABLE状态的java线程到底是卡住了还是正在物理CPU上运行，还是要通过宿主操作系统才能知道
那么问题来了STW时，java业务线程的状态是什么？
我猜是RUNNABLE