如何优雅地监听ThreadPoolExecutor中每个任务的完成？这3种方案必须掌握

第一章：ThreadPoolExecutor 的完成回调

在 Java 并发编程中，ThreadPoolExecutor 提供了强大的线程池管理能力，但其原生 API 并未直接支持任务执行完成后的回调机制。为了实现任务完成时的自定义逻辑（如日志记录、结果处理或资源释放），开发者通常需要借助封装手段来实现回调功能。

使用 Future 和 Runnable 实现回调

一种常见方式是通过包装 Runnable 任务，在其 run() 方法执行前后插入回调逻辑。以下示例展示了如何在任务执行完成后触发回调：

public class CallbackRunnable implements Runnable {
    private final Runnable task;
    private final Runnable callback;

    public CallbackRunnable(Runnable task, Runnable callback) {
        this.task = task;
        this.callback = callback;
    }

    @Override
    public void run() {
        try {
            task.run(); // 执行原始任务
        } finally {
            callback.run(); // 无论成功或异常，均执行回调
        }
    }
}

上述代码中，CallbackRunnable 将原始任务与回调函数封装在一起，确保任务执行完毕后自动调用回调函数。

通过 CompletionService 管理异步结果

另一种更高级的方式是结合 ExecutorCompletionService 来监听任务完成事件。该机制将任务的完成顺序与提交顺序解耦，便于实时响应已完成的任务。

1. 创建 ThreadPoolExecutor 实例
2. 包装为 CompletionService
3. 提交任务并轮询或阻塞获取完成结果

方法	用途
submit()	提交任务并返回 Future
take().get()	获取第一个完成的任务结果

graph TD A[提交任务] --> B{任务执行中} B --> C[任务完成] C --> D[触发回调逻辑] D --> E[处理结果或清理资源]

第二章：继承 ThreadPoolExecutor 重写 afterExecute 方法

2.1 afterExecute 方法的执行机制与调用时机

在框架执行流程中，afterExecute 是控制器动作执行后自动触发的钩子方法，用于处理收尾逻辑，如日志记录、资源释放或响应包装。

调用时机分析

该方法在主业务逻辑（即控制器的具体动作）执行完毕后立即调用，但在响应发送到客户端之前执行，确保可对输出结果进行最后干预。

典型应用场景

• 记录请求处理耗时
• 清理临时上下文数据
• 统一设置响应头信息

public function afterExecute()
{
    // 记录执行时间
    $endTime = microtime(true);
    error_log("Action executed in " . ($endTime - $this->startTime) . " seconds");
    
    // 添加安全响应头
    header('X-Content-Type-Options: nosniff');
}

上述代码展示了如何在 afterExecute 中注入日志与安全头信息。参数无需显式传入，因该方法依赖类成员变量（如 $this->startTime）共享执行上下文。

2.2 通过重写 afterExecute 实现任务完成监听

在任务执行框架中，afterExecute 是一个关键的生命周期钩子方法，常用于执行任务完成后的清理或回调逻辑。通过重写该方法，可实现对任务状态的监听与响应。

扩展 afterExecute 方法

@Override
protected void afterExecute(Runnable r, Throwable t) {
    super.afterExecute(r, t);
    if (t == null && r instanceof Future) {
        try {
            ((Future<?>) r).get();
            System.out.println("任务执行成功");
        } catch (CancellationException ce) {
            System.out.println("任务被取消: " + ce);
        } catch (ExecutionException ee) {
            System.out.println("任务执行失败: " + ee.getCause());
        }
    } else {
        System.out.println("任务抛出异常: " + t);
    }
}

上述代码重写了 afterExecute，通过判断 Future 状态确定任务结果。若异常为 null，说明任务正常提交，进一步检查其执行结果；否则捕获实际异常并记录。

应用场景

• 日志记录：追踪任务生命周期
• 监控报警：发现异常任务及时通知
• 资源回收：释放任务占用的外部资源

2.3 异常情况下的回调处理与日志记录

在分布式系统中，网络波动或服务不可用可能导致回调失败。为保障最终一致性，需设计健壮的异常处理机制。

重试机制与退避策略

采用指数退避重试可有效缓解瞬时故障。以下为Go语言实现示例：

func doWithRetry(fn func() error, maxRetries int) error {
    for i := 0; i < maxRetries; i++ {
        if err := fn(); err == nil {
            return nil
        }
        time.Sleep(time.Duration(1 << i) * time.Second) // 指数退避
    }
    return errors.New("max retries exceeded")
}

该函数封装回调操作，最大重试maxRetries次，每次间隔呈指数增长，避免雪崩效应。

结构化日志记录

使用结构化日志便于问题追踪。关键字段应包含时间戳、请求ID、错误码和上下文信息：

字段	说明
timestamp	事件发生时间
request_id	关联分布式链路
error_code	标准化错误类型
context	附加调试信息

2.4 结合 Future 对象增强回调信息传递

在异步编程中，直接使用回调函数容易导致信息传递不完整或上下文丢失。通过引入 Future 对象，可以更有效地管理异步结果和状态。

