设置事务超时时间是防止长事务拖垮数据库最直接有效的手段，需通过@Transactional(timeout=X)控制方法级超时，并协同PreparedStatement查询超时、连接池connection-timeout及数据库自身超时形成多层防护，避免因事务未生效、超时发生在事务外或传播行为干扰导致失效。
设置事务超时时间是防止长事务拖垮数据库最直接有效的手段之一。它不是“锦上添花”的配置，而是高并发、分布式场景下保障系统稳定性的基础防线。核心逻辑很明确：不让一个事务无限期占用连接、锁和内存资源。
用 @Transactional(timeout = X) 精准控制方法级超时
这是最常用也最推荐的方式，适用于 Spring 管理的声明式事务：
- timeout 单位是秒，例如
@Transactional(timeout = 5)表示该方法内事务最多运行 5 秒，超时则自动回滚 - 该设置只对支持超时的事务管理器生效（如
JpaTransactionManager、DataSourceTransactionManager在较新版本中已支持），老版本 JDBC 事务管理器可能忽略此配置 - 注意：超时计时从事务真正开启（即数据库连接获取并开启事务）开始，不是方法入口；所以方法内耗时但不涉及数据库操作的部分（比如
Thread.sleep(3000)放在save()之后）不会触发超时
结合数据库连接与查询级超时形成多层防护
Spring 事务超时只是其中一环，还需配合底层数据库操作的超时机制：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 为
PreparedStatement设置查询超时：preparedStatement.setQueryTimeout(3)（单位：秒），防止单条 SQL 执行过久 - 配置数据源连接池的连接获取超时（如 HikariCP 的
connection-timeout），避免线程卡在等连接上 - 数据库自身也可设语句超时（如 MySQL 的
max_execution_time），作为最后兜底
避免常见失效陷阱：超时不生效的典型原因
很多团队发现加了 timeout 却没效果，往往掉进这几个坑里：
立即学习“Java免费学习笔记（深入）”；
-
事务未真正生效：方法不是 public、被同一类内调用（绕过代理）、未启用
@EnableTransactionManagement或缺少事务管理器 Bean -
超时发生在事务外：比如休眠或远程调用写在事务提交之后（如
save()后再Thread.sleep()），此时事务早已结束，超时设置自然无效 -
事务传播行为干扰：若方法 A 调用 B，B 使用
PROPAGATION_NOT_SUPPORTED或NEVER，那 B 就不在事务内，@Transactional(timeout) 对它不起作用
分布式事务场景下需额外协同超时策略
单库事务超时解决不了跨服务问题，必须上下文对齐：
- Seata、Saga 等框架要求所有参与者设置一致或递进的超时时间（如全局事务 10s，各分支设为 8s），避免协调者已超时而参与者还在等
- RPC 调用本身也要设超时（如 Feign 的
readTimeout、Dubbo 的timeout），否则远程服务无响应会拖住本地事务 - 建议使用统一上下文传递超时 deadline（如基于
DeadlineContext或自定义 header），让下游能主动感知剩余时间并决策
