Spring@Transactional服务器中途关闭不回滚？违反原子性的原因探究

先还原问题中的代码示例：

@Transactional
public void method() {
    write();
    // server shuts down
    write();
}

出现第一个write()操作未回滚的核心原因如下：

• 事务控制依赖进程内的事务管理器
  Spring的@Transactional基于AOP实现，事务的开启、提交/回滚全靠进程内的事务管理器调度。当服务器突然关闭（比如进程被强制终止、断电），JVM会直接退出，事务管理器连方法执行中断的事件都捕获不到，根本没机会触发回滚逻辑，自然无法向数据库发送回滚指令。

• 数据库事务的恢复逻辑受场景限制

  • 如果是应用进程正常退出（比如收到kill信号），数据库通常能检测到连接断开，此时该连接上未提交的事务会被自动回滚。但如果是极端硬崩溃（如服务器断电），数据库需要重启后通过事务日志恢复：未提交的事务会被回滚，已提交的会被持久化。
  • 若你观察到第一个write()未回滚，大概率是该操作已被提前提交：比如write()内部绕过Spring事务，直接使用了默认开启自动提交的JDBC连接；或者write()标注了@Transactional(propagation = Propagation.REQUIRES_NEW)，每次调用都会开启独立事务并在方法结束时提交——这种情况下第一个write()的事务已经完成提交，服务器关闭不会影响它。

• 事务原子性的边界限制
  事务原子性是数据库层面的保证，但前提是事务能被数据库正确识别管理。如果应用端事务管理器无法触发回滚，数据库的自动恢复依赖自身崩溃恢复能力，这需要数据库正常重启、事务日志完整等前提。极端场景下的瞬间断电可能导致数据库来不及记录事务状态，但这属于硬件/基础设施故障，并非Spring事务机制违背原子性。

内容的提问来源于stack exchange，提问作者Daniel Pop