@Transactional滥用导致连接池耗尽的根因与修复-平芜编程栈

1. 问题现场还原：一个@Transactional注解如何拖垮整个数据库连接

我第一次在生产环境看到这个报错时，心里咯噔一下——org.springframework.dao.DataAccessResourceFailureException: Could not open JDBC Connection for transaction; nested exception is java.sql.SQLTimeoutException: Timeout occurred while trying to get a connection from the pool。不是数据库挂了，不是网络断了，而是应用自己把自己卡死了。当时线上订单接口响应时间从200ms飙升到12秒，监控大盘上连接池活跃数曲线像一根绷紧的钢丝，直直顶在98%的红色警戒线之上。排查日志发现，大量请求卡在DruidDataSource.getConnectionInternal()方法里死等连接，而数据库端实际只开了不到30个会话。这根本不是Oracle扛不住，是Spring Boot应用自己把连接池“锁死”了。

核心关键词就藏在这句报错里：@Transactional、数据源、连接池、Druid、Oracle。这不是某个配置写错了的小毛病，而是Spring事务管理机制与数据库连接生命周期之间一次典型的“认知错位”。很多人以为@Transactional只是加个事务边界，其实它背后牵动的是整个JDBC连接的获取、复用、释放链条。尤其当项目里混用了多数据源（比如主库Oracle+从库MySQL）、又叠加了异步调用、定时任务、重试逻辑时，一个没加传播行为的@Transactional，就像往高速公路上扔了一颗钉子——单看不显眼，但车流一密集，立刻引发连环追尾。我见过最典型的案例：一个导出Excel的Controller方法，被标注了@Transactional，结果用户点一次导出，后台就占着一个Oracle连接长达3分钟（因为要查10万行数据+生成报表），而连接池最大只有20个连接，第21个请求进来就只能干等。这不是Oracle慢，是连接被“合法占用”却“无效持有”。

这个问题之所以高频爆发，恰恰因为它太隐蔽。开发写代码时，IDEA里绿色小钩钩看着很安心；测试环境QPS低，连接池永远有富余；但一上生产，流量翻倍、慢SQL增多、异常分支变多，连接池耗尽就成了压垮骆驼的最后一根稻草。它不像NPE那样当场报错，而是让系统进入一种“半瘫痪”状态：新请求进不来，老请求出不去，监控指标全飘红，但DBA查数据库一切正常——问题不在DB，而在应用层对连接资源的误用。今天这篇，我就带你一层层剥开@Transactional滥用背后的连接池黑洞，从Druid源码级原理讲起，手把手教你定位、修复、预防，而不是靠重启应用来“续命”。

2. 核心机制拆解：为什么@Transactional会死锁连接池？

2.1 Spring事务管理器与连接获取的“绑定契约”

@Transactional不是魔法，它背后是Spring的PlatformTransactionManager在工作。以最常见的DataSourceTransactionManager为例，它的核心逻辑就藏在doBegin()方法里。当你在一个方法上加了@Transactional，Spring会在方法执行前调用doBegin()，而这个方法最关键的一步就是：从数据源中获取一个Connection，并将其绑定到当前线程的TransactionSynchronizationManager中。

// 简化版DataSourceTransactionManager.doBegin源码逻辑 protected void doBegin(Object transaction, TransactionDefinition definition) { DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction; Connection con = null; try { // 关键！这里会触发DruidDataSource.getConnection() con = this.dataSource.getConnection(); // 将Connection绑定到当前线程的ThreadLocal中 txObject.setConnectionHolder(new ConnectionHolder(con), true); // 同时将ConnectionHolder注册到TransactionSynchronizationManager TransactionSynchronizationManager.bindResource(this.dataSource, txObject.getConnectionHolder()); } catch (SQLException ex) { throw new CannotCreateTransactionException("Could not open JDBC Connection", ex); } }

注意这个this.dataSource.getConnection()调用——它不是简单地拿个连接，而是触发了Druid连接池的完整获取流程。而一旦Connection被成功获取并绑定，它就进入了“事务生命周期”，直到事务提交或回滚，这个Connection都不会被归还给连接池。这是Spring事务模型的铁律：同一个事务内，所有DAO操作必须复用同一个Connection，否则无法保证ACID。所以，@Transactional的本质，就是向连接池“预支”一个Connection，并承诺“用完即还”。但问题来了：这个“还”的时机，完全取决于事务的结束。

2.2 事务传播行为：决定Connection命运的“生死开关”