Future 的基本作用

Future 作为一种占位符对象，代表尚未完成的计算结果，支持状态查询、结果获取和异常处理。

Future<String> future = executor.submit(() -> {
    Thread.sleep(1000);
    return "Task Done";
});
while (!future.isDone()) {
    System.out.println("等待任务完成...");
}
String result = future.get(); // 获取结果

上述代码中，submit() 返回一个 Future 对象，可通过 isDone() 判断任务是否完成，get() 阻塞获取最终结果。

与回调结合的优势

将 Future 与回调机制结合，可在任务完成时自动触发回调，并携带执行结果或异常信息，实现更完整的上下文传递。

• 统一异常处理路径
• 支持链式异步操作
• 提升代码可读性与维护性

2.5 实际应用场景示例：任务耗时监控

在分布式系统中，精确掌握任务执行时间对性能调优至关重要。通过引入高精度计时器，可实现对关键路径的毫秒级监控。

基础实现方式

使用Go语言内置的时间包记录起止时间戳：

startTime := time.Now()
// 执行业务逻辑
elapsed := time.Since(startTime)
log.Printf("任务耗时: %v", elapsed.Milliseconds())

上述代码通过 time.Now() 获取当前时间，time.Since() 计算耗时，单位为纳秒，转换为毫秒便于阅读。

监控指标分类

• 平均响应时间：反映系统整体性能趋势
• 95分位耗时：识别异常长尾请求
• 最大耗时：定位极端性能瓶颈

数据上报机制

客户端采集 → 指标聚合 → 异步上报 → 可视化展示

第三章：使用 CompletionService 管理异步任务结果

3.1 CompletionService 的设计原理与优势

任务提交与结果获取的解耦

CompletionService 的核心设计在于将任务的提交与结果的获取进行解耦。通过组合 ExecutorService 与阻塞队列，它能将已完成的任务结果按完成顺序放入队列，而非按提交顺序处理。

• 避免了 Future 列表轮询带来的延迟和资源浪费
• 提升响应速度，尤其在任务耗时差异较大时效果显著

典型实现：ExecutorCompletionService

ExecutorService executor = Executors.newFixedThreadPool(4);
CompletionService<String> completionService = new ExecutorCompletionService<>(executor);

for (int i = 0; i < 5; i++) {
    completionService.submit(() -> {
        Thread.sleep((long) (Math.random() * 1000));
        return "Task " + i + " done";
    });
}

for (int i = 0; i < 5; i++) {
    String result = completionService.take().get(); // 按完成顺序获取
    System.out.println(result);
}

上述代码中，completionService.take() 阻塞等待最先完成的任务结果，确保处理顺序与完成顺序一致，有效优化了任务调度效率。

3.2 基于 ExecutorCompletionService 的任务完成通知

在并发编程中，当需要获取多个异步任务的执行结果并按完成顺序处理时，ExecutorCompletionService 提供了高效的解决方案。它封装了线程池与阻塞队列，自动将已完成任务的结果放入队列，便于及时响应。

核心机制

ExecutorCompletionService 将任务提交到底层的 Executor，并通过一个共享的阻塞队列（如 LinkedBlockingQueue<Future<T>>）传递已完成任务的结果。调用者可使用 take() 或 poll() 实时获取最先完成的任务。

代码示例

ExecutorService executor = Executors.newFixedThreadPool(3);
ExecutorCompletionService<String> completionService = 
    new ExecutorCompletionService<>(executor);

for (int i = 0; i < 5; i++) {
    completionService.submit(() -> {
        Thread.sleep((long) (Math.random() * 2000));
        return "Task " + i + " completed";
    });
}

for (int i = 0; i < 5; i++) {
    String result = completionService.take().get(); // 按完成顺序获取
    System.out.println(result);
}

上述代码中，五个任务以随机耗时执行，completionService.take() 确保结果按实际完成顺序输出，而非提交顺序。该机制适用于爬虫抓取、批量接口调用等需快速响应先完成任务的场景。

3.3 批量任务场景下的高效结果获取实践

在处理大规模批量任务时，传统的同步等待模式会显著拖慢整体响应速度。为提升效率，推荐采用异步轮询与批量聚合机制。

异步结果轮询策略

通过提交任务后返回唯一ID，客户端周期性查询执行结果：

{
  "taskId": "batch_123",
  "status": "RUNNING",
  "progress": 0.75,
  "resultUrl": "/api/v1/results/batch_123"
}

该结构支持状态追踪与进度反馈，避免阻塞式等待。

批量结果聚合接口

使用统一接口批量拉取已完成任务结果，减少网络开销：

• 按时间窗口合并请求
• 启用压缩传输（如GZIP）
• 支持分页获取大结果集

结合缓存机制与指数退避重试策略，可进一步提升系统稳定性与吞吐能力。

第四章：封装 Runnable 和 Callable 实现回调注入

4.1 自定义 RunnableWrapper 实现任务包装与回调

在并发编程中，直接提交 Runnable 任务难以追踪执行状态。通过自定义 `RunnableWrapper`，可在任务执行前后插入监控、日志或回调逻辑。

