Java线程池默认不支持负载均衡，任务分发由execute()逻辑决定而非队列；真正有效的负载感知需侵入任务获取环节（如重写poll/take）或利用RejectedExecutionHandler配合自定义调度器，但实现复杂且易出错；推荐优先使用ForkJoinPool依赖工作窃取机制自动平衡。
Java线程池默认不支持负载均衡，ThreadPoolExecutor 的 workQueue 是被动接收任务的
很多人以为把 LinkedBlockingQueue 换成自定义队列就能实现“负载均衡”，其实不然。线程池的任务分发逻辑在 execute() 方法里：先尝试用空闲线程直接执行，失败才入队。队列本身不参与“哪个线程该拿哪个任务”的决策，它只是个缓冲区。所谓“自定义分配算法”，必须侵入到任务提交或获取环节，而不是只改队列。
常见错误现象：ThreadPoolExecutor 启动后，部分线程长期忙碌、部分长期空闲，监控显示 CPU 利用率不均——这不是队列问题，是任务提交模式和线程本地性导致的。
- 使用场景：适合任务耗时差异大（如 10ms 和 2s 混合）、且无法预估执行时间的后台批处理
- 真正起作用的不是队列类型，而是
execute()中对corePoolSize和maximumPoolSize的判断逻辑，以及getTask()从队列取任务的方式 - 性能影响：强行在
offer()里做线程选择会引入锁竞争或 CAS 开销，可能比默认策略更慢
想让任务“主动找线程”，得用 RejectedExecutionHandler + 自定义调度器
标准线程池没提供“任务路由”接口，但可以利用拒绝策略这个钩子：当线程池满（包括队列满）时，由你接管任务分发权。配合一个轻量级调度器，就能实现近似负载感知的分发。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把
workQueue设为无界队列（如new LinkedBlockingQueue(0)或直接用SynchronousQueue），让线程池快速进入“拒绝”状态，触发你的调度逻辑 - 实现
RejectedExecutionHandler，在rejectedExecution()里查各工作线程当前任务数（需自行维护计数，比如用AtomicIntegerArray记录每个Worker的活跃任务数） - 选负载最低的线程，用
Thread.interrupt()唤醒其getTask()，再通过共享队列把新任务塞给它（注意线程安全） - 兼容性注意：JDK 8+ 的
ThreadPoolExecutor.Worker是包私有类，不能直接继承或访问，只能靠反射或 JMX 获取运行中线程状态——不推荐生产用
更现实的做法：用 ForkJoinPool 替代，靠工作窃取自动平衡
如果你的目标是“让长任务不卡住整个池”，ForkJoinPool 比手动搞负载均衡靠谱得多。它的 WorkQueue 是双端队列，空闲线程会从其他线程队列尾部“窃取”任务，天然适配不均任务。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
使用条件：
- 任务可分解（符合 fork/join 模式），哪怕只是逻辑上拆成子任务
- 避免阻塞操作：调用
join()或get()会挂起当前线程，破坏窃取机制；要用CompletableFuture配合ForkJoinPool.commonPool() - 参数差异：
parallelism控制并发线程数，默认是CPU 核心数 - 1，不是 core/max 两层结构 - 错误信息示例：
java.util.concurrent.RejectedExecutionException: Thread limit exceeded replacing blocked worker表示并行度设太高，触发了内部保护
真要自定义 BlockingQueue 分配逻辑，必须重写 poll() 和 take()，而非 offer()
很多文章教你在 offer() 里选线程，这是错的。任务入队时线程还没开始取，你选了也没用。真正决定“谁拿到任务”的，是 poll() 或 take() 被哪个线程调用——所以分配逻辑得放在这里。
例如：
public class LoadAwareQueue extends LinkedBlockingQueue<Runnable> {
private final AtomicIntegerArray load = new AtomicIntegerArray(threads.length);
// ...
@Override
public Runnable poll() {
int minLoadIdx = findMinLoadIndex(); // 找当前最空闲线程索引
if (minLoadIdx != -1) {
load.incrementAndGet(minLoadIdx); // 标记它即将执行
return super.poll();
}
return super.poll();
}
}但问题来了：poll() 返回后，线程可能立刻执行，也可能被中断或丢弃；你没法保证“标记的线程”真去执行它。而且多个线程并发 poll()，计数极易错乱。这类实现在线上极难稳定，调试成本远高于收益。
复杂点在于：负载感知需要实时、低开销的状态同步，而 JVM 线程模型没暴露足够接口。与其硬刚，不如接受“任务分发不可控”这个事实，转而优化任务设计本身——比如加超时、拆粒度、用异步回调解耦执行链。
