SynchronousQueue 实现直接提交，因其无容量设计要求任务必须被空闲线程立即接收或触发线程创建；若无空闲线程且未达 maximumPoolSize，则新建线程，否则执行拒绝策略。
在 Java 线程池中，使用 SynchronousQueue 是实现“直接提交（Direct Handoff）”策略的核心方式。它本身不存储任务，每个 submit() 或 execute() 调用都必须立即被一个空闲线程接收；若无空闲线程，且线程数未达 maximumPoolSize，则会创建新线程；否则触发拒绝策略。
为什么 SynchronousQueue 实现直接提交
SynchronousQueue 是一个没有容量的阻塞队列，内部不保存元素——生产者线程必须等待消费者线程就绪才能完成插入操作。在线程池语境下：
- 当调用
execute(task)时，如果核心线程都在忙，任务无法入队，只能尝试创建新线程（前提是当前线程数 maximumPoolSize） - 若线程数已达
maximumPoolSize，且无空闲线程接收任务，则直接触发拒绝策略（如AbortPolicy） - 因此它天然规避了任务排队积压，符合“有空线程就交、没空就扩容、扩不了就拒绝”的直接提交语义
典型构造方式：配合 newCachedThreadPool 或自定义 ThreadPoolExecutor
标准的 Executors.newCachedThreadPool() 内部就是基于 SynchronousQueue：
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());
}
你也可以手动构建，更清晰地控制参数：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
ThreadPoolExecutor executor = new ThreadPoolExecutor(
2, // corePoolSize：至少保留 2 个常驻线程
10, // maximumPoolSize：最多允许 10 个线程并发
30L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>(), // 关键：无缓冲队列
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝时由调用线程执行
);
使用注意事项与常见陷阱
直接提交虽响应快、内存开销小，但对负载突增敏感，需谨慎配置：
-
corePoolSize 设为 0 是可行的（如
newCachedThreadPool），此时所有线程都是“按需创建 + 空闲回收”，适合短时突发任务 - maximumPoolSize 不宜过大，否则高并发下可能创建过多线程，引发 OOM 或上下文切换开销剧增
-
拒绝策略必须明确指定，默认
AbortPolicy会抛RejectedExecutionException，线上建议用CallerRunsPolicy或自定义日志+降级逻辑 - 不要混用 SynchronousQueue 和非零 corePoolSize + 低 maximumPoolSize，比如 core=5、max=5、queue=SynchronousQueue，此时第 6 个任务必被拒绝——因为无空闲线程、又不能扩容
验证是否生效的小技巧
可通过日志或调试确认任务是否真没排队：
- 重写
beforeExecute和afterExecute观察线程创建/执行时机 - 在拒绝策略中打印堆栈，看是否频繁触发（说明压力大且扩容/消费跟不上）
- 用
executor.getQueue().size()查队列长度——对SynchronousQueue总是返回 0，这是正常现象，不代表任务丢失
