线程池死锁场景分析

原创已于 2025-09-27 18:07:37 修改 · 139 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#java #开发语言

于 2025-09-25 21:21:39 首次发布

JAVA研发专栏收录该内容

7 篇文章

订阅专栏

在并发编程中，线程池是提升性能的重要工具，但如果使用不当，可能会导致隐蔽的死锁问题。本文将剖析一次真实的线程池死锁场景，分析其产生原理，并提供可行的规避策略。

线程池死锁的典型场景

线程池死锁最常见的表现是：线程池中的核心线程全部被占用，新任务进入队列等待执行，而正在执行的核心线程又在等待队列中的任务完成，形成循环等待，最终导致整个线程池 "卡死"。

代码重现

以下代码可以稳定复现线程池死锁问题：

public static void main(String[] args){
        // 1个核心线程,超过默认进队列等待
        ExecutorService pool = new ThreadPoolExecutor(1,
                10,
                60,
                TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(200),
                new ThreadPoolExecutor.AbortPolicy()
        );

        pool.submit(() -> {
            try {
                log.info("第一层线程执行");
                // 在任务中再次向同一个线程池提交任务，并等待其完成
                pool.submit(() -> log.info("嵌套线程执行")).get();
                log.info("等待嵌套线程执行完成");
            } catch (Exception e) {
                log.error("error", e);
            }
        });
    }

执行结果与现象

运行上述代码后，控制台只会输出：

第一层线程执行

死锁产生的原理分析

要理解这个死锁的产生，我们需要结合线程池的工作原理和上述代码的执行流程：

线程池初始化：创建了一个核心线程数为 1 的线程池，这意味着正常情况下只有 1 个核心线程在工作
任务提交与执行：
- 主线程向线程池提交第一个任务（称为 "外层任务"）
- 线程池启动核心线程执行这个外层任务，此时核心线程处于忙碌状态
嵌套任务提交：
- 外层任务执行过程中，又向同一个线程池提交了第二个任务（称为 "内层任务"）
- 由于核心线程已经被占用，内层任务会被放入等待队列
死锁形成：
- 外层任务调用get()方法，等待内层任务执行完成
- 内层任务需要核心线程空闲后才能从队列中取出执行
- 核心线程被外层任务占用，且在等待内层任务完成
- 形成 "核心线程等待队列任务，队列任务等待核心线程" 的循环等待

线程池死锁的共性特征

通过对上述案例的分析，线程池死锁通常具有以下特征：

线程池嵌套使用：在线程池执行的任务中，再次使用同一个线程池提交新任务
同步等待机制：外层任务通过get()等方法同步等待内层任务完成
核心线程耗尽：核心线程数量不足以同时支撑外层任务和内层任务的执行
隐蔽性强：死锁发生时往往没有异常抛出，程序表现为停滞状态，难以排查

规避线程池死锁的策略

针对线程池死锁问题，我们可以采取以下几种规避策略：

1. 避免同一线程池的嵌套使用

最根本的解决方法是避免在一个线程池的任务中，再次使用同一个线程池提交新任务。如果业务逻辑确实需要嵌套执行，可以：

使用两个不同的线程池，分别处理外层任务和内层任务
为内层任务创建专门的线程池，与外层任务的线程池隔离

2. 合理配置线程池参数

通过调整线程池参数，可以降低死锁发生的概率：

适当增加核心线程数量，避免核心线程轻易被耗尽
合理设置队列容量，平衡内存占用和任务等待需求
根据任务特性调整最大线程数，确保有足够的线程处理突发任务

3. 避免不必要的同步等待

在设计任务时，尽量采用异步方式处理，避免使用get()等阻塞方法等待子任务完成：

使用CompletableFuture等异步编程工具，通过回调函数处理子任务结果
拆分任务流程，减少任务间的依赖关系

4. 增加监控与告警机制

为线程池添加监控，及时发现潜在的死锁风险：