核心设计思路

包装原始 Runnable，注入前置、后置行为，并支持成功/异常回调：

public class RunnableWrapper implements Runnable {
    private final Runnable task;
    private final Runnable onSuccess;
    private final Runnable onError;

    public RunnableWrapper(Runnable task, Runnable onSuccess, Runnable onError) {
        this.task = task;
        this.onSuccess = onSuccess;
        this.onError = onError;
    }

    @Override
    public void run() {
        try {
            task.run();
            if (onSuccess != null) onSuccess.run();
        } catch (Exception e) {
            if (onError != null) onError.run();
        }
    }
}

上述代码通过构造函数注入任务主体与回调逻辑，run() 方法中使用 try-catch 捕获异常，确保无论成功或失败都能触发对应回调，实现关注点分离。

典型应用场景

• 任务执行耗时监控
• 线程池任务失败告警
• 资源清理与状态更新

4.2 在 Callable 中嵌入完成通知逻辑

在并发编程中，`Callable` 接口允许返回计算结果并抛出异常。为了在任务完成时触发通知，可以将回调机制直接嵌入 `call()` 方法。

回调函数的集成方式

通过依赖注入将通知逻辑传入 `Callable` 实例，任务完成后主动调用外部监听器。

public class NotifyingTask implements Callable {
    private final NotificationService notifier;

    public NotifyingTask(NotificationService notifier) {
        this.notifier = notifier;
    }

    @Override
    public String call() throws Exception {
        String result = "Task completed";
        // 执行业务逻辑
        notifier.send("Processing finished: " + result);
        return result;
    }
}

上述代码中，`NotificationService` 作为完成通知的载体，在 `call()` 方法末尾执行发送操作，确保异步任务结束时及时通知外部系统。

• 任务成功执行后自动触发通知
• 解耦了计算逻辑与通知机制
• 支持多种通知渠道（邮件、消息队列等）

4.3 泛型化回调接口设计提升代码复用性

在复杂系统中，回调接口常用于解耦业务逻辑与执行流程。传统方式依赖具体类型定义回调方法，导致重复编码。通过引入泛型机制，可将输入与输出类型参数化，显著提升接口通用性。

泛型回调接口定义

public interface Callback<T, R> {
    R onSuccess(T result);
    void onError(Exception e);
}

该接口接受两个类型参数：T 表示成功返回的数据类型，R 表示处理后的结果类型。不同业务场景可通过指定不同类型组合复用同一接口。

实际应用场景

• 网络请求回调：Callback<HttpResponse, String>
• 数据库查询：Callback<ResultSet, List<User>>
• 文件处理：Callback<File, Boolean>

相同接口结构适配多种数据流处理，减少冗余类定义，增强代码可维护性。

4.4 避免内存泄漏：弱引用与资源清理策略

在长时间运行的应用中，内存泄漏会逐渐消耗系统资源，导致性能下降甚至崩溃。合理使用弱引用和及时释放资源是关键的预防手段。

弱引用的应用场景

弱引用允许对象在无强引用时被垃圾回收，适用于缓存、观察者模式等场景。例如，在 Go 中可通过 sync.WeakValueMap（模拟）避免持有对象过久：

var cache = make(map[string]**interface{}) // 使用指针的指针模拟弱引用
runtime.SetFinalizer(value, func(v *interface{}) {
    delete(cache, key) // 对象回收时清理缓存
})

上述代码通过设置终结器，在对象即将被回收时自动从缓存中移除对应条目，防止无效引用堆积。

资源清理的最佳实践

使用 defer 确保文件、连接等资源及时关闭：

file, _ := os.Open("data.txt")
defer file.Close() // 函数退出前自动调用

结合上下文超时控制，可进一步提升资源管理安全性。

第五章：总结与最佳实践建议

监控与日志的统一管理

在微服务架构中，分散的日志源增加了故障排查难度。建议使用集中式日志系统如 ELK 或 Loki 收集所有服务日志，并通过结构化日志输出提升可读性。

• 所有服务应使用统一的日志格式（如 JSON）
• 关键操作必须包含 trace ID 以便链路追踪
• 定期对日志进行索引优化以提升查询性能

配置热更新机制

避免因配置变更导致服务重启。可结合 Consul 或 Nacos 实现配置中心动态推送。

// Go 示例：监听配置变更
watcher, _ := configClient.Watch("service-a", "default")
for {
    select {
    case update := <-watcher:
        reloadConfig(update.Value)
    }
}

熔断与降级策略落地

为防止级联故障，应在客户端集成熔断器模式。Hystrix 或 Sentinel 是成熟选择。

场景	响应策略	超时设置
支付服务不可用	返回缓存订单状态	800ms
用户信息查询失败	降级为本地默认头像	500ms

自动化健康检查设计

Kubernetes 的 liveness 和 readiness 探针应结合业务逻辑定制。例如数据库连接、缓存可用性等都应纳入检测范围。

请求到达 → 检查数据库连接 → 验证 Redis 可用性 → 返回 HTTP 200/503