1. 事务原理与ACID特性
1.1 ACID原理
在数据库系统中，事务是一组要么全部执行、要么全部不执行的操作集合，ACID四个属性是其核心指标：原子性、一致性、隔离性、持久性。
其中，原子性保证单次事务要么完全执行，要么不改变数据库状态；一致性确保事务结束后数据库从一个合法状态转到另一个合法状态；隔离性防止并发事务之间相互干扰；持久性意味着提交后的数据变更在崩溃后也能保留。
1.2 事务边界与提交
设计良好的事务要有清晰的边界，提交操作将所有影响持久化到日志和数据页，确保数据在系统故障后仍能恢复到一致状态。
在设计接口层时，通常会把一个业务请求映射到一个事务边界中，因此需要在开始时明确关闭 autoCommit，在结束时显式执行 commit，遇到异常则执行 rollback。
2. JDBC与事务基础
2.1 JDBC事务的基本流程
在 JDBC 里，事务通过控制数据源提供的 Connection 的提交行为来实现；通常的流程是获取连接、设置 autoCommit 为 false、执行 SQL、调用 commit()，若出现异常则调用 rollback()，最后关闭连接。
本章围绕 Java 数据库事务原理与 JDBC 管理方法展开，解释从理论到实战的关键要点。
2.2 自动提交 vs 手动提交
默认情况下，JDBC 连接的 autoCommit 为 true，这意味着每条单独的 SQL 会被视作一个事务并立即提交；把 autoCommit 设置为 false，就可以将多条 SQL 组合成一个原子性事务。
在设计接口层时，通常会把一个业务请求映射到一个事务边界中，因此需要在开始时关闭自动提交，在结束时显式提交，出错时回滚。
Connection conn = null;
try {
conn = dataSource.getConnection();
conn.setAutoCommit(false); // 开启一个事务
// 执行多条 SQL
try (PreparedStatement ps1 = conn.prepareStatement("UPDATE account SET balance = balance - ? WHERE id = ?");
PreparedStatement ps2 = conn.prepareStatement("UPDATE account SET balance = balance + ? WHERE id = ?")) {
// ps1.executeUpdate(); ps2.executeUpdate();
}
conn.commit(); // 提交事务
} catch (SQLException e) {
if (conn != null) {
try { conn.rollback(); } catch (SQLException ex) { /* ignore */ }
}
} finally {
if (conn != null) try { conn.close(); } catch (SQLException ex) { /* ignore */ }
}
2.3 连接管理与关闭
避免直接在业务代码里频繁打开和关闭数据库连接，推荐采用 连接池（如 HikariCP、DBCP、C3P0）来统一管理连接生命周期，确保在事务边界内正确控制提交/回滚行为。
在使用连接池时，需要注意对每个事务的连接回收策略，以及在异常场景下保持连接状态的一致性；这也是监控与调优的关键环节。
3. 数据库隔离级别与锁
3.1 隔离级别的四个等级
数据库提供的 隔离级别决定了并发事务之间的可见性与冲突处理：READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READ、SERIALIZABLE。
不同数据库实现略有差异，但基本原则是：更高的隔离级别通常带来更高的并发成本和潜在的性能损耗；在大多数场景下选择 READ_COMMITTED 或 REPEATABLE_READ 可以获得较好的折中。
3.2 锁机制与死锁
并发事务之间的冲突通常通过锁来解决，锁粒度可能是行锁、表锁，死锁是一种常见的性能陷阱，简单场景下两个事务互相等待对方释放锁。
诊断死锁通常要查看数据库日志、以及对应用线程的等待状态进行分析；在代码层面，尽量缩小事务边界、避免长事务、以及采用合理的锁策略能降低死锁概率。
4. 常用事务管理策略与模式
4.1 悲观锁 vs 乐观锁
在高并发场景下，悲观锁假设冲突总是可能发生，因此在更新前直接锁定数据行；乐观锁假设冲突较少，通过 版本号、或者 CAS 等机制来检测冲突，冲突时再重试。
常见实现包括：使用数据库的行版本号列（如 version 字段）来执行“再提交”的重试逻辑，或者通过应用级的 CAS 操作来避免重复写入。
下面的示例演示一个典型的乐观锁更新场景，只有在版本号匹配时才会成功提交：
// 假设表 t 有字段 id, value, version
String sql = "UPDATE t SET value = ?, version = version + 1 WHERE id = ? AND version = ?";
try (Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement(sql)) {
ps.setInt(1, newValue);
ps.setInt(2, id);
ps.setInt(3, currentVersion);
int updated = ps.executeUpdate();
if (updated == 0) {
// 版本不匹配，说明被其他事务修改
throw new ConcurrentModificationException();
}
}
4.2 分布式事务概述与2PC/3PC
跨多个数据源或微服务的场景需要分布式事务，常见方案包括 两阶段提交（2PC）与 三阶段提交（3PC），以及基于 XA 协议的实现；在实际系统中，本地事务更易管理，但需要通过一个全局协调器来实现跨数据源的一致性。
2PC 的核心流程是：在第一阶段准备(prepare)阶段，参与者锁住资源并返回准备就绪；第二阶段提交提供全局提交，出现异常则进入回滚流程。
5. 使用JDBC管理方法的实战
5.1 使用连接池（HikariCP）配置事务相关参数
在生产环境中，连接池是提升 JDBC 事务管理性能的关键组件；以 HikariCP 为例，应该关注 minimumIdle、maximumPoolSize、以及 connectionTestQuery 等参数，确保在并发场景下事务边界内的连接可用。
另外，采用 数据源事务管理，避免在分布式场景下出现连接泄漏或跨线程的错误。
5.2 Spring事务管理与纯JDBC的对比
如果系统使用 Spring，可以通过 PlatformTransactionManager、TransactionTemplate 等抽象，统一管理事务；在纯 JDBC 场景中，必须显式完成 begin/commit/rollback 流程。
下面展示一个简化的 纯JDBC 场景的事务封装示例，用以提升代码可读性和错误处理的一致性：
public void transfer(long fromId, long toId, BigDecimal amount) throws SQLException {
try (Connection conn = dataSource.getConnection()) {
conn.setAutoCommit(false);
try (PreparedStatement psDebit = conn.prepareStatement("UPDATE account SET balance = balance - ? WHERE id = ?");
PreparedStatement psCredit = conn.prepareStatement("UPDATE account SET balance = balance + ? WHERE id = ?")) {
psDebit.setBigDecimal(1, amount);
psDebit.setLong(2, fromId);
psDebit.executeUpdate();
psCredit.setBigDecimal(1, amount);
psCredit.setLong(2, toId);
psCredit.executeUpdate();
}
conn.commit();
} catch (SQLException e) {
// 回滚并抛出异常
throw e;
}
}
6. 实践中的问题诊断与性能调优
6.1 常见问题：死锁诊断与解决
死锁往往来自不一致的访问顺序或事务持续时间过长；日常排查可以从数据库日志、等待事件以及应用日志中定位原因，必要时对业务逻辑重新设计事务边界。
尽量避免在一个事务中执行大量的 I/O 操作与慢查询，缩短事务生命周期，提高并发吞吐。
6.2 日志、慢查询与事务大小控制
开启数据库的 慢查询日志 与 执行计划 分析有助于找到瓶颈；在应用层，控制每个事务包含的 SQL数目 与 数据量，避免大事务造成锁竞争。
7. 实战案例简述
7.1 银行业务：并发转账事务
在银行场景中，账户余额的更新必须以原子方式执行，跨表或跨账户的一致性需要严格通过事务边界来保障；通过乐观锁和必要时的重试，可以降低死锁概率。
示例场景包括：扣减和记账、日志记录、以及风控标记的并发写入，所有步骤应在同一个事务中完成以确保原子性。
7.2 电商下单场景：分布式事务的必要性与实现
下单过程通常涉及库存扣减、订单写入、支付状态更新等多步操作，若分布式数据源，需要用到分布式事务的策略；在本地数据源下，合理的事务边界和锁策略也能显著提升系统鲁棒性。
