使用Executors.newFixedThreadPool时，线程等待网络操作会被重复调用run方法吗？

Executors.newFixedThreadPool 创建的固定线程池永远不会把处于网络等待状态的活跃工作线程判定为空闲，更不会主动重复调用该线程正在执行的Runnable的run方法。你担心的“线程池误判活跃线程导致数据篡改”的情况，并非线程池的设计逻辑，问题完全出在你复用带状态Runnable实例的代码逻辑本身。 #

固定线程池的实际运行逻辑 #

你之前对线程池的认知存在根本偏差：ExecutorService从来不会“主动调用线程池内线程的run方法”，整个固定线程池的运行机制非常明确：

• 固定线程池本质是核心线程数与最大线程数完全相等的ThreadPoolExecutor，启动后会提前创建好指定数量的工作线程。每个工作线程从诞生开始，就会进入一个永久循环：
  • 从线程池自带的无界阻塞任务队列里取待执行的Runnable任务
  • 拿到任务就执行它的run方法
  • run方法完全执行结束后，再回到第一步继续取下一个任务
  • 如果队列里没有任务，工作线程就会阻塞挂起，这个状态才被线程池判定为“空闲线程”
• 对“线程是否忙碌”的判定，线程池只认一个标准：这个工作线程有没有正在执行某一个Runnable的run方法、有没有把方法跑完。不管这个run方法内部是在做CPU计算、等网络IO、抢锁、甚至主动sleep，只要方法没执行完，这个工作线程就永远是“忙碌”状态，线程池绝对不会给它分配任何新任务，更不会重复触发它正在执行的Runnable的run方法。

举个极端例子：就算你连续给线程池提交100次同一个Runnable实例，线程池也会把这100次任务的run方法严格串行执行——必须等上一次run完全执行退出，才会执行下一次的run，绝对不会出现两个工作线程并行运行同一个Runnable实例的两次run方法的情况，这个边界是JDK线程池从实现层面就锁死的。

• 你新提交的所有任务，只要没有空闲工作线程能接，就会全部在阻塞队列里排队，等哪个工作线程把手头的run方法跑完了，才会从队列取出排队的任务执行。

你的代码的实际风险来源 #

你的代码混乱的根源，根本不是线程池“误判活跃线程”，而是你强行复用同一个带可变状态的Runnable实例的写法本身就不安全：
你维护了一个固定长度的processorPool数组，反复把同一个RequestProcessor实例提交给线程池执行，而且这个实例本身是带可变状态的（有自己的解析队列、实例字段）。实际运行的混乱场景是这样的：

1. 循环第一次走到i=0时，你给processorPool[0]调用init(data1)，把data1存入实例的队列，然后把这个实例作为Runnable提交给线程池。某一个工作线程接到任务，开始跑run：先是调用parseData()取到data1，然后进入processParsedData()等200ms的网络响应，这时候这个工作线程是完全被这个任务占住的。
2. 因为你的while循环跑的极快，i循环10次之后又回到0，你又给同一个processorPool[0]调用init(data2)，把data2存到这个实例的队列里，然后再次把同一个processorPool[0]作为Runnable提交给线程池。
3. 这时候正在处理data1的工作线程还是忙的，所以你第二次提交的这个Runnable任务，只会进到线程池的阻塞队列里排队，根本不会打断正在跑第一个任务的工作线程。等第一个任务的run方法完全跑完、工作线程空闲下来了，才会从队列拿出这个Runnable，第二次执行它的run方法。
4. 这个过程中，因为你可以在两次run执行的间隙，直接修改实例的可变状态（存新的data、改parsedData字段），很容易出现：第一次的run方法还在等网络IO的间隙，你已经通过init方法往实例的队列里塞了新的data2，甚至改了实例字段，等第一次run走到parseData()的时候，读到的已经不是原来的data1，而是被你改乱的状态。

简单说：线程池保证的是同一个工作线程不会并行重复跑同一个Runnable的run方法，但它管不着你在两次run执行的间隙，随便修改这个Runnable实例的内部状态——这才是你代码里数据被篡改的根源。 #

代码调整方向 #

• 不要维护固定长度的Runnable实例池反复复用，每次收到新请求，直接new一个全新的RequestProcessor实例，把当前请求的data通过构造方法传进去，再提交给线程池执行就行。每个Runnable实例只对应一次请求处理，没有共享的可变状态，自然不会出现数据篡改的问题。
• 你代码里给RequestProcessor加的实例内部队列完全是多余的，单实例只需要处理单条请求数据即可。
• 如果觉得网络等待占住工作线程浪费资源，可以优化网络客户端的超时配置、或者调整线程池的大小匹配实际的网络延迟，这和线程池的任务执行逻辑没有关系。

内容的提问来源于stack exchange，提问作者CornerH