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虽强，但性能损耗大，且可能引发大量锁等待。

• 高并发查+改场景（如秒杀），用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查）

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