宝子们，今天和大家唠一个超常见却又容易踩坑的技术问题！最近有位小伙伴在开发同步企微用户功能时，差点被整崩溃—— 在给方法加了@Transactional注解，结果执行时却突然报错：The client was disconnected by the server because of inactivity. See wait_time，这到底咋回事？别慌，今天咱就来抽丝剥茧，把这个问题盘得明明白白！
问题场景还原：一场“龟速” 接口引发的血案
这个同步用户的方法，逻辑看着挺简单：先去查询第三方接口获取用户数据，再把数据批量塞进数据库。可谁能想到，第三方接口就像开了“龟速模式”，响应慢得离谱！要知道，在 Spring 框架里，虽然@Transactional注解默认没有设置超时时间（timeout 属性为 – 1） ，但数据库层面可不答应 ！比如 MySQL 的innodb_lock_wait_timeout默认值是 50 秒，一旦事务执行时间超过这个限制，数据库就会觉得客户端 “摸鱼” 太久，直接断开连接，报错就这么来了！
为啥会翻车？三大“罪魁祸首” 大起底
数据库的“急性子”：事务超时是数据库和 Spring 事务管理的 “守护机制”。想象一下，如果一个事务没完没了地占着数据库连接，其他事务只能干瞪眼，数据库性能会直线下降，甚至可能引发死锁！所以数据库设置超时时间，就是为了及时 “止损”，强制终止 “磨洋工” 的事务。
第三方接口的“不可控”：第三方接口不在咱们掌控范围内，服务器性能、网络波动、接口复杂度…… 随便一个因素都可能让它 “摆烂”，拖慢整个事务进度。
@Transactional 的 “小脾气”：虽然@Transactional的timeout默认不设限，但数据库可不买账！要是咱们没手动调整超时时间，一旦遇上耗时操作，就只能等着数据库“发火” 断开连接了。
@Transactional 注解：看似简单，实则暗藏玄机
@Transactional可是 Spring 框架里管理数据库事务的 “得力干将”，能帮我们轻松实现数据的一致性和完整性。不过它的门道可不少，快来看看这些关键知识点！
- 常用属性：按需定制你的事务 “规则”
propagation（事务传播行为）：就像事务间的“社交规则”。比如REQUIRED（默认值），意思是“有事务就加入，没有就创建新的”；REQUIRES_NEW更霸道，不管有没有事务，都要开个新的“小群” 自己玩。
isolation（事务隔离级别）：用来解决事务并发访问的“冲突”，比如脏读、不可重复读、幻读等问题。MySQL 默认的REPEATABLE_READ，就能保证在一个事务里多次读取同一数据时，数据不会“变魔术”。
timeout（事务超时时间）：前面踩坑的关键！我们可以手动设置这个属性，给事务执行时间“上闹钟”，避免它无限期拖延。
readOnly（只读事务）：如果事务只负责“读数据”，把它设为true，数据库就能针对性优化，提升性能！
- 应用场景：这些地方都少不了它
在电商系统里，用户下单时，更新库存、生成订单、扣减余额这些操作，必须“同生共死”，这时@Transactional就能派上用场；还有用户注册功能，插入基本信息和权限信息，也得靠它保证数据完整性。 - 注意事项：这些 “坑” 千万别踩
注解生效有门槛：@Transactional只对public修饰的方法“感冒”，用在private、protected方法上，它可不会起作用哦！
自调用的“陷阱”：类内部方法互相调用@Transactional注解的方法，事务可能失效。因为 Spring 事务靠 AOP 实现，自调用时代理对象 “帮不上忙”，解决办法可以抽取出新类，或者用AopContext.currentProxy()获取代理对象调用。
异常处理有讲究：只有抛出RuntimeException及其子类（未检查异常），事务才会自动回滚；受检异常得手动处理，或者用rollbackFor属性指定回滚类型。
问题解决：三招教你“反杀” 事务超时
延长“生命线”：在@Transactional注解里手动设置timeout属性，比如@Transactional(timeout = 120)，给事务多留点时间。但别太贪心，无限制延长会拖慢数据库性能！
拆分开“单干”：把查询第三方接口和插入数据库拆成两个方法，分别加@Transactional注解。这样查询慢也不影响插入，“分工合作” 更高效！
异步“开小灶”：用 Spring 的@Async注解把查询操作放到单独线程，不阻塞主线程，等数据查完再插入数据库，系统响应更快，还能避开超时问题！
声明：来自全栈的程序员，仅代表作者观点。链接：https://eyangzhen.com/1964.html
