java事务回滚需显式控制连接生命周期、精准拦截业务异常并同步释放资源；必须禁用auto-commit、复用同一connection、catch所有异常类型并显式rollback，finally仅负责安全释放资源。

Java 中事务在异常发生时安全回滚，核心不是“自动感知异常”，而是**显式控制连接生命周期、精准拦截业务失败、同步释放关联资源**。关键在于事务边界与资源管理必须严格对齐，否则容易出现连接泄漏、部分提交或回滚失效。

确保同一 Connection 贯穿整个事务

MySQL 默认 auto-commit=true，每条 SQL 独立生效。要支持回滚，必须：

• 从数据源获取 Connection 后，立即调用 conn.setAutoCommit(false)
• 所有 SQL 操作（INSERT/UPDATE/DELETE）必须复用这一个 Connection 实例
• 禁止在 DAO 层各自取新连接——那样事务根本跨不了方法，也谈不上回滚
• 若用 HikariCP 等连接池，需确认其未开启“auto-commit override”等干扰配置

在 catch 块中显式 rollback，且覆盖业务异常

数据库不会因 Java 异常自动回滚。只捕获 SQLException 是不够的，因为多数业务异常（如余额不足、参数非法、唯一冲突）是你自己抛出的 RuntimeException 或自定义 Exception：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 在 try 块中执行全部业务逻辑
• catch 块应包含 BusinessException、RuntimeException、SQLException 等常见类型
• 进入 catch 后，先判空并检查 conn.isValid()，再调用 conn.rollback()
• rollback 本身可能抛 SQLException，建议单独包裹并记录 ERROR 日志，但不可吞掉
• 回滚后建议打 warn 日志，例如：log.warn("事务已回滚，原因：{}", e.getMessage())

finally 中只释放资源，不参与事务决策

commit 和 rollback 必须在 try/catch 分支内完成，finally 只做一件事：可靠释放资源，顺序和防护都要到位：

• 按反序 close：ResultSet → PreparedStatement → Connection
• 每个 close 都要判 null + 单独 try-catch，避免一个失败导致后续资源泄漏
• 调用 conn.close() 是归还连接池，不是物理关闭；可选调用 conn.setAutoCommit(true) 重置状态，防止连接被复用时残留 false 状态
• 不要在 finally 里 return 或 throw —— 会掩盖原始异常或返回值

更稳妥的做法：用 @Transactional 声明式管理

手动写 try-catch-rollback 容易遗漏细节（比如忘记 rollback、异常没捕获全、连接状态没重置）。Spring 的 @Transactional 能自动处理底层逻辑：

• 在 service 方法上加 @Transactional(rollbackFor = BusinessException.class)
• 抛出指定异常时，Spring 自动触发 rollback，且保证使用同一 Connection
• 注意：异常必须透出到代理层——不能在方法内 catch 后静默处理或仅返回错误码
• 若需条件性回滚（如余额不足但不想抛异常），可用 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南