jdbc事务通过connection api协同数据库引擎保障acid：原子性靠setautocommit(false)、commit/rollback显式控制；一致性依赖数据库约束与业务逻辑校验；隔离性由settransactionisolation()设定级别；持久性由数据库日志机制（如redo log）保证。
JDBC 事务本身不直接“实现”ACID，而是通过 JDBC API 提供的机制，配合数据库自身的事务支持，来保障ACID 特性。关键在于正确使用 Connection 的控制能力，并确保数据库引擎支持事务（如 MySQL 的 InnoDB，而非 MyISAM）。
原子性（Atomicity）：要么全成功，要么全回滚
通过 Connection.setAutoCommit(false) 关闭自动提交，把多个 SQL 操作纳入同一事务上下文；执行完所有操作后调用 commit()；一旦中间出错（比如 SQLException），立即调用 rollback()。
- 必须显式捕获异常并触发 rollback，否则连接可能一直持有未提交状态
- 避免在 try 块中只 commit、不处理 rollback —— 推荐用 try-with-resources + 显式 finally 或 try-catch-finally 确保 rollback 执行
- 示例场景：转账操作中，扣款和入账必须同属一个事务，任一失败则全部撤销
一致性（Consistency）：依赖业务逻辑 + 数据库约束
JDBC 不负责校验业务规则，但能配合数据库维持数据层面的一致性：
- 外键、唯一索引、CHECK 约束等由数据库强制执行，JDBC 执行 DML 后若违反会抛出 SQLException，触发 rollback
- 应用层需在事务内完成逻辑检查（如余额是否充足），并在检查失败时主动 rollback
- 注意：隔离级别也会影响一致性表现（例如脏读可能导致临时不一致）
隔离性（Isolation）：靠 setTransactionIsolation() 控制并发行为
通过 Connection.setTransactionIsolation(int level) 设置事务隔离级别，影响多个事务并发执行时的可见性规则：
-
TRANSACTION_READ_UNCOMMITTED：最低级别，允许脏读 -
TRANSACTION_READ_COMMITTED：大多数数据库默认（如 Oracle、SQL Server），防止脏读 -
TRANSACTION_REPEATABLE_READ：MySQL InnoDB 默认，防止脏读和不可重复读 -
TRANSACTION_SERIALIZABLE：最高级别，完全串行化，但性能开销大 - 设置需在
setAutoCommit(false)之后、执行 SQL 之前完成
持久性（Durability）：由数据库日志和刷盘机制保证
JDBC 层面无法直接控制磁盘写入，但可通过以下方式增强持久性保障：
- 确保 commit() 调用成功返回后，数据库已将事务日志（如 InnoDB 的 redo log）刷入磁盘
- 部分数据库提供同步刷盘参数（如 MySQL 的
innodb_flush_log_at_trx_commit=1），这是真正实现持久性的基础 - JDBC 驱动一般会等待数据库确认 commit 完成才返回，因此应用只需正确调用 commit 并处理异常即可
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
