任务提交性能直接受workQueue.offer()效率决定：SynchronousQueue靠线程交接、无内存开销但依赖线程可用性；ArrayBlockingQueue为O(1)数组操作，满则立即拒绝；LinkedBlockingQueue需分配Node对象并承受GC压力，看似成功实则隐性堆积。
线程池的任务提交性能直接受工作队列插入效率的影响，不是间接关系，而是关键路径上的决定性环节。任务能否快速入队、是否触发线程扩容、会不会立刻被拒绝，全取决于 workQueue.offer() 这一步的耗时与成败。
队列类型决定插入行为本质
不同队列对 offer() 的实现差异巨大，直接影响提交吞吐量和响应延迟：
- SynchronousQueue：不存储任务，offer() 实际是“找空闲线程交接”，失败意味着当前无空闲线程且无法新建（受限于 maximumPoolSize），会直接走拒绝流程。插入本身几乎无内存开销，但成功率高度依赖线程可用性。
- ArrayBlockingQueue（有界）：底层数组，offer() 是 CAS + 数组索引更新，平均 O(1)，但满时立即返回 false，迫使线程池创建新线程或触发拒绝策略。
- LinkedBlockingQueue（无界，默认 Integer.MAX_VALUE）：基于链表，offer() 需分配 Node 对象并 CAS 更新 tail，存在 GC 压力；虽极少返回 false，但插入看似成功，实则把压力转移到堆内存——任务堆积后 GC 频繁，最终拖慢整个 submit() 调用。
插入失败不等于提交失败，但意味着决策转向
ThreadPoolExecutor 的 submit/execute 不是“先入队再调度”，而是按固定顺序判断。workQueue.offer() 返回 false 时，线程池不会重试或等待，而是立即进入下一步：检查是否还能扩容线程。这个过程本身很快，但后果显著：
- 若允许扩容（线程数 < maximumPoolSize），就 new Thread → start，带来线程创建开销；
- 若已达上限，直接调用拒绝策略——比如默认的 AbortPolicy 会抛 RejectedExecutionException，业务线程当场阻断。
也就是说，队列插入效率低（如锁竞争激烈）或容量不足，会高频触发线程创建或异常，使 submit() 从“纳秒级”操作退化为“毫秒级甚至更长”。
立即学习“Java免费学习笔记（深入）”；
高并发下队列争用会放大性能波动
多线程同时 submit 任务时，队列的并发安全机制成为瓶颈：
- ArrayBlockingQueue 使用单一把锁（ReentrantLock），所有 offer/put/take 串行化，高并发下易排队等待；
- LinkedBlockingQueue 用两把锁（putLock/takeLock），生产与消费分离，吞吐更高，但 offer() 仍需获取 putLock；
- SynchronousQueue 在高竞争下可能因自旋等待线程交接而消耗 CPU，尤其当核心线程忙、又未达 maximumPoolSize 时。
实测中，相同配置下，LinkedBlockingQueue 在 10K+ TPS 场景比 ArrayBlockingQueue 吞吐高 2–3 倍，但内存增长不可控；SynchronousQueue 在任务速率稳定时延迟最低，但突增流量易引发线程数飙升。
优化方向落在“匹配”而非“最快”
没有绝对最快的队列，只有最匹配场景的队列：
- 追求低延迟、任务执行快且速率平稳 → SynchronousQueue + corePoolSize ≈ expected concurrency；
- 任务执行时间差异大、允许适度缓冲 → ArrayBlockingQueue（设合理容量）+ 拒绝策略兜底（如 CallerRunsPolicy）；
- 任务间强依赖、不能丢失、且系统内存充足 → LinkedBlockingQueue，但必须监控队列 size 和 GC 表现，防 OOM；
- 超高吞吐、多核利用率优先 → 可考虑 DelayedWorkQueue（ScheduledThreadPool）或自定义无锁队列，但复杂度陡增。
真正影响性能的，从来不是单次插入快慢，而是队列行为如何与线程池参数、任务特征、系统资源形成闭环反馈。调优时盯着队列，其实是盯着整个线程池的节拍器。
