Java事务管理需深入理解ACID特性：原子性依赖Spring AOP代理与异常传播机制；一致性需应用逻辑与DB约束协同；隔离级别应按场景选型而非盲目提升；持久性保障需合理配置超时、传播行为及异步事务上下文。
Java事务管理不是加个@Transactional就完事，它背后是ACID特性的落地支撑，更是生产环境里数据一致性的最后一道防线。真正用好事务，得从特性理解、Spring机制、隔离冲突、到性能瓶颈逐层穿透。
原子性：不是“写了代码”就算原子，而是“失败能干净回滚”
原子性不是指代码写在一起，而是指数据库层面的回滚能力可覆盖全部操作。Spring靠AOP代理+TransactionInterceptor拦截方法，在异常时触发rollback()，但有几个关键前提：
- 异常必须抛出到事务切面能捕获的层级——默认只对
RuntimeException和Error回滚，受检异常需显式配置rollbackFor = Exception.class - 同一类内方法自调用（比如
createOrder()里直接调updateStock()）会导致@Transactional失效，因为代理对象没被调用 - 非Spring管理的对象（如new出来的service）、或手动try-catch吞掉异常，都会绕过事务控制
一致性：靠约束+逻辑双重保障，不单靠事务本身
事务不保证业务一致性，只保证数据库约束不被破坏。比如转账总额不变，是靠应用层校验+数据库外键/唯一索引/检查约束共同实现的：
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- 扣库存前查余额是否充足，是应用一致性逻辑；数据库设
CHECK (stock >= 0)是DB层兜底 - 避免幻读导致的重复下单，不能只靠事务，要配合
SELECT ... FOR UPDATE或分布式锁 - DDL语句（如
ALTER TABLE）在MySQL中会隐式提交当前事务，执行前务必确认无未提交操作
隔离性：选对级别，比盲目上SERIALIZABLE更重要
隔离级别不是越高越好。READ_COMMITTED是MySQL InnoDB默认值，已能解决脏读；REPEATABLE_READ可防不可重复读，但幻读仍存在；SERIALIZABLE虽强，但性能损耗大，且可能引发大量锁等待。
立即学习“Java免费学习笔记（深入）”；
- 高并发查+改场景（如秒杀），用
REPEATABLE_READ+ 行锁（主键更新）+ 应用层幂等，比升级隔离级别更实际 - 跨表统计类查询（如报表），可考虑
READ_UNCOMMITTED或快照读，避免长事务阻塞 - Spring中通过
@Transactional(isolation = Isolation.REPEATABLE_READ)指定，但最终生效取决于数据库实际支持
持久性与生产调优：日志、超时、传播行为一个都不能松
持久性由数据库WAL机制保障，但Java层若配置不当，会让它形同虚设：
- 事务超时设置不合理（如默认-1无限等待）易导致连接池耗尽，建议统一设为3~10秒，用
@Transactional(timeout = 5) - 嵌套调用慎用
PROPAGATION_REQUIRES_NEW，每次新建事务意味着额外日志刷盘和连接开销，高频调用会拖慢TPS - 异步任务（@Async）里开启事务，需确保使用的是
SimpleAsyncTaskExecutor或自定义线程池配TransactionSynchronizationManager，否则事务上下文无法传递 - 监控关键指标：事务提交率、平均耗时、回滚率（持续高于2%需排查异常模式）、死锁次数（MySQL可通过
SHOW ENGINE INNODB STATUS查）
