在日常运维 SaaS 平台的过程中，数据库连接池资源耗尽是导致服务级联不可用的常见原因之一。而引发这一问题的源头，往往是一段包含外部调用的长事务（Long Transaction）代码。
在某次常规测评期间，监控系统显示服务出现大面积请求超时。排查数据库服务器时，CPU 和内存负载均保持在正常水位，也未发生死锁。然而，应用层的 HikariCP 数据库连接池监控却显示：活跃连接数已经达到配置的上限，并且没有连接被及时归还。所有后续的业务线程都在排队等待获取数据库连接。
问题定位：事务边界内混入了外部 I/O
通过链路追踪系统，我们定位到了资源耗尽的具体位置：一个用于生成学生心理评估报告的业务方法。这段代码的逻辑结构如下：
“`java
@Transactional
public void generatePsyReport(Long studentId) {
// 1. 从数据库读取基础数据
Student stu = studentMapper.selectById(studentId);
// 2. 结合算法进行多维度数据计算
ReportData data = complexCalculator.calculate(studentId);
// 3. 调用外部第三方服务发送通知（存在网络不稳定风险）
jpushService.pushAlert(stu.getPhone(), data);
// 4. 将计算生成的报告结果写入数据库
reportMapper.insert(data);
}
“`
从业务上看，这几步操作顺理成章，同时开发者习惯性地加上了 @Transactional 试图保证数据一致性。但正是这个注解，导致了连接泄露的隐患。
当方法开始执行时，Spring AOP 机制会从 HikariCP 连接池中获取一个 MySQL 连接并开启事务。执行到第 3 步时，如果外部的第三方推送接口发生网络延迟（例如响应时间延长到了 3 秒），这个数据库连接将会一直被当前线程持有，直到整个方法执行完毕并提交事务。
在测评高峰期，如果有数百个用户同时触发报告生成，这些请求会在短时间内占用连接池中的所有连接。此时因为外部 HTTP 调用的阻塞，这些连接无法得到释放，整个系统的其他数据库请求（哪怕只是简单的身份验证查询）也会因无法获取连接而阻塞，进而引发服务雪崩。
剥离耗时操作，重塑事务边界
橙星云技术团队在内部开发规约中明确规定：数据库事务应当尽量简短，内部只保留纯粹的数据库增删改操作，避免混入 RPC 调用、HTTP 请求或耗时较长的复杂计算。
针对上述问题，我们可以将事务边界进行重构，把无需事务支持的操作剥离出来：
“`java
public void generatePsyReport(Long studentId) {
// 【非事务区：数据库查询与内存计算，不长时间占用事务资源】
Student stu = studentMapper.selectById(studentId);
ReportData data = complexCalculator.calculate(studentId);
// 调用外部服务，允许适度延迟，不影响数据库连接池
jpushService.pushAlert(stu.getPhone(), data);
// 【事务区：仅处理数据写入】
dbService.saveReportInTx(data);
}
“`
在重构后的逻辑中，saveReportInTx 是一个独立的方法，且只承担入库职能。由于只包含数据写入，这个方法的执行时间通常在十几毫秒以内。这意味着每个请求占用数据库连接的时间被极大缩短，少量的连接即可在短时间内完成高频的流转。
深入理解 Spring 声明式事务的生命周期，剥离非必要的耗时操作，避免长事务的产生，是保障 B 端高并发平台可用性的关键基础。