synchronousqueue被cachedthreadpool选用，因其零容量特性强制“生产即消费”：任务提交时若有空闲线程则立即执行，否则新建线程，完美匹配“按需创建、空闲回收”的弹性模型。
SynchronousQueue 是 Java 并发包中一个特殊的无缓冲阻塞队列，它不存储元素——每个插入操作必须等待另一个线程的移除操作，反之亦然。在 Executors.newCachedThreadPool() 中，它正是默认使用的任务队列。
为什么 CachedThreadPool 选用 SynchronousQueue？
因为 CachedThreadPool 的设计目标是“按需创建线程、空闲线程快速回收”，它不需要缓存待执行任务。如果用有容量的队列（如 LinkedBlockingQueue），任务会排队等待，可能延迟执行，也容易掩盖线程创建不足或资源瓶颈问题。而 SynchronousQueue 强制“生产即消费”：新任务提交时，若已有空闲线程，立刻交由其执行；否则就触发线程池扩容（新建线程）。这正好匹配“来活就干、没活就退”的弹性模型。
SynchronousQueue 如何影响线程生命周期？
当任务提交到使用 SynchronousQueue 的线程池时：
- 如果有空闲工作线程处于
take()等待状态，任务立即被该线程获取并执行； - 如果没有空闲线程，线程池会尝试新建线程（上限为 Integer.MAX_VALUE）；
- 线程在完成任务后，会再次调用
queue.poll(60L, TimeUnit.SECONDS)尝试获取新任务； - 若 60 秒内无新任务到达，线程就终止自身，实现自动回收。
实际使用中的注意事项
虽然 SynchronousQueue 让 CachedThreadPool 看起来很“智能”，但要注意：
- 高并发短任务场景下，可能频繁创建/销毁线程，带来调度和 GC 开销；
- 突发大量任务时，线程数可能飙升，若系统资源受限（如文件句柄、栈内存），易引发 OOM 或拒绝服务；
- 它不支持
peek()或批量操作，也无法查看当前待处理任务数（size()总是 0），调试和监控较困难； - 不适合需要任务排队保序、或希望控制最大并发数的业务场景——这时应考虑固定线程池 + 有界队列。
可以替换为其他队列吗？
不能直接通过 Executors.newCachedThreadPool() 替换，因为它是封装好的工厂方法。但你可以手动构造 ThreadPoolExecutor，并传入自定义队列：
- 用
new LinkedBlockingQueue(100)实现带缓冲的弹性池（需配合合理 core/max 线程数）； - 用
new ArrayBlockingQueue(n)控制积压上限，避免内存失控； - 甚至用
new DelayQueue()或自定义队列实现定时/优先级调度。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
