Python · 内存管理与垃圾回收

场景 1 · 服务内存只涨不降, 定位增长点

现象: Python 服务 RSS 每天涨 200MB。用 tracemalloc 两个时间点快照对比, 精确到代码行:

import tracemalloc
tracemalloc.start()
snap1 = tracemalloc.take_snapshot()
# …… 跑一段时间 / 处理一批请求后
snap2 = tracemalloc.take_snapshot()
for stat in snap2.compare_to(snap1, 'lineno')[:10]:
    print(stat)   # 输出: 文件:行号  增量字节数  增量块数

常见凶手: 模块级 list/dict 当缓存只进不出、异常对象带整条 traceback 被存进日志集合、闭包捕获了大 response。

场景 2 · 百万实例的内存优化

风控特征服务加载 300 万个实体对象, 默认 dict 布局 ~1.9GB, 三板斧降到 ~0.9GB:

class Feature:
    __slots__ = ('uid', 'score', 'tags')   # 1. 去掉实例 dict

features = [Feature(*row) for row in cursor]     # 2. 惰性分页加载, 别一次全进内存
tags = tuple(t for t in raw_tags)                # 3. tuple 代替 list (省 header + 不可变可共享)

场景 3 · 缓存必须有上限和过期

无上缓存的缓存 = 定时炸弹。函数级用带 maxsize 的 lru_cache, 服务级用 cachetools:

from functools import lru_cache

@lru_cache(maxsize=100_000)            # 有上限! 不写 maxsize=无界
def get_region(ip): ...

from cachetools import TTLCache
cache = TTLCache(maxsize=50_000, ttl=300)   # 容量 + 过期双保险

场景 4 · 服务启动内存基线优化

import 即占内存: 一个 Flask 应用顶层 import pandas 就白吃 80MB。重依赖延迟到真正使用的函数内:

def export_endpoint():
    import pandas as pd        # 首次调用才加载: 不用该功能的部署省 80MB+
    df = pd.read_sql(...)
    return df.to_csv()

# 验证基线: python -X importtime app.py 2>&1 | sort -t'|' -k2 -rn | head

场景 5 · 大 JSON 响应的序列化降耗

网关聚合接口返回几 MB JSON, 换 orjson(Rust 实现)吞吐 5-10 倍、峰值更低, 还省二次编码:

import orjson
from fastapi import Response

@app.get("/aggregate")
def aggregate():
    data = build_big_payload()                     # dict/list 结构
    return Response(orjson.dumps(data),   # 直接产 bytes
                    media_type="application/json")

场景 6 · DataFrame 分块流式聚合

分析任务别一次 read_csv 整个文件: chunksize 迭代 + 只读需要的列, 内存从 O(文件) 降到 O(块):

total = 0
for chunk in pd.read_csv("events.csv", chunksize=100_000,
                        usecols=["user_id", "amount"]):   # 只读两列
    total += chunk.groupby("user_id")["amount"].sum()
result = total.groupby(level=0).sum()             # 分块部分和再合并

场景 7 · 超大文件 mmap 内存映射

几 GB 的模型/索引文件不全读进内存, 按页惰性加载, 多进程共享同一份物理页:

import mmap, struct

with open("index.bin", "rb") as f:
    mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
    def read_record(i):
        off = i * 16                              # 访问哪页, OS 才载哪页
        return struct.unpack_from("<qd", mm, off)  # (id, score)
    # fork 出的 worker 共享同一物理页 → 内存 ≈ 单份

场景 8 · 常驻服务 gc 调参(Instagram 方案)

预热完成后大部分对象永远活在 gen2, 每轮全代扫描白费 CPU — 冻结常驻对象 + 调大阈值:

def on_warmup_complete():            # 预热请求打完后调用一次
    gc.collect()                       # 先收一轮干净
    gc.freeze()()                   # 常驻对象移出扫描集 (PEP 570+)
    gc.set_threshold(50_000, 50, 50)  # gen0 阈值 700 → 50k: 扫描少 70 倍

场景 9 · 资源生命周期统一 with 收敛

泄漏大头是"忘关": 文件、连接、游标全部上下文管理器化, 旧 API 用 closing 包:

from contextlib import closing

with closing(make_legacy_client()) as client:   # 老库没有上下文协议也能保证 close
    client.send(payload)
# review 清单: 每个 acquire 必须配 with / try-finally, 无裸 open/connect

场景 10 · 多 worker 共享只读大模型

8 个 worker 各载 2GB 模型 = 16GB; fork 前(或启动早期)加载, COW 共享物理页:

# master.py — 先加载再 fork worker (gunicorn preload 等价)
MODEL = load_2g_model()              # 顶层加载
def handle(req):
    return MODEL.predict(req)        # 只读不写 → COW 页不复制 → 8 worker 仍 ≈ 2GB
# gunicorn --preload app:app 即此模式; 写操作会触发页复制, 保持模型只读