Python 长连接服务的内存管理策略

长连接服务内存持续增长的主因是socket未及时关闭、连接数失控、大对象序列化不流式处理及心跳检测高频创建对象，需显式调用close()、用semaphore限流、流式序列化和单调时钟优化。

长连接服务中 socket 对象不及时关闭导致内存持续增长

python 的 socket 对象底层持有系统文件描述符和缓冲区，一旦建立长连接但未显式调用 close()，对象即使被变量引用释放，也可能因循环引用或异步框架延迟回收而滞留。常见现象是 ps aux 显示进程 RSS 持续上涨，gc.get_objects() 能查到大量未销毁的 socket 实例。

• 务必在连接断开逻辑末尾调用 sock.close()，不要依赖 __del__ 或 with 语句（长连接生命周期超出作用域）
• 使用 weakref.finalize() 做兜底：例如 weakref.finalize(sock, Lambda: print("socket closed"))，可快速验证是否真被释放
• 若用 asyncio，注意 StreamWriter.close() 后还需 await wait_closed()，否则 socket 可能卡在 CLOSE_WAIT

asyncio 下连接池未限制最大并发数引发 OOM

很多人以为 asyncio 是“轻量”，但每个活跃连接仍需分配 recv/send buffer、task 对象、ssl 上下文等。不限制连接数时，突发流量会瞬间拉起成千 task，内存直接飙高甚至触发 linux OOM killer。

• 用 asyncio.Semaphore 控制并发连接数，例如初始化 sem = asyncio.Semaphore(100)，在 accept 后立刻 await sem.acquire()，断开前 sem.release()
• 避免在 connection handler 中启动无限制的子任务（如 asyncio.create_task(...) 不加控制），应统一走连接池调度
• 观察 /proc/[pid]/status 中的 VmRSS 和 Threads 字段，线程数异常高往往意味着 task 泄漏

json / Protocol Buffer 序列化大对象时不流式处理造成临时内存峰值

长连接服务常需推送批量数据（如行情快照、日志聚合），若一次性 json.dumps(big_dict) 或 pb.SerializeToString()，Python 会先在内存构造完整 bytes 对象，可能比原始数据大 2–3 倍（字符串编码、中间对象开销）。

• 对大结构体改用流式序列化：JSON 场景用 json.JSONEncoder().iterencode() 配合 sock.sendall() 分块发送；Protobuf 推荐用 SerializePartialToString() + 手动分片
• 禁用 json.dumps(..., indent=2) 等美化选项，生产环境只需紧凑格式
• 发送前用 sys.getsizeof() 抽样检查序列化结果大小，超过 1MB 就该考虑分片或压缩

心跳检测逻辑里反复创建 datetime 对象和字符串格式化

每秒执行的心跳检查若写成 if datetime.now() > last_heartbeat + timedelta(seconds=30):，再配上 log.info(f"timeout at {datetime.now()}")，看似无害，但高频创建 datetime 对象和字符串会显著增加 GC 压力，尤其在万级连接时。

立即学习“Python免费学习笔记（深入）”；

• 用单调时钟替代：改用 time.monotonic() 记录时间戳，比较只做 Float 运算，零对象分配
• 日志中避免实时格式化，用 lazy Logging：例如 log.info("timeout at %s", time.time())，让 logging 模块按需格式化
• 心跳超时判断改用整数计数器（如每收到一个包 last_active_tick += 1），配合固定 tick 间隔更新，彻底规避时间对象

真正棘手的不是单点泄漏，而是多个小问题叠加：socket 忘关 + 连接数失控 + 序列化暴增 + 心跳开销，四者乘在一起，内存就不是线性涨了。上线前至少要跑一轮连接数阶梯压测，盯着 top -p [pid] 和 cat /proc/[pid]/maps | grep anon | wc -l 看匿名页增长节奏。