Java长事务超时处理需区分数据库、JDBC、应用层及协调器四类超时来源，精准捕获对应异常，在事务边界内立即上报协调器并主动回滚，确保资源释放与状态同步。
Java 中长事务捕获超时异常并通知分布式协调器，核心在于：明确超时来源、精准捕获 TimeoutException（或框架特定超时异常）、主动释放资源、同步上报状态。这不是单纯 try-catch 能解决的，需结合事务生命周期与协调器通信机制。
识别真实的超时异常来源
长事务中“超时”可能来自不同层级，需区分处理：
-
数据库事务超时：如 MySQL 的
wait_timeout、PostgreSQL 的idle_in_transaction_session_timeout，通常抛出SQLException（非TimeoutException），需解析 SQLState 或错误码（如 MySQL 的HY000+ “Lock wait timeout exceeded”） -
JDBC 连接/语句超时：通过
Statement.setQueryTimeout()触发，抛出SQLTimeoutException（SQLException子类） -
应用层任务超时：使用
Future.get(timeout, unit)、CompletableFuture.orTimeout()等，抛出标准java.util.concurrent.TimeoutException -
分布式事务协调器超时：如 Seata、Atomikos、Narayana 在全局事务未在指定时间内完成时主动回滚，并可能抛出
TransactionTimeoutException等自定义异常
在事务边界内捕获并上报
不能等到事务提交后才处理超时——此时可能已无法回滚。必须在执行关键操作（如远程调用、批量写入）时就设置超时，并立即响应：
- 对每个可能阻塞的外部依赖（HTTP 客户端、RPC、消息发送）单独设置超时，并捕获对应异常
- 在 catch 块中：记录完整上下文日志（traceId、事务XID、操作名、耗时）
- 调用分布式协调器客户端 API 主动上报超时事件，例如：
BranchRollbackRequest request = new BranchRollbackRequest();
request.setXid(xid);
request.setBranchId(branchId);
request.setResourceId("jdbc:mysql://...");
request.setApplicationData("timeout_at_20260721T053800Z");
seataRemotingClient.send(request); // 异步上报，避免阻塞主流程
确保事务可安全终止
捕获超时后，若事务尚未提交，必须防止“悬挂事务”：
立即学习“Java免费学习笔记（深入）”；
- 显式调用
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()（Spring）或UserTransaction.setRollbackOnly()（JTA） - 关闭所有打开的 JDBC 连接、流、HTTP 客户端连接池连接
- 若使用异步任务（如
@Async），确保线程池支持中断，并在超时时调用future.cancel(true) - 避免在 finally 中执行可能再次超时的操作（如重试上报）；上报失败应降级为本地日志+告警
与协调器约定超时通知协议
协调器需能识别并响应应用上报的超时信号，建议统一约定：
- 上报字段包含：
xid（全局事务 ID）、branchId（分支 ID）、timeoutMs、timestamp、stackTrace（截断）、service（当前服务名） - 协调器收到后，应标记该分支为
TIMEOUT_ROLLBACK，触发自动回滚或人工介入流程 - 应用侧上报应带重试机制（最多 2 次），失败则写入本地补偿表，由定时任务兜底同步
