Java线程池中的线程是如何复用的

Worker.run() 中的 while 同一线程可持续消费任务的循环复用：首先执行初始消费任务： firstTask，再循环调用 getTask() 阻止获取任务；getTask() 返回 null（shutdown、stop 或空闲加时)循环退出，线程终止。

Worker.run() 里那个 while 循环是什么？

线程复用的关键隐藏在Worker类的run()在方法上——它在执行之前就退出了，而是继续从阻塞队列中提取任务。这个循环不是“重复启动新线程”，而是相同的Thread反复调用对象task.run()。

常见错误：认为线程池 submit 一次新建一个线程；发现线程数稳定 corePoolSize，但任务仍在运行——事实上，同一行程正在循环消费。

• Worker初始化将绑定一个初始化firstTask，只有在执行完成后才进入循环
• 在循环体中调用getTask()，这种方法会阻止等待(例如使用)LinkedBlockingQueue.poll(timeout)）
• 如果getTask()返回null(超时，线程池 shutdown、或达到 maximumPoolSize 后空闲时间超时)，循环退出，线程自然结束
• 注意：runWorker(Worker w)是实际执行循环的入口，Worker.run()只是委托给它

getTask() 返回 null 三个典型的时机

线程复用不是无限的，getTask()返回null这意味着这个Worker退出。这不是 bug，回收机制设计良好。

容易踩的坑：手柄allowCoreThreadTimeOut = true和keepAliveTime = 0混用，导致 core 线程也立即被销毁，但没有人排队处理任务。

• 线程池已shutdown，而且工作队列为空 → 立即返回null
• 线程池已stop→ 无论队列是否空，直接返回null
• 线程空闲超时:当前线程数 > corePoolSize，且从队列 poll 超过keepAliveTime未拿到任务 → 返回null

为什么 Worker 继承 AQS 却不用锁？

Worker继承AbstractQueuedSynchronizer，但没有用它作为互斥锁，而是借用了它 state 字段和 CAS 原语，实现线程中断状态的原子控制。

使用场景：调用时thread.interrupt()确保不干扰正在运行的任务(例如，任务本身也在调用)interrupt()），也不能错过中断信号。

• Worker用AQS.setState(0)表示“允许中断”，setState(1)表示“运行中禁止中断”
• runWorker()在执行任务之前开始调用interruptIfStarted()，只在 state == 1 真正中断线程的时间
• 若任务本身被调用Thread.sleep()或queue.take()，中断会抛出InterruptedException，此时，线程不会立即退出，而是继续下一轮循环 —— 这是重用的前提

自定义 ThreadFactory 最容易被忽视的点

许多人认为只要重写newThread()可以控制线程行为，但忘记了Worker在构造过程中对线程进行处理target设为自身（Runnable），而不是用户传递的任务。

后果:如果你在线程工厂设置了线程setUncaughtExceptionHandler，它确实有效，但如果试图通过setContextClassLoader影响任务执行环境的可能性很大——因为任务是在Worker.run()内部调用取决于上下文类加载器Worker创建线程时的快照不是你 newThread 时设的那个。

• 务必在newThread()有意义的线程名设置在其中，如"biz-pool-worker-" + counter.getAndIncrement()，否则，堆栈里全是pool-1-thread-1
• 不要依赖线程工厂修改线程优先级——JVM 规范不能保证跨平台的有效性，可能会被容器或安全策略拦截
• 若需传递上下文(如 TraceId），不能依靠线程局部变量的初始化execute()或submit()时显式包装任务(例如使用)new ThreadLocalContextWrapper(task)）