非事务性资源不能依赖事务管理器自动关闭，必须显式释放；其生命周期不得跨越事务边界，关闭逻辑须与事务成败解耦；推荐在事务外创建并用try-with-resources关闭，或传参至事务方法中仅使用；若必须在事务内创建，需用try-finally确保关闭且捕获close异常；全局资源应交由Spring容器管理销毁。
在 Java 的事务管理中，非事务性资源（如文件流、HTTP 连接、手动创建的数据库连接、第三方 SDK 客户端等）**不能依赖事务管理器自动关闭**，必须显式、及时、安全地释放。关键原则是：**资源生命周期不应跨越事务边界，且关闭逻辑必须与事务成败解耦**。
避免在事务方法内直接 new 资源并延迟关闭
常见错误是在 @Transactional 方法里打开资源，却把 close() 放在方法末尾或 finally 块中——看似稳妥，实则隐患很大：
- 若事务回滚后抛出异常（如
RuntimeException），finally仍会执行，但此时资源可能已处于不可用或半关闭状态； - 若资源关闭本身抛异常（如网络超时、IO 错误），会覆盖原始事务异常，掩盖真正问题；
- Spring 事务拦截器在方法返回后才提交/回滚，而资源若持有外部状态（如长连接、锁），可能在事务真正结束前就被释放，导致不一致。
推荐做法：在事务外准备，在事务内仅使用
将资源的创建和关闭严格限定在事务作用域之外，事务方法只负责“使用”，不负责“拥有”：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 用
try-with-resources在调用方（如 Controller 或 Service 非事务方法）中创建并自动关闭资源； - 将资源实例作为参数传入
@Transactional方法，该方法只读/写，不 close； - 例如处理上传文件并保存数据库：先在 Controller 中用
MultipartFile.getInputStream()获取流，用try包裹整个业务流程（含事务方法调用），流在try结束时关闭；事务方法只接收InputStream并解析内容、存库。
必须关闭时：用独立 try-catch + finally 确保释放
如果资源不得不在事务方法内创建（如调用某 SDK 必须在业务逻辑中初始化客户端），请按以下方式处理：
立即学习“Java免费学习笔记（深入）”；
- 立即声明资源变量，紧随创建后用
try-finally包裹使用逻辑； -
finally中只做关闭，且对close()异常进行捕获并记录（不抛出），避免干扰事务控制流； - 不要在
catch中关闭——异常可能发生在使用阶段，资源未必已成功初始化； - 示例：
Resource res = null;
try {
res = new Resource();
// 执行业务操作（含 DB 操作）
} finally {
if (res != null) {
try { res.close(); } catch (Exception e) { log.warn("close failed", e); }
}
}
利用 Spring 的 DisposableBean 或 @PreDestroy（适用于单例资源）
对于复用性强、全局共享的非事务资源（如 HTTP 客户端、消息生产者），应设计为 Spring Bean，并实现资源清理契约：
- 声明为
@Scope("singleton")，在配置类中通过@Bean(destroyMethod = "close")指定销毁方法； - 或实现
DisposableBean接口，重写destroy()； - 确保这些资源本身不绑定到某次事务，其生命周期由 Spring 容器管理，与事务完全隔离。
