应选callable而非runnable，因其可返回账务数据、原样抛出分类异常（如超时/sql错误/空响应）、支持future.get(timeout)超时控制，避免单点拖垮对账流。
在分布式对账系统中，多源数据并行提取是性能瓶颈的关键环节。用 Callable 实现可返回结果、可抛异常、可被线程池调度的任务，比 Runnable 更适合对账场景——比如从 MySQL、Oracle、Hive、HTTP 接口等不同源头同时拉取某日账务快照，再汇总比对。
为什么选 Callable 而不是 Runnable？
对账任务天然需要“结果”和“错误上下文”：
-
必须返回数据：比如从各库查出的交易明细 List
，Runnable 没有返回值，得靠外部容器收集，易出竞态 - 需区分失败类型：网络超时、SQL 报错、空响应、格式解析异常……Callable 配合 Future.get() 可原样抛出，便于统一兜底或重试
- 支持超时控制：Future.get(30, TimeUnit.SECONDS) 可防某个数据源拖垮整个对账流
一个真实可用的多源 Callable 模板
以下是一个生产级可复用的抽象基类（Java 8+），已剥离业务细节，聚焦并发安全与可观测性：
public abstract class DataSourceCallable<t> implements Callable<extractionresult>> {
protected final String sourceName;
protected final LocalDate businessDate;
protected final long timeoutMs;
<pre class="brush:java;toolbar:false;">public DataSourceCallable(String sourceName, LocalDate businessDate, long timeoutMs) {
this.sourceName = sourceName;
this.businessDate = businessDate;
this.timeoutMs = timeoutMs;
}
@Override
public ExtractionResult<T> call() throws Exception {
long start = System.currentTimeMillis();
try {
T data = doExtract(); // 子类实现具体拉取逻辑
long cost = System.currentTimeMillis() - start;
return ExtractionResult.success(sourceName, data, cost);
} catch (Exception e) {
long cost = System.currentTimeMillis() - start;
return ExtractionResult.failure(sourceName, e, cost);
}
}
protected abstract T doExtract() throws Exception;
// 内部结果包装类（含源标识、数据、耗时、异常）
public static class ExtractionResult<R> {
public final String source;
public final R data;
public final long elapsedMs;
public final Exception error;
private ExtractionResult(String source, R data, long elapsedMs, Exception error) {
this.source = source;
this.data = data;
this.elapsedMs = elapsedMs;
this.error = error;
}
public static <R> ExtractionResult<R> success(String source, R data, long elapsedMs) {
return new ExtractionResult<>(source, data, elapsedMs, null);
}
public static <R> ExtractionResult<R> failure(String source, Exception e, long elapsedMs) {
return new ExtractionResult<>(source, null, elapsedMs, e);
}
public boolean isSuccess() { return error == null; }
}
}
说明：
- 所有子类只需实现 doExtract()，专注单数据源逻辑，不感知线程、超时、包装
- ExtractionResult 统一封装成功/失败状态，含耗时和异常，方便后续做 SLA 统计或告警
- 构造时传入 businessDate，避免子类硬编码日期，利于测试和回溯
四个典型子类示例（开箱即用）
每个子类代表一种常见对账源，体现如何适配不同协议和异常语义：
- MySqlTradeCallable：用 JdbcTemplate 查 t_trade 表，捕获 DataAccessException 并转为业务异常
- HivePartitionCallable：调用 Hive JDBC 执行 SELECT … WHERE ds=‘20240520’，超时设为 120s，空结果视为成功（分区存在但无数据）
- HttpLedgerApiCallable：用 OkHttp 调账务中心 HTTP 接口，校验 HTTP status=200 + 响应体非空，JSON 解析失败单独捕获
- OracleReconCallable：用 Oracle UCP 连接池执行 PL/SQL 函数，显式处理 ORA-01403（无数据）作为正常分支，其他 ORA 错误抛出
关键点：各子类只管“怎么拿”，不管“谁来调”。异常分类清晰，不把连接超时和业务空数据混为一谈。
并行提交与结果聚合实战写法
别直接用 Executors.newFixedThreadPool —— 对账流需可控、可观测、可熔断：
// 1. 构建带监控的线程池（推荐使用 Hystrix 或自定义 ThreadPoolExecutor）
ThreadPoolExecutor executor = new ThreadPoolExecutor(
8, 16, 60L, TimeUnit.SECONDS,
new LinkedBlockingQueue(100),
r -> new Thread(r, "recon-extract-" + UUID.randomUUID()),
new ThreadPoolExecutor.CallerRunsPolicy() // 队列满时由主线程执行，防雪崩
);
<p>// 2. 提交全部 Callable（假设已有 4 个数据源实例）
List<datasourcecallable>> tasks = Arrays.asList(
new MySqlTradeCallable("mysql_primary", date, 30_000),
new HivePartitionCallable("hive_dwd", date, 120_000),
new HttpLedgerApiCallable("ledger_api", date, 15_000),
new OracleReconCallable("oracle_hist", date, 45_000)
);</datasourcecallable></p><p>// 3. 批量提交，获取 Future 列表
List<future>>> futures = executor.invokeAll(tasks, 180, TimeUnit.SECONDS);</future></p><p>// 4. 收集结果（注意：invokeAll 已按 task 顺序返回 future，保持对应关系）
List<extractionresult>> results = new ArrayList();
for (Future<extractionresult>> future : futures) {
try {
results.add(future.get()); // 此处 get 不会阻塞，invokeAll 已完成或超时
} catch (ExecutionException e) {
results.add(ExtractionResult.failure("unknown", e.getCause(), 0));
}
}</extractionresult></extractionresult></p><p>// 5. 后续：统计成功率、过滤失败项、触发告警、组装对账输入...
executor.shutdown();</p>提示：
- invokeAll + timeout 是关键：它确保整体等待不超过 180 秒，哪怕个别 future 还没返回
- Future.get() 在 invokeAll 后调用是安全的，不会再次阻塞；若 invokeAll 因超时返回，对应 future 的 get() 会立即抛 CancellationException
- 务必 shutdown 线程池，尤其在 Spring Boot 的 CommandLineRunner 中，否则应用无法优雅退出
不复杂但容易忽略：Callable 本身只是接口，真正让对账变稳的是结构化异常处理、明确的超时分层、结果归一化封装，以及线程池策略与业务 SLA 对齐。写一次通用基类，后面新增数据源只需 20 行代码。
