要保留被拒任务的原始异常链，需在提交前用包装器封装任务并捕获异常，再通过自定义RejectedExecutionHandler提取并记录任务上下文与异常信息。
Java线程池拒绝策略（如 AbortPolicy、CallerRunsPolicy 等）触发时，默认不会保留被拒绝任务的执行上下文或原始异常信息。若任务本身在执行中抛出异常，而该任务又因队列满/线程数达上限被拒绝，原始异常就丢失了。要保留原始任务及其可能携带的异常链，关键不是“在线程池拒绝时捕获任务异常”，而是**在任务提交前主动封装任务，使其异常可追溯，并在拒绝时通过自定义策略将任务和异常信息一并记录或传播**。
用 Runnable/Callable 包装器捕获并携带原始异常
在提交任务前，不直接提交裸任务，而是用一个能记录堆栈、异常、时间戳的包装器封装：
- 对
Runnable：使用匿名内部类或 Lambda 捕获执行时的Throwable，并存入ThreadLocal或随任务对象一起保存； - 对
Callable<V>：更自然，可在call()中 try-catch，将原始异常作为包装异常的 cause 封装； - 示例（Callable 包装）：
Callable<String> original = () -> {
if (Math.random() > 0.5) throw new IllegalArgumentException("task failed");
return "ok";
};
Callable<String> wrapped = () -> {
try {
return original.call();
} catch (Exception e) {
throw new RuntimeException("Wrapped task execution failed", e);
}
};
这样，即使任务未被执行（被拒绝），你仍可在拒绝策略中拿到这个 wrapped 对象——它本身不执行，但它的 toString()、字段或自定义元数据可反映原始意图。
实现自定义 RejectedExecutionHandler 保留任务引用与上下文
标准拒绝策略（如 AbortPolicy）只抛出 RejectedExecutionException，不暴露任务对象。你需要实现 RejectedExecutionHandler，并在拒绝时做三件事：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 接收
Runnable参数（即被拒任务）； - 若该任务是前述包装类型，尝试强转并提取原始异常、提交时间、业务 ID 等；
- 将任务 + 异常链记录到日志、发送告警，或抛出带完整 cause 链的新异常（如
new RejectedTaskException("task rejected", originalCause)）；
public class LoggingRejectedHandler implements RejectedExecutionHandler {
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
if (r instanceof TracedTask) {
TracedTask task = (TracedTask) r;
log.warn("Task rejected: {} with exception", task.getDesc(), task.getRootCause());
// 可选：重新抛出含链式异常的自定义异常（需调用方 try-catch）
throw new RejectedTaskException("Task rejected", task.getRootCause());
}
// fallback
throw new RejectedExecutionException(
"Task " + r.toString() + " rejected from " + executor);
}
}
配合 ThreadFactory 记录任务提交线程与时间
仅靠拒绝策略还不够——你可能还想知道“谁提交了这个任务”。在创建线程池时传入自定义 ThreadFactory，并在任务提交时（如通过 submit() 或 execute()）利用 Thread.currentThread().getStackTrace() 快照调用栈：
- 把栈信息存入任务包装器的字段（如
submitStack）； - 拒绝时一并打印，就能定位到哪行代码触发了过载；
- 注意避免过度采集（如只取前 5 层业务栈），防止性能损耗；
慎用“重试提交”代替异常链保留
有些方案建议在拒绝策略中把任务重新 execute() 到另一个备份线程池——这看似“保留了任务”，实则掩盖问题且易引发雪崩。真正需要的是可观测性：明确知道哪个任务、因何原因、在何时被拒。异常链的价值在于诊断，而非自动恢复。所以优先选择记录 + 告警 + 上报，而非静默重试。
