tornado长连接内存泄漏的根本原因是连接生命周期管理失控：socket未显式关闭、心跳高频创建临时对象、大消息非流式序列化；必须显式调用close()和close_fd()，用weakref.finalize兜底，禁用datetime.now()改用time.monotonic()，心跳改全局定时器，大消息须流式编码，全程配合memory_profiler监控。
为什么Tornado长连接会悄悄吃光内存
根本原因不是框架本身，而是连接生命周期管理失控：socket对象未显式关闭、心跳逻辑高频创建临时对象、大消息体序列化不流式处理。Tornado的IOLoop虽能支撑万级并发，但每个连接背后若持有未释放的socket、缓冲区或闭包引用，内存就会线性增长，最终触发Linux OOM killer。
必须显式调用close()，不能只靠on_close()
Tornado的on_close()是回调钩子，不等于资源释放。socket底层文件描述符和接收缓冲区仍驻留，尤其在异常断连（如客户端强制kill）时，on_close()可能根本不执行。
- 在
on_message()或业务逻辑中，一旦判定连接需终止（如认证失败、协议错误），立刻调用self.close()，并紧接着调用self.stream.close_fd()（若使用IOStream） - 用
weakref.finalize()做兜底验证：weakref.finalize(self.stream, lambda: print("stream freed"))，上线前跑压测，看日志是否真触发 - 避免在
on_close()里做耗时操作（如写DB、发HTTP），它运行在IOLoop线程，阻塞会拖垮整个事件循环
datetime.now()在心跳里是内存杀手
每秒对万级连接执行datetime.now() + 字符串格式化，等于每秒生成上万个datetime对象和临时字符串，GC压力陡增。这不是“小开销”，是长连接服务的典型隐性泄漏点。
- 改用单调时钟：
time.monotonic()代替datetime.now()，它返回浮点数，无对象构造开销 - 心跳超时检查写成：
if time.monotonic() - self.last_heartbeat > 30.0:，不拼接日志字符串，只在真正超时时才记录 - 把心跳计时器从每连接独立逻辑，改为全局单次定时器（
IOLoop.call_later(1.0, check_all_heartbeats)），批量扫描，减少定时器数量
大消息推送必须流式序列化
行情快照、日志聚合这类场景，若用json.dumps(big_dict)一次性编码，Python会在内存中先构造完整bytes对象，峰值内存可达原始数据的2–3倍——这对长连接服务是致命的。
- 用
json.JSONEncoder配合iterencode()流式输出：for chunk in json.JSONEncoder().iterencode(big_dict): self.write(chunk) - Protocol Buffer推荐用
SerializePartialToString()替代SerializeToString()，跳过字段校验，减少中间对象 - 发送前预估大小：用
sys.getsizeof()粗略判断，超阈值（如512KB）直接拒绝或分片，别让单次write扛住整个对象
最难的不是写对代码，而是让每个连接的资源释放路径可验证、可监控。上线前务必用memory_profiler按行抓内存增长点，重点盯stream、buffer、encoder相关行——这些地方出问题，不会报错，只会安静地拖垮整台机器。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
