Skip to main content

23小节：通过回调函数实现线程池任务防丢失功能

作者：程序员马丁

在线博客：https://nageoffer.com

note

热门项目实战社群，收获国内众多知名公司面试青睐，近千名同学面试成功！助力你在校招或社招上拿个offer。

通过回调函数实现线程池任务防丢失功能，元数据信息：

©版权所有 - 拿个offer-开源&项目实战星球专属学习项目，依据《中华人民共和国著作权法实施条例》和《知识星球产权保护》，严禁未经本项目原作者明确书面授权擅自分享至 GitHub、Gitee 等任何开放平台。违者将面临法律追究。

内容摘要：本文深入介绍 oneThread 动态线程池框架的优雅关闭机制实现，重点阐述任务保护策略、Spring 生命周期集成和自动销毁机制的架构设计。通过重写 shutdown() 方法、等待终止机制和 Bean 销毁回调，实现了线程池关闭时的任务安全保障，为生产环境提供了可靠的服务停机解决方案。

课程目录如下所示：

  • 前言
  • 传统线程池关闭的痛点分析
  • oneThread 优雅关闭机制设计
  • shutdown() 方法重写实现
  • Spring Bean 声明周期集成
  • 自动销毁机制深度解析
  • 文末总结

前言​

在微服务架构盛行的今天，服务的优雅停机已经成为生产环境稳定性的重要指标。想象一下这样的场景：

凌晨 3 点，你需要发布一个紧急修复版本。当你执行项目重启 kubectl rollout restart 命令时，Kubernetes 会向旧的 Pod 发送 SIGTERM 信号，给它 30 秒的时间来优雅关闭。但是，如果此时线程池中还有 200 个正在处理的订单任务，传统的线程池会直接丢弃这些任务，导致订单状态异常、用户投诉，甚至可能引发资金问题。

这就是传统线程池在服务停机时面临的任务丢失风险。虽然这种情况在开发环境中很难察觉，但在生产环境的高并发场景下，任何一次不优雅的停机都可能造成业务损失。

传统的 ThreadPoolExecutor 在调用 shutdown() 方法时，虽然会停止接收新任务，但对于队列中的待执行任务和正在执行的任务，处理方式相对"粗暴"。队列中的任务倒是会继续执行完毕，这点还算友好，但正在执行的任务如果执行时间较长，就可能会被强制中断。更要命的是，它没有合理的等待机制，很容易造成任务丢失。

更关键的是，在 Spring 应用中，开发者往往会忘记手动调用线程池的 shutdown() 方法，导致应用关闭时线程池资源无法正确释放。

大家可以看看，你所在项目中，线程池有没有优雅关闭。如果没有，恭喜你中奖了～

oneThread 框架通过重写 shutdown() 方法和 Spring 生命周期集成，彻底解决了这些问题。它确保所有任务都有足够的时间完成执行，结合 Spring 的销毁机制实现自动触发，无需手动调用。同时支持自定义等待时间，在任务完整性和停机速度之间找到平衡。即使超时了，也会记录警告日志，但不会无限等待下去。

本文将深入解析 oneThread 框架优雅关闭机制的设计思路和实现细节，帮你构建更加稳定可靠的线程池管理方案。

传统线程池关闭的痛点分析​

1. 任务丢失风险​

传统的 ThreadPoolExecutor 在关闭时存在明显的任务丢失风险：

// 传统线程池的关闭方式
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    5, 10, 60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(100)
);

// 提交一些长时间运行的任务
for (int i = 0; i < 50; i++) {
    executor.submit(() -> {
        try {
            // 模拟业务处理，需要 5 秒
            Thread.sleep(5000);
            System.out.println("任务完成: " + Thread.currentThread().getName());
        } catch (InterruptedException e) {
            System.out.println("任务被中断: " + Thread.currentThread().getName());
        }
    });
}

// 应用关闭时直接调用 shutdown
executor.shutdown();
// 问题：如果任务执行时间超过 JVM 关闭时间，任务会被强制终止

这里的问题很明显。首先是时间竞争问题，JVM 关闭和任务执行之间存在时间竞争，任务可能来不及完成就被强制终止了。其次是资源浪费，已经投入的计算资源和业务逻辑处理可能前功尽弃。最严重的是数据一致性问题，对于涉及数据跑批等任务，强制中断可能导致数据不一致。

2. 手动管理的复杂性​

在 Spring 应用中，正确管理线程池的生命周期需要开发者手动处理：

@Component
public class TaskService {
    
    private ThreadPoolExecutor executor;
    
    @PostConstruct
    public void init() {
        executor = new ThreadPoolExecutor(
            5, 10, 60L, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(100)
        );
    }
    
    @PreDestroy
    public void destroy() {
        // 开发者需要记住手动关闭
        if (executor != null && !executor.isShutdown()) {
            executor.shutdown();
            try {
                // 需要手动实现等待逻辑
                if (!executor.awaitTermination(30, TimeUnit.SECONDS)) {
                    executor.shutdownNow();
                    if (!executor.awaitTermination(10, TimeUnit.SECONDS)) {
                        System.err.println("线程池无法正常关闭");
                    }
                }
            } catch (InterruptedException e) {
                executor.shutdownNow();
                Thread.currentThread().interrupt();
            }
        }
    }
}

这种手动管理方式的复杂性主要体现在几个方面。每个使用线程池的组件都需要编写类似的销毁逻辑，产生大量样板代码。开发者很容易忘记添加 @PreDestroy 方法，导致资源泄漏。而且需要正确处理 InterruptedException，逻辑复杂且容易出错。等待时间的设置还需要根据业务场景调优，缺乏统一标准。

除了这种还有其他初始化和销毁方法，这里仅为举例说明。

除此之外，传统线程池在关闭过程中缺乏必要的监控和日志记录：

// 传统方式缺乏关闭过程的可观测性
executor.shutdown();
// 无法知道：
// - 关闭过程是否顺利？
// - 有多少任务被中断？
// - 等待了多长时间？
// - 是否存在资源泄漏？

这种"黑盒"式的关闭过程给生产环境的问题排查带来了困难。

oneThread 优雅关闭机制设计​

oneThread 的优雅关闭机制采用了分层设计的思路，整个架构可以用下面的图来表示：

在设计 oneThread 的优雅关闭机制时，我们遵循了几个核心原则：

  • 任务优先原则：我们优先保证已提交任务的完整执行，为任务完成提供合理的等待时间，避免因系统关闭导致的业务数据不一致。

  • 可配置性原则：支持自定义等待终止时间，允许不同线程池使用不同的关闭策略，提供环境相关的配置能力。

  • 可观测性原则：完整记录关闭过程的关键信息，提供关闭状态的实时反馈，支持关闭过程的监控和告警。

  • 自动化原则：与 Spring 生命周期无缝集成，无需开发者手动管理线程池关闭，减少样板代码和人为错误。

在技术选型上，我们做了几个重要的决定：

解锁付费内容，👉 戳​

Table of Contents