有界队列触发最大线程数的条件是：队列已满且当前线程数小于核心线程数时，新任务会创建新线程直至达到最大线程数。
有界队列触发最大线程数的条件是什么
有界队列（如 ArrayBlockingQueue）在线程池中不会立即创建新线程——只有当队列已满，且当前线程数 corePoolSize 时，会优先新建核心线程；等达到 corePoolSize 后，新任务会尝试入队；入队失败（即队列满），才开始新建非核心线程，直到达 maximumPoolSize。
关键点在于「入队失败」这个动作：它不是靠定时检测或延迟判断，而是 offer() 方法直接返回 false，线程池捕获后才走扩容逻辑。
-
ArrayBlockingQueue的offer()是非阻塞的，满则立刻返回false，触发扩容 -
LinkedBlockingQueue默认构造时容量为Integer.MAX_VALUE，表面有界实为“伪有界”，几乎不会触发扩容，容易误以为是无界队列 - 若手动指定小容量（如
new LinkedBlockingQueue(10)），它就真变成有界队列，行为与ArrayBlockingQueue一致 - 注意：
SynchronousQueue容量为 0，不存储任务，每个offer()都需配对的poll()，因此「总是入队失败」→ 几乎每次都触发新建线程（只要没到maximumPoolSize）
无界队列为什么几乎不扩容、却更容易 OOM
典型无界队列是 LinkedBlockingQueue（无参构造）或 PriorityBlockingQueue。它们的 offer() 永远返回 true，线程池永远不会走到“入队失败 → 新建线程”分支，所以线程数永远卡在 corePoolSize，哪怕任务堆积如山。
后果很直接：所有额外任务全堆在队列里，JVM 堆内存持续增长。尤其当任务对象本身较大（比如含 byte[] 或 JSON 字符串），或生产速度稳定高于消费速度，OutOfMemoryError: Java heap space 就只是时间问题。
立即学习“Java免费学习笔记（深入）”；
-
LinkedBlockingQueue无参构造 → 容量Integer.MAX_VALUE，但实际能存多少取决于堆内存，不是“无限” -
PriorityBlockingQueue是无界且无容量限制，但内部用数组实现，扩容会触发Arrays.copyOf()，加剧 GC 压力 - 别指望 GC 能救你：任务对象往往被队列强引用，只要队列不缩容、不清理，GC 就无法回收
怎么选队列才能平衡资源与可靠性
没有银弹，只看你的场景压测数据和失败容忍度。想保吞吐？宁愿 OOM 也要少建线程，选无界队列 + 稳定的 corePoolSize；想控内存、允许临时拒掉部分请求？选有界队列 + 合理 maximumPoolSize + 拒绝策略。
- 高吞吐、低延迟敏感服务（如网关）：用
SynchronousQueue，逼出真实并发能力，但必须配好maximumPoolSize和拒绝策略（如AbortPolicy） - 后台批处理、可接受延迟的任务：用小容量
ArrayBlockingQueue（如 100~1000），配合略高的maximumPoolSize，让线程数随负载弹性伸缩 - 绝对避免
LinkedBlockingQueue无参构造用于高流量入口——它看起来安全，实则是 OOM 温床 - 如果必须用无界语义，至少加监控：定期采样
queue.size()，超过阈值告警或自动降级
ThreadPoolExecutor 拒绝策略和 OOM 的关系
拒绝策略只在「线程数已达 maximumPoolSize 且队列已满」时生效。也就是说：有界队列 + 合理 maximumPoolSize 才有机会触发拒绝；无界队列下，拒绝策略基本永不执行——因为队列永远不会满。
常见误区是以为设了 CallerRunsPolicy 就万事大吉。但它会让调用线程（比如 Tomcat 的 worker 线程）去执行任务，可能拖慢整个请求链路，甚至引发线程饥饿，反而掩盖了真正的容量瓶颈。
-
AbortPolicy抛RejectedExecutionException，最易暴露问题，适合快速失败场景 -
DiscardPolicy静默丢弃，风险高——下游系统可能收不到通知，状态不一致 - 自定义策略里记录日志或发消息可以，但别在里面做重试或复杂逻辑，会卡住线程池的拒绝判断路径
- 真正该做的，是在拒绝发生前就通过指标（队列长度、活跃线程数、任务等待时间）做熔断或限流
线程池不是黑盒，它的行为完全由队列的 offer() 返回值驱动。看懂这一行返回值，比背十种配置组合都管用。
