2、内存管理基础：内存分配、释放、引用计数、垃圾回收等核心概念

2.1 内存分配：从堆中获取资源的路径

内存分配是内存管理的起点。在绝大多数现代运行时（如 V8、Java 虚拟机、Python 解释器）中，对象并非直接分配在物理内存上，而是通过一层抽象的堆内存管理器进行。分配器维护一个空闲链表或空闲块索引，当程序请求一块内存时，分配器从堆中切割一块合适大小的区域返回给调用者。

分配方式通常分为两类：线性分配（bump allocation）和空闲链表分配（free-list allocation）。线性分配仅维护一个“分配指针”，新对象紧挨着上一个对象连续排列，速度极快，但只适用于年轻代等需要频繁回收的区域。空闲链表分配则遍历空闲块，寻找大小匹配的内存块，速度较慢但更灵活。

核心要点：分配速度与内存碎片化程度呈反比。线性分配快但易产生碎片，空闲链表分配慢但能复用碎片。诊断内存问题时，观察分配路径是判断性能瓶颈的第一步。

内存分配路径与堆结构 分配器 空闲链表 大小分级 线程本地缓存 分配请求 堆内存 年轻代 线性分配 Eden + S0/S1 分配指针 快速分配 老年代 空闲链表 大对象直接进入 碎片整理 返回引用 程序对象 对象头 类型指针 实例数据 对齐填充

2.2 内存释放与引用计数：谁负责归还内存

内存释放决定了对象生命周期何时结束。手动释放（如 C 语言的 free()）要求程序员精确掌握释放时机，一旦出错就会导致悬垂指针或重复释放。而现代语言普遍采用自动内存管理，其中引用计数（Reference Counting）是最直观的策略。

引用计数的核心思想是：每个对象维护一个计数器，记录当前有多少引用指向它。当引用被赋值、传递或销毁时，计数器相应增减。当计数器归零时，对象立即被回收。Python 的 sys.getrefcount()、Objective-C 的 retainCount 都是典型实现。

// 引用计数变化示例（伪代码）
Object* obj = new Object();  // refCount = 1
Object* ref1 = obj;          // refCount = 2
Object* ref2 = obj;          // refCount = 3
ref1 = nullptr;              // refCount = 2
ref2 = nullptr;              // refCount = 1
obj = nullptr;               // refCount = 0 → 立即回收

关键陷阱：引用计数无法处理循环引用。当两个对象互相持有对方的引用时，即使外部已无任何引用指向它们，计数器也永远不会归零，导致内存泄漏。这是 Python 的 gc 模块和 Swift 的 weak 关键字存在的根本原因。

2.3 垃圾回收：追踪式回收与分代策略

与引用计数的“即时回收”不同，追踪式垃圾回收（Tracing GC）不依赖计数器，而是从一组称为GC Roots的起点出发，遍历对象引用图，标记所有可达对象，然后回收不可达对象。GC Roots 通常包括：栈上的局部变量、静态变量、活跃线程、JNI 引用等。

现代垃圾回收器几乎都采用分代收集（Generational Collection）策略，基于“大部分对象朝生夕灭”的统计规律。堆被划分为年轻代和老年代：年轻代使用复制算法，因为存活对象少，复制成本低；老年代使用标记-清除或标记-整理算法，因为对象存活率高，移动成本大。

回收算法 核心思路 优点 缺点 典型应用
标记-清除 标记可达对象，清除不可达对象 实现简单，不移动对象 产生内存碎片 CMS 回收器
标记-整理 标记后将所有存活对象向一端移动 无碎片，内存连续 移动对象成本高 Parallel Old
复制算法 将存活对象复制到另一块空间 无碎片，分配高效 浪费一半内存空间 年轻代（Serial、ParNew）
引用计数 计数器归零即回收 实时性高，暂停短 无法处理循环引用 Python、Swift

2.4 内存管理中的常见误区与诊断视角

在实际开发中，对内存管理概念的误解往往比内存问题本身更危险。以下是几个高频误区：

  • 误区一：内存泄漏只发生在手动管理语言中。实际上，GC 语言中未释放的静态集合、未注销的监听器、缓存未清理等都会造成泄漏，只是表现形式更隐蔽。
  • 误区二：GC 越频繁越好。频繁触发 GC 会导致大量 Stop-The-World 暂停，表现为吞吐量下降和延迟抖动。合理设置堆大小和 GC 策略比盲目调高回收频率更重要。
  • 误区三：引用计数没有暂停。虽然引用计数是增量式的，但在处理循环引用或批量释放时，仍可能出现较长的暂停。
  • 误区四：只要内存足够就不需要关注分配。分配速率过高会导致 GC 压力增大，即使堆内存充足，CPU 时间也会被 GC 线程大量消耗。

诊断建议：当遇到内存异常时，不要急于调大堆内存。先通过 jstat、gc.log 或 perf 观察分配速率、GC 频率和暂停时间。如果分配速率极高，优先检查是否有大量短生命周期对象被反复创建；如果老年代持续增长，优先检查是否存在集合类缓存未清理或全局引用未释放。

2.5 案例复盘：一次典型的“内存泄漏”误判

某服务在压测时发现内存曲线持续上升，最终触发 OOM。团队最初怀疑是堆内存不足，将堆从 4GB 调至 8GB，但问题依旧。通过分析 GC 日志发现：

// GC 日志关键片段
[Full GC (Allocation Failure)  8192M->8120M(8192M), 2.3 secs]
[Full GC (Allocation Failure)  8192M->8115M(8192M), 2.1 secs]
// 老年代几乎无法回收，每次 Full GC 仅释放几十 MB

进一步使用堆转储分析（jmap -dump + MAT）发现，一个静态 HashMap 中累积了数百万个以 UUID 为 key 的缓存条目，且从未设置过期策略。这些条目被 GC Roots 中的静态变量引用，因此永远不会被回收。修复方案是引入带过期时间的缓存（如 Caffeine）或定期清理，问题随即解决。

这个案例说明：内存管理的核心不在于“回收得快”，而在于“谁持有引用、何时释放引用”。理解分配、引用计数和 GC 的协作关系，才能准确定位问题根源，而不是盲目调整参数。

← 上一章 📖 返回目录 下一章 →