孤舟笔记 并发篇二十五 当任务数超过核心线程数时，如何让任务不进入队列？线程池调优的经典问题

文章目录

• • 一、先说结论：三种让任务不进队列的方法
  • 二、先搞懂：默认流程为什么先进队列？
  • 三、方法一：SynchronousQueue------不存任务的队列
  • [四、方法二：自定义队列------让 offer() 返回 false](#四、方法二：自定义队列——让 offer() 返回 false)
  • [五、方法三：调大 corePoolSize](#五、方法三：调大 corePoolSize)
  • 六、三种方式对比
  • 七、什么时候需要让任务不进队列？
  • 任务不进队列全景
  • 回答技巧与点评
  • • • 标准回答
      • 加分回答
      • 面试官点评

个人网站

默认的线程池任务提交流程是：核心线程 → 队列 → 非核心线程 → 拒绝策略。但有些人想让任务跳过队列，直接创建非核心线程------这该怎么做？

这道题考的不是死记硬背，而是你对线程池任务提交顺序的底层理解。

一、先说结论：三种让任务不进队列的方法

方法	原理	优缺点
使用 SynchronousQueue	不存储任务，直接交给线程	线程数可能暴涨
自定义队列的 offer()	拒绝入队，返回 false	触发创建非核心线程
调大 corePoolSize	核心线程够多，任务直接执行	资源占用高

一句话记住：让任务不进队列 = 让队列"拒绝接收"任务 = offer() 返回 false → 线程池被迫创建新线程。

二、先搞懂：默认流程为什么先进队列？

// ThreadPoolExecutor.execute() 核心逻辑（简化）
public void execute(Runnable command) {
    int c = ctl.get();
    
    // 1. 线程数 < corePoolSize → 创建核心线程
    if (workerCountOf(c) < corePoolSize) {
        if (addWorker(command, true))
            return;
    }
    
    // 2. 核心线程满了 → 入队列 👈
    if (workQueue.offer(command)) {
        // 入队成功
    }
    
    // 3. 入队失败 → 创建非核心线程 👈
    else if (!addWorker(command, false)) {
        reject(command);  // 4. 也失败了 → 拒绝
    }
}

关键： 只有 workQueue.offer() 返回 false 时，才会走到第 3 步创建非核心线程。

所以让任务不进队列的核心思路就是：让 offer() 返回 false。

三、方法一：SynchronousQueue------不存任务的队列

ThreadPoolExecutor pool = new ThreadPoolExecutor(
    5,                                      // 核心线程 5
    50,                                     // 最大线程 50
    60, TimeUnit.SECONDS,
    new SynchronousQueue<>()                // 👈 不存储任务！
);

SynchronousQueue 的特殊性： 它内部不存储任何元素，offer() 只有当有消费者线程等着取时才返回 true，否则返回 false。

效果： 核心线程忙时，offer() 返回 false → 立刻创建非核心线程。

这就是 CachedThreadPool 的做法：

// Executors.newCachedThreadPool() 源码
new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS,
    new SynchronousQueue<>()  // 👈
);

风险： 线程数可能暴涨到 maximumPoolSize。适合短时轻量任务，不适合耗时任务。

四、方法二：自定义队列------让 offer() 返回 false

这是最灵活的方式，自定义一个队列，让它在特定条件下拒绝入队：

class ForceQueuePolicy extends LinkedBlockingQueue<Runnable> {
    public ForceQueuePolicy(int capacity) {
        super(capacity);
    }

    @Override
    public boolean offer(Runnable task) {
        // 先尝试创建非核心线程
        // 让 offer 返回 false → 触发 addWorker(command, false)
        return false;  // 👈 永远拒绝入队！
    }
}

但这样有问题： 如果线程数已经到 maximumPoolSize，offer() 还返回 false，任务会被拒绝。

更安全的做法------先尝试创建线程，失败了再入队：

class SmartQueue extends LinkedBlockingQueue<Runnable> {
    private final ThreadPoolExecutor pool;

    public SmartQueue(int capacity, ThreadPoolExecutor pool) {
        super(capacity);
        this.pool = pool;
    }

    @Override
    public boolean offer(Runnable task) {
        // 线程数未达最大 → 拒绝入队，让线程池创建新线程
        if (pool.getPoolSize() < pool.getMaximumPoolSize()) {
            return false;  // 👈 拒绝入队，触发创建非核心线程
        }
        // 线程数已达最大 → 正常入队
        return super.offer(task);  // 👈 入队等待
    }
}

效果： 核心线程忙时优先创建非核心线程，线程数到顶了才入队。

五、方法三：调大 corePoolSize

最简单粗暴的方式------让核心线程数足够大，任务一来就有空闲线程：

// 将核心线程数调到和最大线程数一样
ThreadPoolExecutor pool = new ThreadPoolExecutor(
    50,                                     // core = max 👈
    50,
    0, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(100)
);

效果： 线程数未达 corePoolSize 时，任务直接分配给新核心线程，不进队列。

缺点： 50 个核心线程即使空闲也不回收（除非 allowCoreThreadTimeOut），资源浪费。

六、三种方式对比

场景：核心线程 5，最大线程 50，来了 10 个任务

方式一：SynchronousQueue
5 个核心线程 + 5 个非核心线程 = 10 个线程并行
✅ 响应快  ⚠️ 线程数可能暴涨

方式二：自定义队列（offer 返回 false）
5 个核心线程 + 5 个非核心线程 = 10 个线程并行
✅ 灵活可控  ⚠️ 实现稍复杂

方式三：调大 corePoolSize（core=50）
10 个核心线程并行，40 个空闲等待
✅ 简单  ⚠️ 资源浪费

默认：LinkedBlockingQueue
5 个核心线程执行，5 个任务排队等待
⚠️ 5 个任务在队列里等着，不创建新线程

七、什么时候需要让任务不进队列？

需要跳过队列的场景：

• 任务对响应时间敏感（如 HTTP 请求），不想排队等
• 任务量波动大，高峰期需要快速扩容线程
• 任务执行时间短，创建线程的开销可接受

不需要跳过队列的场景：

• 任务量稳定，核心线程就能处理
• 任务执行耗时长，创建太多线程反而增加调度开销
• 需要控制并发度，避免资源耗尽

任务不进队列全景

任务不进队列 全景

核心原理
workQueue.offer() 返回 false → 触发创建非核心线程

三种方法
├── SynchronousQueue ── 不存任务，直接交接
│   ✅ 简单  ⚠️ 线程数暴涨
├── 自定义队列 ── offer() 按条件返回 false
│   ✅ 灵活可控  ⚠️ 实现稍复杂
└── 调大 corePoolSize ── 核心线程够多
    ✅ 最简单  ⚠️ 资源浪费

默认流程
核心线程 → 队列 → 非核心线程 → 拒绝策略
                   ↑
            offer() 返回 false 才到这里

口诀：默认先进队，要跳得让 offer 返 false，
      SynchronousQueue 不存任务，
      自定义队列按条件拒，核心线程多也行，
      选哪种看场景，响应快和资源省要权衡。

回答技巧与点评

标准回答

默认线程池的任务提交流程是核心线程 → 队列 → 非核心线程 → 拒绝策略，只有队列的 offer() 返回 false 时才会创建非核心线程。让任务不进队列有三种方式：一是使用 SynchronousQueue，它不存储任务，offer() 在没有消费者时直接返回 false，触发创建新线程；二是自定义队列，在 offer() 中根据线程数判断是否拒绝入队；三是调大 corePoolSize，让核心线程够用。三种方式各有取舍，需要根据响应时间和资源消耗的权衡来选择。

加分回答

1. Tomcat 的线程池策略：Tomcat 的 TaskQueue 就重写了 offer() 方法------当线程数未达 maximumPoolSize 时返回 false，优先创建线程；线程数满了才入队。这就是为什么 Tomcat 的线程池在高并发时响应比 JDK 默认策略快
2. 设计取舍 ：默认"先进队列再创建线程"是为了控制线程数量，避免大量短任务创建过多线程导致调度开销过大。"先创建线程再入队"适合对延迟敏感的场景，但要防止线程暴涨。这是延迟 vs 吞吐量的经典权衡
3. 队列容量的影响：如果用有界队列（如 ArrayBlockingQueue(100)），队列满了 offer() 也会返回 false，自然触发创建非核心线程。所以有界队列比无界队列更"积极"地创建非核心线程

面试官点评

这道题考的是你对线程池任务提交流程的深度理解。能说出"让 offer 返回 false"是关键得分点，能对比三种方式的优劣、提到 Tomcat 的实践、以及设计取舍（延迟 vs 吞吐量），说明你有实战调优经验。面试官最想听到的是：你不只是背答案，而是理解了"队列是缓冲还是直通"这个设计选择的本质。

原文阅读

---

内容有帮助？点赞、收藏、关注三连！评论区等你 💪