worker是线程池中封装thread并实现runnable的内部类，通过while循环复用执行任务，利用aqs状态控制中断，其生命周期由gettask()超时策略决定，不可外部直接操作。
Worker 是什么？它不是 Thread，而是 Runnable 的“包装器”
线程池里真正干活的不是裸露的 Thread，而是一个叫 Worker 的内部类——它实现了 Runnable，同时持有一个 Thread 实例。你调用 execute() 提交任务时，线程池不会直接把任务塞给 Thread.run()，而是让 Worker 自己去循环取任务、执行、再取下一个。
关键在于：Worker 的 run() 方法里根本没写死只执行一次，而是调用了 runWorker(this)，后者是个 while 循环体：
final void runWorker(Worker w) {
Runnable task = w.firstTask;
while (task != null || (task = getTask()) != null) {
task.run(); // 这里才是你传进来的 Runnable
task = null;
}
}
-
firstTask是创建Worker时指定的初始任务（可能为null），用于支持预热或立即执行 - 循环中
getTask()才是复用的核心：它从workQueue阻塞或超时取任务，取不到就等，取到就执行 - 一旦
getTask()返回null，while 结束，Worker退出，对应线程自然终止
getTask() 怎么决定线程该不该回收？看两个条件
getTask() 不是无脑阻塞，它会根据当前线程数和配置动态选择等待策略，直接决定非核心线程是否被回收：
- 如果
allowCoreThreadTimeOut == true，所有线程都按超时逻辑走 - 否则，仅当
workerCount > corePoolSize（即当前是非核心线程）时，才启用超时等待 - 超时等待用的是
workQueue.poll(keepAliveTime, unit)；不超时则用workQueue.take()（永久阻塞）
也就是说：核心线程默认永不超时，哪怕队列空着也一直卡在 take() 上；而非核心线程在空闲满 keepAliveTime 后，poll() 返回 null，整个 Worker 就退出了。
常见踩坑点：keepAliveTime 设得太小（比如 10ms），又频繁提交低频任务，会导致非核心线程刚建好就回收，反复创建销毁，反而失去复用意义。
为什么 Worker 要继承 AQS？锁在哪用？
Worker 继承 AbstractQueuedSynchronizer（AQS）不是为了并发控制任务，而是为了**安全中断线程**——它用 AQS 的 state 做线程运行状态标记（-1 初始化、0 运行中、1 已完成），并在执行任务前后加锁/解锁。
- 执行前调用
lock()，防止外部在任务运行中调用interrupt() - 执行后
unlock()，允许后续中断操作生效 - 真正中断线程靠的是
thread.interrupt()，但必须等当前任务跑完、且getTask()再次进入阻塞前才生效
所以你看到的 shutdownNow() 并不能立刻杀死正在执行的任务，它只是：① 设置线程池状态为 STOP；② 对所有 Worker.thread 调用 interrupt()；③ 清空队列。任务是否响应中断，完全取决于你自己的 Runnable 是否检查 Thread.interrupted()。
别把 Worker 当普通线程对象去操作
有人试图拿到 Worker 实例后手动调用 run() 或修改 firstTask，这是错的——Worker 是线程池私有实现，没有公开 API，也不保证线程安全。
- 不能 new Worker(...) 然后 start()，它的
thread字段由线程池通过ThreadFactory创建并绑定 - 不能在外部保存
Worker引用并期望它长期有效；线程退出后，该对象会被 GC，且不再关联任何线程 - 监控线程池运行状态，请用
ThreadPoolExecutor提供的getActiveCount()、getCompletedTaskCount()等方法，而不是遍历内部workersSet
真正需要定制行为的地方，是替换 ThreadFactory（比如统一命名、设置守护属性）或重写 beforeExecute()/afterExecute() 钩子方法——这些才是开放、稳定、可维护的扩展点。
