原始的workerThread模式包含三种角色：工人、传送带、产品，
传送带中维护一个productionsQueue以及最大的产品数量（为了防止产品无限积压）,
在传送带初始化时，创建了若干个worker（线程），worker不断从传送带取产品进行加工，
当传送带中无产品时，worker线程被挂起等待唤醒，当有新的产品加入到传送带中时，挂起的worker会被唤醒，取产品加工。
当上游线程Thread往传送带中加入产品时，如果productionsQueue到达最大产品数量时，Thread会被挂起。
当有worker线程取出产品后，会唤醒阻塞的线程Thread(当然这里也有可能唤醒worker)
线程池只是workerThread的一种实现，那么线程池中创建的Thread就是工人，线程池本身就是传送带，产品就是提交到线程池中的Runnable，
而在线程池中的阻塞队列就相当于productionsQueue，请问老师，我这样理解是否正确？

 

执行代码后查看线程栈会发现pool-1-thread-1一直处于waiting状态，因为外层的pool.submit等待内层pool.submit，内层又在等待外层submit的释放，简直是相互伤害到地老天荒啊。解决方案有两种：
1、最简单就是把线程个数从1个改到2个，然后代码运行就会成功打印出来QQ
2、真正要解决的还是需要针对有依赖关系的代码分配不同的线程池，只有真正无关的逻辑才能共用一个线程池。
第一次发现原来线程池之中还有deadlock的问题存在，其实说白了，线程池只是解决了频繁线程创建和销毁的代价问题，关于并发所带来的的问题，它是一点力都没出的，甚至某些时候还带来了一些问题(比如threadlocal)。