@Transactional的propagation属性，就是那个决定Connection是否会被长期霸占的开关。默认值是Propagation.REQUIRED，意思是“如果当前存在事务，则加入该事务；否则新建一个事务”。这本身没问题，但一旦嵌套调用发生，问题就暴露了：

Scenario A（安全）：ServiceA.methodA()加了@Transactional，调用ServiceB.methodB()（无@Transactional）。此时methodB复用methodA的Connection，事务结束时统一归还。
Scenario B（危险）：ServiceA.methodA()加了@Transactional，调用ServiceB.methodB()（也加了@Transactional且propagation=REQUIRES_NEW）。此时methodB会挂起methodA的事务，新建一个独立事务，从而从连接池再拿一个Connection。如果methodB执行时间长，或者被循环调用，Connection就会被成倍占用。

更致命的是Propagation.SUPPORTS和Propagation.NEVER。前者表示“如果当前有事务就加入，没有就不开启事务”，看似温和，但它不会主动获取Connection。但如果方法里调用了JdbcTemplate.query()，而此时恰好没有事务上下文，JdbcTemplate会自己去dataSource.getConnection()，拿到连接后却不绑定到事务管理器，导致这个连接用完后直接归还池中——这本身是安全的。但开发者往往误以为加了SUPPORTS就万事大吉，结果在需要事务的方法里用了SUPPORTS，导致部分SQL没被事务包裹，数据一致性崩塌。

而Propagation.NEVER更危险：它要求“绝对不能有事务”，一旦检测到当前线程有事务上下文，直接抛异常。但很多框架（如Spring Batch的StepExecutionListener）内部会开启事务，你一用NEVER，整个流程就中断。这些传播行为的选择，本质上是在回答一个问题：“这个方法，到底需不需要独占一个Connection？”

2.3 Druid连接池的“等待策略”与超时陷阱

Druid作为国内最主流的连接池，其maxActive（1.2.16版本后改名maxPoolSize）和maxWait参数，是压垮系统的最后一根杠杆。假设你的Oracle数据库最大并发连接数是200，你配置Druid的maxPoolSize=20，maxWait=60000（60秒）。这意味着：

池子里最多20个连接可用；
如果20个全被占用，第21个请求会进入等待队列；
它最多等60秒，超时后抛出SQLTimeoutException。

问题在于，60秒的等待时间，在高并发场景下是灾难性的。一个用户点击下单，后端服务要调用库存、订单、支付三个微服务，每个服务内部都有@Transactional方法。如果其中任何一个环节（比如支付回调）因网络抖动延迟5秒，那么这5秒内，它占用的Connection就一直不释放。而每秒100个下单请求，意味着每秒有300个Connection被申请（3个服务×100），但池子只有20个，瞬间积压280个等待线程。JVM线程数暴涨，CPU打满，GC频繁，整个应用雪崩。这不是Druid配置小，而是@Transactional让连接“借而不还”的时间窗口，远大于业务实际处理时间。

提示：Druid的removeAbandonedOnBorrow=true（1.2.16已废弃，改用removeAbandonedOnUse）本意是回收“被遗弃”的连接，但它依赖removeAbandonedTimeoutMillis（默认300秒）。也就是说，一个Connection被占用超过5分钟，Druid才会强制回收。而很多慢查询、大数据量导出，执行时间就在3-8分钟之间——正好卡在回收阈值之外，成了连接池里的“僵尸连接”。

2.4 Oracle JDBC驱动的“隐式连接持有”特性

Oracle的JDBC驱动（ojdbc8.jar）有个鲜为人知的特性：当Connection执行了setAutoCommit(false)后，即使你手动调用了connection.close()，这个Connection也不会真正归还给连接池，而是被标记为“dirty”，需要等到事务commit/rollback后才能复用。而Spring的DataSourceTransactionManager，在事务开始时会自动调用con.setAutoCommit(false)，这是开启JDBC事务的必要步骤。

这就形成了一个闭环陷阱：

@Transactional方法启动，Spring获取Connection并setAutoCommit(false)；
方法内执行SQL，一切正常；
方法执行完毕，Spring准备commit，调用con.commit()；
但如果commit过程因网络问题、Oracle监听异常（ORA-12547）失败，Spring会进入回滚逻辑，调用con.rollback()；
rollback同样可能失败（比如连接已断），此时Connection进入一种“既没commit也没rollback”的中间态；
Druid检测到这个Connection状态异常，不会将其放回active队列，而是丢进discardCount统计，最终导致连接池可用连接数持续下降。

