接口前20次都正常，第21次为什么开始全部超时？

接口前20次都很快：每次30毫秒返回“无权限”。第21次开始，所有请求一起卡住，10秒后超时。

研发第一反应是数据库慢了，监控却显示没有慢SQL。真正的问题藏在失败路径：接口拿到数据库连接后发现用户无权查看报表，于是提前返回，却没有把连接还回连接池。

连接池容量刚好是20。前20次“快速失败”每次偷走一个名额，第21次已经没有连接可借。此后连正常用户也进不来。

本文使用教学报表接口。约束是：连接池最多20个连接；权限检查需要读取租户信息；拒绝请求也必须释放资源；数据库超时、解析异常和客户端断开都可能发生；一次请求最多归还一次连接，不能泄漏也不能重复归还。

为什么常规性能测试很容易漏掉

如果压测只发送合法请求，正常路径末尾的 release() 会执行，吞吐和延迟都很好。如果异常用例每次重启应用，连接池也会重新装满，泄漏无法累积。

资源泄漏通常不是第一请求就失败，而是状态随着请求次数单调恶化。测试必须在同一进程、同一连接池上连续触发异常，并观察“借出数是否回到基线”。

提前返回只是其中一种出口

容易漏释放的出口包括：权限拒绝、参数校验失败、查询超时、反序列化异常、业务分支返回、协程取消和客户端断连。只在函数最后写一次释放，任何中途跳出都可能绕开它。

下面用一个最小连接池复现“前20次正常，第21次超时”的形状：

class Pool:
    def __init__(self, size):
        self.size = size
        self.in_use = 0

    def acquire(self):
        if self.in_use >= self.size:
            raise TimeoutError("连接池已耗尽")
        self.in_use += 1
        return object()

    def release(self, _connection):
        self.in_use -= 1


def buggy_report(pool, allowed):
    connection = pool.acquire()
    if not allowed:
        return "FORBIDDEN"       # 提前返回，连接没有归还
    pool.release(connection)
    return "OK"


pool = Pool(20)
assert all(buggy_report(pool, False) == "FORBIDDEN" for _ in range(20))
assert pool.in_use == 20
try:
    buggy_report(pool, True)
    raise AssertionError("第21次应拿不到连接")
except TimeoutError:
    pass

这段代码故意省略线程安全与真实驱动，只用于暴露资源不变量。生产连接池还会有等待队列、最大生命周期、健康检查和事务状态。

修复不是“把池调到200”

扩大连接池只会把故障从第21次推迟到第201次，还可能给数据库制造更大并发。正确方向是让资源获取与释放绑定在一个结构化作用域里。

from contextlib import contextmanager


@contextmanager
def lease(pool):
    connection = pool.acquire()
    try:
        yield connection
    finally:
        pool.release(connection)


def safe_report(pool, allowed):
    with lease(pool):
        if not allowed:
            return "FORBIDDEN"
        return "OK"


safe_pool = Pool(20)
assert all(safe_report(safe_pool, False) == "FORBIDDEN" for _ in range(100))
assert safe_pool.in_use == 0

finally能覆盖普通返回与多数异常，但进程被强制终止、驱动失去网络、事务未清理等情况仍需要池和数据库自身的回收机制。不要把示例等同于完整生产方案。

把“资源归零”写成每条用例的后置断言

每个请求结束后，至少核对连接池借出数、事务活跃数、临时文件、锁和后台任务是否回到允许基线。基线不一定永远是0，例如应用可能保留固定后台连接；关键是本次操作不能留下净增长。

回归用例应覆盖：权限拒绝100次、查询抛异常、结果解析失败、请求超时、客户端断开、连接本身失效，以及释放函数再次报错。还要验证重复释放不会把池计数改成负数，失效连接不会被当作健康连接重新借出。

上线后不要等到全超时才发现

连接池使用率只是第一层。更早的信号包括借用时长分布、借出与归还差值、等待队列长度、请求结束后仍活跃的事务数，以及按响应状态分组的资源占用。若403请求越多，借出数越高，关联已经非常可疑。

告警要在“还能处理请求”时触发，例如借出数持续上升且归还率偏离，而不是等池100%后才叫人。事故期间临时扩容可以争取时间，但仍要找到具体泄漏出口。

第21次超时不是第21次请求突然变慢，而是前20次请求都没有真正结束。稳定性测试要验证每一条退出路径都把借来的资源完整归还。