它会从队列里一直不停的获取待执行的任务，也就是 getTask()；在 getTask 也能看出它会一直从内置的队列取出任务。
而一旦队列是空的，它就会 waiting 在 workQueue.take()，也就是我们从堆栈中发现的 1067 行代码。
线程名字的变化
上文还提到了异常后的线程名称发生了改变，其实在 addWorker() 方法中可以看到 new Worker()时就会重新命名线程的名称，默认就是把后缀的计数+1。
这样一切都能解释得通了，真相只有一个：
在单个线程的线程池中一但抛出了未被捕获的异常时，线程池会回收当前的线程并创建一个新的 Worker；
它也会一直不断的从队列里获取任务来执行，但由于这是一个消费线程，根本没有生产者往里边丢任务，所以它会一直 waiting 在从队列里获取任务处，所以也就造成了线上的队列没有消费，业务线程池没有执行的问题。
所以之后线上的那个问题加上异常捕获之后也变得正常了，但我还是有点纳闷的是：
既然后续所有的任务都是在线程池中执行的，也就是纯异步了，那即便是出现异常也不会抛到消费线程中啊。
这不是把我之前储备的知识点推翻了嘛？不信邪！之后我让运维给了加上异常捕获后的线上错误日志。
结果发现在上文提到的众多 switch case 中，最后一个竟然是直接操作的数据库，导致一个非空字段报错了