监控线程池的活跃线程数、队列大小等指标
为任务执行设置超时时间，避免无限期等待
实现任务执行时间监控，对长时间运行的任务进行告警

监控实现代码参考：

public class MonitoredThreadPool extends ThreadPoolExecutor {
    
    // 1. 全局唯一的定时线程池：1个核心线程，空闲60秒关闭，避免资源占用
    private static final ScheduledExecutorService MONITOR_POOL = new ScheduledThreadPoolExecutor(
            1,  // 仅需1个核心线程，足够处理所有超时检查
            new ThreadFactory() {
                private final AtomicLong threadId = new AtomicLong(1);
                @Override
                public Thread newThread(Runnable r) {
                    Thread t = new Thread(r, "task-monitor-thread-" + threadId.getAndIncrement());
                    t.setDaemon(true); // 设为守护线程，避免阻塞JVM退出
                    return t;
                }
            },
            new ThreadPoolExecutor.DiscardPolicy() 
    );
    
    // 2. 记录任务开始时间
    private final Map<Runnable, Long> taskStartTimeMap = new ConcurrentHashMap<>();
    
    // 3. 可配置的超时阈值（单位：毫秒）
    private final long timeoutThreshold;

    public MonitoredThreadPool(int corePoolSize, int maximumPoolSize, long keepAliveTime,
                               TimeUnit unit, BlockingQueue<Runnable> workQueue, long timeoutThreshold) {
        super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);
        this.timeoutThreshold = timeoutThreshold;
    }

    @Override
    protected void beforeExecute(Thread t, Runnable r) {
        super.beforeExecute(t, r);
        // 记录当前任务的开始时间
        long startTime = System.currentTimeMillis();
        taskStartTimeMap.put(r, startTime);
        
        // 4. 提交超时检查任务到全局监控线程池（仅提交1次）
        MONITOR_POOL.schedule(() -> {
            // 检查任务是否仍在执行（未被afterExecute移除）
            Long start = taskStartTimeMap.get(r);
            if (start != null) {
                long duration = System.currentTimeMillis() - start;
                // 若执行时间超过阈值，触发告警（可扩展：打印堆栈、推送监控平台等）
                if (duration > timeoutThreshold) {
                    log.warn("任务执行超时！线程名：{}，任务类：{}，已执行：{}ms，超时阈值：{}ms",
                            t.getName(), r.getClass().getSimpleName(), duration, timeoutThreshold);
                    // 可选：若需强制终止任务，可调用thread.interrupt()（需业务支持中断）
                    // t.interrupt();
                }
            }
        }, timeoutThreshold, TimeUnit.MILLISECONDS); // 超时阈值后执行检查
    }

    @Override
    protected void afterExecute(Runnable r, Throwable t) {
        super.afterExecute(r, t);
        // 任务执行完成，移除开始时间（避免监控线程误判）
        taskStartTimeMap.remove(r);
    }

    // 5. 优雅关闭：业务线程池关闭时，同步关闭监控线程池
    @Override
    public void shutdown() {
        super.shutdown();
        // 若所有业务线程池都已关闭，关闭监控线程池（可根据实际场景调整，如全局监控可不关）
        if (isAllBusinessPoolShutdown()) {
            MONITOR_POOL.shutdown();
            try {
                // 等待监控线程池关闭，避免残留线程
                if (!MONITOR_POOL.awaitTermination(5, TimeUnit.SECONDS)) {
                    MONITOR_POOL.shutdownNow(); // 强制关闭未完成的监控任务
                }
            } catch (InterruptedException e) {
                MONITOR_POOL.shutdownNow();
                Thread.currentThread().interrupt(); // 保留中断状态
            }
        }
    }

    // 辅助方法：判断是否所有业务线程池都已关闭（根据实际业务场景实现）
    private boolean isAllBusinessPoolShutdown() {
        // 示例：若全局仅一个业务线程池，直接返回true；若多个，需维护列表判断
        return true;
    }
}