长连接服务内存持续增长的主因是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()后还需 awaitwait_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 看匿名页增长节奏。
