当前位置：首页 > news >正文

FastAPI异步优化实战：解决内存泄漏与虚拟内存激增问题

news 2026/6/3 10:46:39

1. 为什么你的FastAPI服务内存越跑越高？

最近在技术社区看到不少开发者反馈，用FastAPI搭建的HTTP接口服务运行一段时间后，内存占用像坐火箭一样往上窜。我自己在去年做电商促销系统时也踩过这个坑——凌晨3点被报警短信吵醒，发现8G内存的服务器被吃了个精光。

内存泄漏的典型症状是这样的：服务刚启动时内存占用很稳定，但随着请求量增加，RES（常驻内存集）和VIRT（虚拟内存）两个指标持续增长，即使请求量下降内存也不会释放。用top命令观察，会发现Python进程的内存占用数字不断变大。

1.1 同步函数是内存杀手

FastAPI官方文档里其实藏着一个重要提示：路由处理函数默认应该是异步的。但很多从Flask转型过来的开发者（包括当年的我）会习惯性地写同步函数：

@app.post('/sync-endpoint') def sync_handler(): # 这里是耗时的数据库查询 result = heavy_db_query() return result

这种写法在并发请求时会引发线程池阻塞。FastAPI底层使用Starlette的线程池来处理同步函数，每个请求都会占用一个线程。当并发量超过线程池大小时，新请求会排队等待，导致内存中的请求上下文堆积。

1.2 虚拟内存暴涨的背后

通过ps aux命令可以看到两个关键内存指标：

RES：进程实际占用的物理内存
VIRT：进程可访问的所有内存（包括交换分区和映射文件）

当Python频繁创建/销毁对象时，内存管理器会预留虚拟地址空间（VIRT增长）。如果存在内存泄漏，物理内存（RES）也会同步增加。我做过一个测试：用同步函数处理1000次图片上传请求，VIRT从200MB飙到3.2GB，而改用异步函数后稳定在500MB左右。

2. 异步改造实战：从入门到精通

2.1 基础改造示范

把同步函数改成异步其实很简单，只需要加个async关键字：

@app.post('/async-endpoint') async def async_handler(): result = await async_db_query() # 注意这里也要用await return result

但这里有三个新手容易忽略的细节：

所有被调用的IO操作（数据库、文件、网络请求）必须本身支持异步
不能混用time.sleep()，要用asyncio.sleep()
同步库（如requests）会破坏事件循环，需要用httpx等异步HTTP客户端

2.2 数据库连接池的坑

即使用了async def，如果数据库连接配置不当还是会泄漏。以asyncpg为例，正确的连接池配置应该是：

import asyncpg async def get_db(): # 每个worker维护独立连接池 return await asyncpg.create_pool( user='user', password='pwd', database='db', host='127.0.0.1', min_size=5, # 关键参数：最小连接数 max_size=20 # 关键参数：最大连接数 ) @app.on_event("shutdown") async def shutdown(): await app.state.pool.close() # 记得关闭连接池！

曾经有同事把max_size设为100，在高并发时产生了80多个闲置连接，内存直接OOM。我的经验值是：max_size = (worker数量) * 5。

3. 高级调试技巧：定位内存泄漏点

3.1 使用objgraph可视化对象引用

当怀疑有内存泄漏时，可以用这个神级工具：

import objgraph @app.post('/debug-memory') async def debug(): # 请求前快照 before = objgraph.typestats() # 执行业务逻辑... # 请求后对比 after = objgraph.typestats() print("新增对象:", {k: after[k]-before[k] for k in after if after[k] > before[k]}) # 生成引用图（需安装xdot） objgraph.show_backrefs( objgraph.by_type('Request'), filename='request_refs.png' )

我曾经用这个方法发现了一个反直觉的泄漏——中间件里缓存的请求日志没有及时清理。

3.2 监控工具推荐

生产环境建议配置以下监控：

Prometheus + Grafana：通过process_resident_memory_bytes指标监控RES
py-spy：低开销的采样分析工具，不重启服务就能生成火焰图
aiomonitor：直接连接到运行中的asyncio事件循环检查协程状态

4. 性能优化组合拳

4.1 合理配置UVicorn参数

启动命令里的这些参数直接影响内存：

uvicorn main:app \ --workers 4 \ # 建议等于CPU核心数 --limit-concurrency 100 \ # 防止突发流量打爆内存 --timeout-keep-alive 30 \ # 及时释放闲置连接 --no-access-log # 访问日志也会占内存

4.2 警惕第三方中间件

某些中间件会偷偷缓存数据。比如这个配置就会导致请求体一直留在内存中：

app.add_middleware( GZipMiddleware, minimum_size=1000 # 大于1KB的响应自动压缩 )

建议用async-lru实现可控的缓存：

from async_lru import alru_cache @alru_cache(maxsize=128) async def query_item(item_id): return await db.fetch(item_id)

4.3 终极方案：内存隔离

对于特别吃内存的操作（比如Excel解析），可以用multiprocessing隔离：

import concurrent.futures def _heavy_sync_task(data): # 在独立进程里运行同步代码 return pandas.read_excel(data) @app.post('/process-excel') async def process_excel(file: UploadFile): loop = asyncio.get_event_loop() with concurrent.futures.ProcessPoolExecutor() as pool: result = await loop.run_in_executor( pool, _heavy_sync_task, await file.read() ) return result

这种模式相当于给内存泄漏加了防火墙——子进程退出时所有内存都会被回收。我在处理大文件上传时，用这个方法使内存占用下降了70%。

5. 真实案例：电商促销接口优化

去年双十一前，我们的秒杀接口出现内存持续增长的问题。通过以下步骤最终解决：

用mprof生成内存使用曲线，发现每次秒杀后内存阶梯式上升
用pyrasite连接到生产进程，执行gc.get_objects()发现未释放的订单对象
最终定位到问题：优惠券核销代码里同步调用了支付宝接口
改造为异步版本后，内存波动从±800MB降到±50MB

关键优化点是这个：

# 改造前（同步阻塞） def verify_coupon(): response = requests.post('https://payment/alipay') # 同步请求 # 改造后 async def verify_coupon(): async with httpx.AsyncClient() as client: response = await client.post('https://payment/alipay')

这个案例让我深刻体会到：在异步框架里混用同步代码，就像在高速公路上突然停车，后果很严重。现在团队Code Review时，看到requests库调用都会直接打回重写。

查看全文

http://www.jsqmd.com/news/632956/