我亲眼见过一个案例：Oracle RAC集群中某节点网络闪断，导致10个Connection在rollback阶段卡住，Druid日志里Discard count: 10不断增长，而ActiveCount从20掉到10，系统立刻告警。这根本不是代码bug，而是Oracle JDBC驱动与Druid连接池在异常处理上的“默契不足”。

3. 实操诊断与修复：四步精准定位与根治

3.1 第一步：实时监控连接池状态——别猜，要看

在生产环境，永远不要靠日志“猜”问题。Druid提供了强大的内置监控页面（/druid/index.html），但默认关闭。你需要在application.yml中显式开启：

spring: datasource: druid: # 开启Druid监控 stat-view-servlet: enabled: true login-username: admin login-password: your_password allow: 127.0.0.1,192.168.1.0/24 # 生产环境务必限制IP web-stat-filter: enabled: true exclusions: "*.js,*.css,/druid/*"

访问http://your-app:8080/druid/index.html后，重点关注三个Tab：

数据源：看ActiveCount（当前活跃连接数）、PoolingCount（空闲连接数）、WaitThreadCount（等待线程数）。如果ActiveCount长期接近maxPoolSize，且WaitThreadCount > 0，说明连接池已饱和。
SQL监控：按ExecuteTime排序，找出执行时间最长的SQL。特别关注那些Running状态超过30秒的SQL——它们极大概率是@Transactional方法里正在执行的慢查询。
URI监控：看哪个HTTP接口的RunningCount最高。比如/api/export/order的RunningCount=18，而池子大小=20，基本可以锁定问题接口。

实操心得：我习惯在监控页右上角点“JSON API”，复制/druid/json/stat/dataSource.json的URL，用curl定时抓取：
curl "http://localhost:8080/druid/json/stat/dataSource.json" | jq '.ActiveCount, .PoolingCount, .WaitThreadCount, .LogicConnectCount, .PhysicalConnectCount'
把这个命令写成脚本，每5秒执行一次，输出到文件。当WaitThreadCount突增时，立刻结合jstack抓线程快照，能精准定位是哪个线程在getConnectionInternal里阻塞。

3.2 第二步：代码层扫描——用Arthas揪出“罪魁祸首”

有了监控线索，下一步是定位具体哪段代码在滥用@Transactional。Arthas是Java诊断神器，无需重启，实时热修复。假设监控显示/api/export接口有问题，我们用Arthas追踪它的调用链：

# 进入Arthas curl -O https://arthas.aliyun.com/arthas-boot.jar java -jar arthas-boot.jar # 查找目标进程PID [INFO] Found existing java process, please choose one and hit RETURN. * [1]: 12345 /opt/app/your-app.jar # 追踪该接口的Spring MVC调用 trace com.yourpackage.controller.ExportController exportOrder --skipJDKMethod false # 观察输出，重点看@Transactional方法的执行时间 ---ts=2023-10-05 14:23:45;thread_name=http-nio-8080-exec-15;id=15;is_daemon=true;priority=5;TCCL=org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedWebappClassLoader@1a2c8d1e `---com.yourpackage.service.ExportService.exportOrder() # 耗时 182345ms! `---com.yourpackage.dao.OrderDao.listAllOrders() # 耗时 182300ms!

看到exportOrder()耗时3分钟，而它里面调用了listAllOrders()，这个DAO方法必然在@Transactional方法内。接着，用sc命令搜索所有@Transactional类：

sc -d *ServiceImpl | grep "annotation.*Transactional"

输出类似：

class-info com.yourpackage.service.ExportServiceImpl code-source file:/opt/app/lib/your-app.jar!/BOOT-INF/classes!/ name com.yourpackage.service.ExportServiceImpl is-interface false is-annotation false is-enum false is-anonymous-class false is-generic false is-member-class false is-local-class false is-member-class false class-loader org.springframework.boot.loader.LaunchedURLClassLoader@1a2c8d1e classLoaderHash 1a2c8d1e annotations @org.springframework.transaction.annotation.Transactional(value=[], rollbackFor=[], noRollbackFor=[], propagation=REQUIRED, isolation=DEFAULT, timeout=-1, readOnly=false, value="", transactionManager="transactionManager")

注意timeout=-1，这是默认值，意味着“永不超时”。这就是问题根源！我们必须给它加超时保护。

3.3 第三步：精准修复——从@Transactional到连接池的全链路优化

3.3.1 @Transactional层面：强制超时与传播行为修正

