写过几年 Python 的人，大概率都遇到过这样的场景：服务跑着跑着 RSS 持续上涨，top 里的内存占用曲线像一条不肯回头的射线；或者某个看似无害的缓存列表，把几十 GB 的内存吃得干干净净。很多人第一反应是"Python 就是慢、就是吃内存"，但真正的问题往往不在语言本身，而在我们对它内存模型的理解是否到位。
Python 的内存管理是一套混合策略：以引用计数为主干做即时回收，用分代垃圾回收兜底处理引用计数无法覆盖的循环引用，再通过小整数缓存、字符串驻留、空闲链表等机制降低高频小对象的分配成本。这三者叠加，构成了一个看似简单、实则细节丰富的运行时。本文从源码行为出发，结合生产环境的真实案例，把这套机制讲透。
深夜两点，告警群突然炸了：某核心服务的堆内存使用率连续 30 分钟超过 95%，Full GC 频率从平时的每 40 分钟一次飙升到每分钟数次，接口 P99 从 120ms 恶化到 3s，紧接着节点开始轮番 OOM 重启。这类场景对每一个后端工程师来说都不陌生。本文以一次真实的生产内存泄漏事故为蓝本，完整复盘从「发现异常」到「定位根因」再到「止血与根治」的全链路排查过程，重点讲清楚 jstat、jmap、jstack、MAT 这些工具各自该在什么时机用、能拿到什么证据、如何互相印证。
拿到告警后的第一件事不是急着 dump 堆，而是先回答三个问题：这是内存泄漏，还是内存本来就不够？是 Full GC 频发导致的暂停，还是年轻代晋升压力过大？是单点问题还是全集群问题？
很多工程师对 GC 的认知停留在「STW 越小越好、吞吐量越大越好」的口号层面，一到生产环境就凭感觉堆参数。实际上，不同垃圾收集器的核心差异在于内存布局、对象标记/复制算法、并发阶段与暂停模型的组合方式。同样一份负载，在 CMS 上表现良好的配置原封不动搬到 ZGC 上反而会拖慢吞吐量；反过来，一个「大堆、低延迟」的诉求如果硬套 Parallel Scavenge，几乎注定要经历周期性长暂停。
理解演进，本质上是理解一个约束条件的逐步解除过程：CMS 试图在分代假设下并发做掉大部分标记与清除，但受限于「标记-清除」的内存碎片与「并发标记-再标记」的漏标补偿；G1 用 Region 化布局 + 可预测停顿的增量回收 + 复制式整理，把停顿从「堆大小相关」拉回到「回收集大小相关」；ZGC 则用染色指针与读屏障，把「并发整理」推向极致，让停顿收敛到与堆大小基本无关。 这一路走来，每一代都在解决上一代最痛的短板，也都引入了新的运维复杂度。