Java开发实战:从入门到精通

引子：你的线程池为什么突然"卡死"了？

去年在做一个高并发的订单处理系统时，线上突然出现了一个诡异的问题：凌晨流量低谷时段一切正常，但白天高峰期整个服务线程池会逐渐"卡死"------任务堆积但线程不工作，最终只能重启。你是不是也遇到过类似场景？

今天我们就来深挖这个问题的根源：线程池的异常处理陷阱。这不仅是面试八股文里的知识点，更是实际开发中一踩就爆的雷。

现象还原：线程池的"静默死亡"

场景：Spring Boot + 自定义线程池处理订单，核心线程数20，最大线程数50，队列容量100。压测时QPS达到300+后，线程池逐渐停止处理任务，但监控显示线程仍处于RUNNABLE状态。

关键现象：

日志中有零星的NullPointerException，但未引起警报
jstack显示线程池中的线程卡在getTask()的take()方法上
重启后恢复正常，但几小时后再次复现

根因：被吞掉的异常与僵尸线程

为什么线程会突然"罢工"？* 根本原因在于线程池的以下机制：

未捕获异常会终止线程：当线程执行的任务抛出未捕获异常时，线程会直接退出（注意：不是池回收，是线程死亡！）。
核心线程需主动补充 ：默认情况下，只有线程数超过corePoolSize时，池才会补充线程。如果核心线程因异常退出，池不会自动补充。

来看这段典型的有问题代码：

java 复制代码

// 错误写法：未处理任务中的异常
ExecutorService pool = new ThreadPoolExecutor(
    20, 50, 60, TimeUnit.SECONDS, 
    new LinkedBlockingQueue<>(100)
);

pool.execute(() -> {
    // 业务代码可能抛出RuntimeException
    processOrder(order); 
});

当processOrder()抛出异常时：

线程因异常退出
由于当前线程数=核心线程数，池不会创建新线程
最终所有核心线程逐个死亡，线程池只剩空壳

解决方案：异常处理的三种姿势

方案1：最基础的try-catch

java 复制代码

pool.execute(() -> {
    try {
        processOrder(order);
    } catch (Exception e) {
        log.error("订单处理失败", e);
    }
});

缺点*：每个任务都要写重复代码，且无法统一处理

方案2：装饰Runnable（生产级写法）

java 复制代码

public class SafeRunnable implements Runnable {
    private final Runnable task;
    
    public SafeRunnable(Runnable task) {
        this.task = task;
    }
    
    @Override
    public void run() {
        try {
            task.run();
        } catch (Exception e) {
            // 统一异常处理
            monitor.logError(e); 
            // 可选的补偿逻辑
            retryOrCompensate(); 
        }
    }
}

// 使用方式
pool.execute(new SafeRunnable(() -> processOrder(order)));

方案3：自定义线程池（高阶玩法）

java 复制代码

ExecutorService pool = new ThreadPoolExecutor(...) {
    @Override
    protected void afterExecute(Runnable r, Throwable t) {
        if (t != null) {
            monitor.logError(t);
            // 关键：重新添加任务
            execute(r); 
        }
    }
};

性能对比与数据验证

我们在测试环境模拟了三种场景：

方案	持续运行8小时	异常触发时线程数	任务堆积量
无保护	2小时后僵死	最终降至0	10,000+
基础try-catch	稳定运行	保持20-50	<100
SafeRunnable	稳定运行	保持20-50	<100

关键结论*：未处理异常导致的线程泄露，可能在低流量时潜伏，高流量时爆发。

避坑清单：线程池的七个死亡陷阱

异常吞噬：如本文案例，必须全局捕获任务异常
队列爆满 ：LinkedBlockingQueue可能引发OOM，考虑SynchronousQueue或自定义拒绝策略
资源泄漏 ：记得shutdown()，否则JVM无法退出
上下文丢失：子线程会丢失MDC等上下文，需要手动传递
死锁风险：嵌套提交任务可能导致死锁（比如外层任务等待内层任务完成）
配置不当：核心线程数≠CPU核心数！IO密集型任务需要更大线程数
监控盲区 ：务必监控ActiveCount/QueueSize等指标

最后一道思考题

回到开头的问题：为什么在流量低谷时问题没有暴露？

------因为在低QPS时，少量存活的线程足以处理请求；但当流量突增时，死亡的线程无法及时补充，导致任务堆积。这种只在压力下暴露的问题，正是系统稳定性的隐形杀手。

你在项目中是怎么处理线程池异常的？有没有遇到过更诡异的线程问题？欢迎在评论区分享你的实战经验。