对ExportService.exportOrder()方法，必须做两件事：

设置事务超时：防止慢查询无限占用Connection；
调整传播行为：如果该方法只是读取数据（如导出），应避免开启事务。

@Service public class ExportService { // 错误示范：无超时，REQUIRED传播 // @Transactional // 正确示范：只读事务 + 30秒超时 + SUPPORTS传播（不强制开启事务） @Transactional(propagation = Propagation.SUPPORTS, readOnly = true, timeout = 30) // 单位：秒 public List<Order> listAllOrders() { return orderDao.selectAll(); } // 对于必须写操作的方法，如createOrder() @Transactional(propagation = Propagation.REQUIRED, timeout = 10, // 写操作通常更快，设10秒足够 rollbackFor = {Exception.class}) public void createOrder(Order order) { orderDao.insert(order); stockDao.decreaseStock(order.getProductId()); } }

readOnly=true是关键优化。它会告诉Spring：“这个事务只读，可以做一些优化”。Spring会调用Connection.setReadOnly(true)，而Oracle JDBC驱动收到此指令后，会：

避免在Connection上开启不必要的事务日志；
在某些场景下（如使用SELECT FOR UPDATE时）提前报错，避免脏读；
最重要的是，Druid连接池会将readOnly的Connection优先分配给只读请求，减少写事务对连接池的争抢。

3.3.2 Druid连接池层面：参数调优与防御性配置

基于Oracle的特性，Druid参数必须精细化配置。以下是我的生产环境推荐配置（application.yml）：

spring: datasource: druid: # 核心连接数 initial-size: 5 min-idle: 5 max-active: 20 # 严格匹配Oracle的processes参数（通常设为20-50） # 关键超时参数 max-wait: 30000 # 30秒！比默认60秒更激进，宁可快速失败也不让线程堆积 time-between-eviction-runs-millis: 60000 # 每分钟检测一次空闲连接 # 防御性配置（针对Oracle） remove-abandoned-on-mismatch: true # 当连接数与实际不符时，强制回收 remove-abandoned-timeout-millis: 180000 # 3分钟，比默认5分钟更短，及时清理“僵尸” test-while-idle: true validation-query: SELECT 1 FROM DUAL # Oracle必须用DUAL validation-query-timeout: 3 # 验证SQL超时3秒，避免验证本身卡住 # 监控增强 log-abandoned-on-remove: true # 记录被回收的连接堆栈，方便溯源 filters: stat,wall,log4j2 # wall防火墙过滤恶意SQL，log4j2记录详细日志

特别强调validation-query: SELECT 1 FROM DUAL。很多团队用SELECT 1，但在Oracle里会报错，必须显式指定DUAL表。而validation-query-timeout: 3是为了防止Oracle监听服务（TNS Listener）偶发卡顿，导致验证SQL hang住，连带拖垮整个连接池。

3.3.3 多数据源场景下的隔离策略

如果你的项目用了多数据源（如primaryDataSource连Oracle，secondaryDataSource连MySQL），必须确保事务管理器与数据源严格绑定。错误配置会导致事务管理器从错误的数据源拿连接：

// 错误：同一个TransactionManager管理多个数据源 @Bean public PlatformTransactionManager transactionManager() { return new DataSourceTransactionManager(primaryDataSource()); // 只管Oracle } // 正确：为每个数据源配专属TransactionManager @Bean("oracleTransactionManager") public PlatformTransactionManager oracleTransactionManager() { return new DataSourceTransactionManager(primaryDataSource()); } @Bean("mysqlTransactionManager") public PlatformTransactionManager mysqlTransactionManager() { return new DataSourceTransactionManager(secondaryDataSource()); } // 在Service中指定使用哪个事务管理器 @Service public class OrderService { @Transactional(transactionManager = "oracleTransactionManager") public void createOrderInOracle(Order order) { ... } @Transactional(transactionManager = "mysqlTransactionManager") public void syncToMysql(Order order) { ... } }

否则，@Transactional注解会默认使用transactionManagerBean，而它只认Oracle数据源。当syncToMysql()方法被调用时，Spring会试图从Oracle数据源拿连接，结果抛出CannotGetJdbcConnectionException，而MySQL连接池却空闲着——资源错配，双输。

3.4 第四步：上线验证与熔断兜底

修复代码后，不能直接上生产。必须做三件事：

压测验证：用JMeter模拟1000并发请求，观察Druid监控页的ActiveCount是否稳定在15-18之间，WaitThreadCount是否始终为0。

日志埋点：在关键@Transactional方法前后加日志，记录方法名、耗时、事务状态：

@Around("@annotation(org.springframework.transaction.annotation.Transactional)") public Object logTransaction(ProceedingJoinPoint joinPoint) throws Throwable { long start = System.currentTimeMillis(); String methodName = joinPoint.getSignature().toShortString(); try { Object result = joinPoint.proceed(); long cost = System.currentTimeMillis() - start; if (cost > 5000) { // 超过5秒记WARN log.warn("Slow transaction method: {}, cost: {}ms", methodName, cost); } return result; } catch (Exception e) { long cost = System.currentTimeMillis() - start; log.error("Transaction failed: {}, cost: {}ms, error: {}", methodName, cost, e.getMessage()); throw e; } }

熔断兜底：集成Sentinel或Resilience4j，在连接池耗尽时快速失败，避免线程堆积。例如，当WaitThreadCount > 5时，直接返回503 Service Unavailable，而不是让用户干等：

@GetMapping("/export") public ResponseEntity<?> exportOrder() { // 检查Druid连接池状态 DruidDataSource dataSource = (DruidDataSource) primaryDataSource(); if (dataSource.getWaitThreadCount() > 5) { return ResponseEntity.status(HttpStatus.SERVICE_UNAVAILABLE) .body("系统繁忙，请稍后再试"); } return ResponseEntity.ok(exportService.exportOrder()); }

4. 常见问题与避坑指南：血泪教训总结

4.1 典型问题速查表

问题现象	根本原因	快速定位方法	解决方案
`SQLTimeoutException`频发，但DB监控正常	@Transactional方法内有未优化的慢SQL，执行时间超过`maxWait`	Druid监控页→SQL监控→按`ExecuteTime`排序	优化SQL（加索引、分页）、缩短事务范围、设置`@Transactional(timeout=...)`
`ActiveCount`持续100%，`PoolingCount`为0	事务未正常提交/回滚，Connection被“悬挂”	`jstack <pid> \| grep "getConnectionInternal"`+`jmap -histo <pid>`看Connection对象数	检查是否有`try-catch`吞掉了异常，导致`@Transactional`的rollback失效；确保所有异常都抛出或明确`rollbackFor`
切换Oracle 19c后连接池耗尽加剧	Oracle 19c默认启用`ENABLE_BROKEN_CONNECTION_DETECTION`，JDBC驱动更敏感	查看Druid日志是否有`discardCount`增长	在`jdbc.url`中添加`?oracle.net.disableOob=true`关闭OOB检测，或升级ojdbc10.jar
多数据源下部分事务不生效	`@Transactional`未指定`transactionManager`，默认使用了错误的数据源	检查`@Transactional`注解是否带`transactionManager`属性	为每个数据源声明独立的`PlatformTransactionManager`Bean，并在Service中显式引用
定时任务`@Scheduled`方法加了@Transactional，导致连接池缓慢耗尽	定时任务线程池与Web线程池共用同一连接池，且任务执行时间长	Druid监控页→URI监控→看`/druid/weburi.json`中定时任务路径的`RunningCount`	将定时任务迁移到独立的`@Async`线程池，并配置专用的`TaskExecutor`，避免抢占Web连接池

4.2 我踩过的三个深坑

坑一：@Async+@Transactional的双重陷阱
一个同事写了这样的代码：

@Service public class OrderService { @Async // 异步执行 @Transactional // 事务注解 public void sendEmailAfterOrder(Order order) { emailDao.send(order.getEmail()); // 发邮件 logDao.saveSuccessLog(order.getId()); // 记日志 } }

结果发现，sendEmailAfterOrder()方法里的事务完全不生效。原因在于：@Async会创建新线程执行，而Spring的TransactionSynchronizationManager是基于ThreadLocal的，新线程里没有事务上下文。更糟的是，@Transactional注解在新线程里尝试开启事务，却因为没有TransactionManager绑定而失败，最终logDao.saveSuccessLog()执行时，是从连接池拿了新连接，但用完不归还（因为没事务管理器接管）。解决方案：要么去掉@Async，要么用TransactionTemplate手动控制事务：

@Autowired private TransactionTemplate transactionTemplate; @Async public void sendEmailAfterOrder(Order order) { transactionTemplate.execute(status -> { emailDao.send(order.getEmail()); logDao.saveSuccessLog(order.getId()); return null; }); }

坑二：Lombok的@Data与@Transactional的隐式冲突
在Entity类上用了@Data，而该Entity被@Transactional方法返回并序列化（如ResponseEntity<Entity>）。Lombok生成的toString()方法会遍历所有字段，如果Entity里有@ManyToOne关联的懒加载集合（如order.getItems()），Hibernate会在toString()里触发getItems()，从而发起新的数据库查询。这个查询没有事务上下文，会从连接池拿新连接，而@Transactional方法还没结束，旧连接还在占用，新连接又来抢——连接池瞬间告急。解决方案：Entity类禁用@Data，手写toString()，或用@ToString(exclude = "items")排除关联字段。

坑三：MyBatis的@Select与@Transactional的“假安全”
有人认为@Select是只读，加不加@Transactional无所谓。但MyBatis的@Select默认走的是SqlSessionTemplate，而SqlSessionTemplate在执行前会检查当前是否有事务，如果有，就复用事务的Connection；如果没有，就自己拿Connection。问题在于，如果一个@Select方法被@Transactional方法调用，它复用Connection没问题；但如果它被普通Controller直接调用，它就会自己拿Connection，而这个Connection用完后不会被事务管理器回收，而是由MyBatis自己归还。如果MyBatis配置不当（如closeSession没设为true），Connection就可能泄漏。最佳实践：所有DAO方法，无论读写，都应在Service层统一封装，由Service的@Transactional管控，DAO层只负责SQL执行。

4.3 预防性检查清单（上线前必做）

每次发布新功能，我都会用这个清单快速扫描：

[ ] 所有@Transactional方法是否设置了timeout？默认-1的必须改。
[ ] 是否有@Transactional加在Controller层？必须下移到Service层。
[ ] 是否有@Transactional方法调用了外部HTTP服务（如调用微信API）？必须拆分为“事务内操作+事务外调用”两步。
[ ] 是否有@Transactional方法里做了文件IO、发送邮件、调用RPC？这些耗时操作必须移出事务。
[ ] 多数据源项目，每个@Transactional是否指定了正确的transactionManager？
[ ] Druid监控页是否已开启，且login-username/password已修改为强密码？
[ ]validation-query是否针对数据库类型正确配置（Oracle用SELECT 1 FROM DUAL，MySQL用SELECT 1）？

这个清单花了我三个月时间，从十多个线上事故里提炼出来。它不追求理论完美，只解决真实世界里最痛的那几个点。记住，连接池耗尽不是技术债，而是设计债——它暴露的是我们对事务边界的模糊认知。每一次@Transactional的添加，都应该是一次 conscious decision，而不是IDEA自动生成的惯性操作。

5. 架构级思考：从连接池到领域驱动的演进

解决了一个@Transactional问题，不等于解决了所有数据访问问题。我见过太多团队，在修复连接池耗尽后，立刻陷入下一个坑：为了“保证事务一致性”，把所有业务逻辑硬塞进一个超长的@Transactional方法里，结果方法越来越臃肿，单元测试越来越难写，最终变成没人敢动的“上帝Service”。这其实是用战术勤奋掩盖战略懒惰。

真正的出路，在于把事务边界从“技术实现”升维到“业务语义”。举个例子，电商下单流程：

传统做法：@Transactional public void createOrder(...) { checkStock(); deductStock(); createOrder(); sendMQ(); }

DDD做法：定义OrderAggregate，其placeOrder()方法是一个原子业务操作，内部通过领域事件（Domain Event）解耦：

@Transactional public Order placeOrder(OrderRequest request) { // 1. 领域内校验（内存操作，无DB） validate(request); // 2. 创建订单聚合根（内存对象） Order order = new Order(request); // 3. 持久化订单（只涉及Order表） orderRepository.save(order); // 4. 发布领域事件（异步） applicationEventPublisher.publishEvent(new OrderPlacedEvent(order)); return order; }

而OrderPlacedEvent的监听器里，才去扣减库存、发消息、更新搜索索引。这些操作各自有自己的事务边界，互不影响。这样，placeOrder()方法的事务时间被压缩到毫秒级，连接池压力自然消失。

这种转变，需要团队理解：事务不是技术约束，而是业务一致性的契约。一个@Transactional注解，应该对应一个清晰的业务用例（Use Case），而不是一段技术代码。当你的架构图里，事务边界和限界上下文（Bounded Context）的边界重合时，连接池问题就不再是运维难题，而成了架构健康度的晴雨表。

最后分享一个小技巧：在团队代码评审时，把@Transactional当成一个“危险信号”来对待。每次看到它，都问三个问题：