程序在运行过程中不知不觉地占用大量内存，甚至最终因内存耗尽而崩溃，其核心原因通常在于程序对内存资源的“申请”与“释放”之间，出现了不平衡或管理失效。一个看似平稳运行的程序，其内存占用持续增长，背后往往隐藏着系统性的缺陷。导致这一问题的五大“元凶”主要涵盖：存在未被回收的“内存泄漏”、一次性向内存加载了“过量数据”、不恰当的数据结构选择导致“空间浪费”、并发场景下资源的“不当复制”、以及底层框架或第三方库的“隐性开销”。

其中，存在未被回收的“内存泄漏”，是最为经典和隐蔽的原因。它指的是，程序在运行过程中，持续地向系统申请新的内存空间来存放临时对象或数据，但在使用完毕后，因为代码中的逻辑缺陷，未能将这些不再需要的对象，从“引用链”中释放掉。这使得垃圾回收机制，错误地认为这些对象“仍在使用中”，从而永远无法回收它们所占用的内存。日积月累，这些“僵尸”对象，就会像一个“只进不出”的黑洞，悄无-声息地，吞噬掉所有可用的系统内存。

一、内存的“世界观”：程序如何使用内存

要深入理解内存为何会被“不知不觉地”耗尽，我们必须首先，对程序“如何使用内存”这一基础问题，建立一个清晰、准确的认知模型。程序的内存使用，并非一个混沌的整体，而是被清晰地，划分为两个核心区域：栈内存和堆内存，两者各司其职，遵循着截然不同的管理规则。

首先，我们来谈谈栈内存。这部分内存是由编译器或解释器进行自动管理的，主要用于存放函数的参数、局部变量以及记录函数调用的“返回地址”。栈内存的特点是空间相对较小，但分配和回收速度极快。每当一个函数被调用时，系统会自动地在栈顶为其分配一小块内存，这块内存通常被称为“栈帧”；而当函数执行完毕返回时，这块内存又会被自动地立即释放。因此，栈内存中的数据，其生命周期与函数的生命周期是严格绑定的。除了因“无限递归”而导致的“栈溢出”这种特殊情况，栈内存通常不是导致程序内存“持续增长”的根源。

与之相对的，是堆内存。这部分内存则用于存放那些更复杂、更大、生命周期也更长的“对象”，例如一个用户对象或一个包含了大量数据的列表。在Java、Python、JavaScript等具有自动垃圾回收的现代语言中，堆内存的分配（例如，通过新建对象的关键字）是由我们程序员来控制的；而其“释放”，则是由一个被称为“垃圾回收器”的系统进程来“自动”完成的。绝大多数的、不知不觉的内存占用问题，其“事发现场”，都发生在“堆内存”之中。

在整个**内存管理**的生命周期中，包含三个基本步骤：分配内存、使用内存、以及释放内存。而几乎所有难以察觉的内存问题，都出在最后一步“释放内存”上。

二、核心机制：自动垃圾回收的“智慧”与“盲区”

为了将开发者从繁琐、易错的手动内存管理中解放出来，现代编程语言，普遍引入了“自动**垃圾回收**”机制。

垃圾回收器的工作原理虽然内部算法极其复杂，但其核心思想却非常质朴，可以概括为“可达性分析”。这个过程的起点，是程序中一些被称为“根”的对象，这些“根”通常包括全局变量、当前所有函数调用栈上的局部变量和参数等。从这些“根”对象出发，垃圾回收器会像一个探险家一样，沿着对象之间的“引用”关系（例如，A对象的一个属性，指向了B对象），去遍历整个堆内存中的所有对象。通过这种遍历，所有能够从“根”对象出发，通过一条或多条“引用链”，最终被“访问”到的对象，都被认为是“存活的”、“有用的”，即“可达的”。反之，所有无法从任何一个“根”出发被访问到的对象，则被认为是“死亡的”、“无用的”，即“不可达的”。最终，垃圾回收器的任务就是将所有这些被判定为“不可达”的对象，所占用的内存空间，进行回收和清理，以供后续的程序重新分配和使用。

然而，垃圾回收器是一个极其勤勉、忠实的“清洁工”，但它，绝非一个“智能”的“业务专家”。它判断一个对象是否“存活”的唯一标准，就是技术层面的“可达性”，而无法，从“业务逻辑”的层面，去判断一个对象，是否“仍然被需要”。这正是导致“内存泄漏”的根本原因。一个“逻辑上”已经不再被需要的对象，如果，因为代码中的某个疏忽，仍然，被至少一个“存活”的对象（最终可以追溯到“根”）所引用着，那么，在垃圾回收器眼中，它就依然是“可达的”，因此也就永远不会被回收。

三、元凶一：经典的“内存泄漏”

基于上述原理，我们可以系统性地，识别出那些在实践中，最常见的、导致“逻辑泄漏”的编码模式。

一种经典的泄漏场景是未被移除的“事件监听器”。在图形界面或前端开发中，当你创建了一个“临时”的、用于显示某个弹窗的组件时，这个组件为了响应用户的点击，常常会向一个“全局”的、或生命周期很长的“文档对象”，注册一个“事件监听器”。当这个弹窗被关闭后，你期望这个“临时”组件应被回收。然而，因为那个“全局”的文档对象，在其内部的“监听器列表”中，还保持着对这个临时组件内部回调函数的“引用”，这就形成了一条从“全局对象”到“临时组件”的、牢固的“引用链”。只要这个全局对象存在，这个本应“死亡”的临时组件，就永远无法被垃圾回收器所回收。如果用户反复地打开和关闭这个弹窗，那么，内存中，就会堆积起成百上千个“死而不僵”的组件实例，最终，导致内存耗尽。

与事件监听器类似，一个启动后就永远不会被清除的“定时器”，如果其回调函数，引用了某个“大对象”，那么，这个“大对象”的内存，也同样，永远不会被释放。

在Java等后端语言中，**静态集合类的“陷阱”**也同样普遍。静态变量的生命周期，是与整个应用程序的生命周期相绑定的。如果为了方便，一个开发者将本地缓存实现为了一个“静态的哈希表”，并且只向其中添加数据，而缺乏一个有效的“过期”或“移除”机制，那么任何一个被添加到这个静态缓存中的对象，都将永久地驻留在内存中，直至应用程序关闭。如果这个添加操作被高频地调用，那么，这个静态缓存，就会像一个“只进不出”的容器，无休止地吞噬着堆内存。

四、元凶二：低效的内存“使用模式”

除了经典的“内存泄漏”，一些低效的、粗放的内存“使用模式”，同样，是导致程序“不知不觉”地，占用大量内存的常见原因。

最典型的问题就是数据的“全量”加载。例如，试图将一个大小为2个G的日志文件或数据文件，一次性地，全部读取到一个“字符串”或“字节数组”变量中；或者，执行一个数据库查询，在没有进行“分页”或“条件限制”的情况下，返回了一个包含了数百万行记录的结果集，并试图将其全部加载到内存中。这些操作，都会瞬间向操作系统申请巨大的堆内存，不仅可能会因为内存不足而直接失败，更会给垃圾回收器带来巨大的压力，引发长时间的程序卡顿。对于所有“大数据量”的处理场景，都必须强制性地采用“流式处理”或“分批处理”的模式，例如逐行读取文件，或使用分页查询来处理数据库结果。

另一个常见的问题，源于字符串的“不可变性”与拼接。在Java等语言中，字符串是“不可变”的。这意味着，任何对字符串的“修改”（例如，拼接），都不会在“原地”进行，而是会创建一个全新的字符串对象。如果在一个需要执行十万次的循环中，使用加号来反复地进行字符串的拼接，这个看似简单的操作，会在内存中创建出十万个临时的、无用的、中间态的字符串对象。这会极大地增加内存的消耗和垃圾回收的负担。在需要进行大量字符串拼接的场景下，必须使用像StringBuilder这样，专门为“可变字符串”而设计的、更高效的工具类。

五、诊断与预防

要系统性地，与内存占用问题作斗争，我们需要一套“诊断”与“预防”相结合的组合拳。

在诊断方面，内存分析器是发现问题的最强大工具。它能够，在程序的某个时间点，生成一份完整的“堆内存快照”。这份快照，详尽地记录了，在那个瞬间，内存中到底存在着哪些“对象”，每个对象占用了多大的空间，以及最重要的——这些对象是被谁所“引用”着的。通过在程序运行的不同时间点，生成两份或多份堆内存快照，然后，对它们进行对比分析，我们就可以清晰地看到，是哪些类型的对象，在持续地、只增不减地占据着内存。然后，再沿着这些“可疑”对象的“引用链”，向上追溯，我们通常就能最终地定位到那个导致它们“无法被释放”的“罪魁祸首”。

在预防层面，则需要将“内存意识”融入到团队的日常流程和规范中。首先，代码审查是一个重要的环节，审查者应特别关注那些可能导致资源不被释放的“高危”代码模式，例如静态集合的使用、事件监听器的注册以及定时器的启动。其次，团队应建立一条铁的编码规范，即资源管理的“配对”原则：任何一种“申请”或“订阅”资源的操作，都必须有一个明确的、与之配-对的“释放”或“取消订阅”的操作，并且，这个“释放”操作，必须被放置在一个能够被“保证执行”的代码块中。最后，压力测试也是必不可少的环节，通过在项目发布前，进行长时间的、高负载的压力测试，是提前暴露那些“缓慢的、不易察觉的”内存泄漏的、最有效的手段。

在实践中，当一个严重的内存泄漏问题被发现时，应立即地，在像 PingCode 这样的研发管理工具中，为其，创建一个最高优先级的“缺陷”工作项，并将相关的“堆内存快照”分析报告，作为附件上传。而在一个数据密集型的项目规划之初，也应在 Worktile 的项目计划中，明确地，设立专门的“内存压力测试”和“性能优化”的任务节点。

常见问答 (FAQ)

Q1: “内存泄漏”和“内存溢出”有什么区别？

A1: “内存泄漏”，是“原因”。它指的是，程序中，那些不再被需要的内存，因为逻辑错误，而无法被系统回收的过程。而“内存溢出”，则是“结果”。它指的是，因为持续的内存泄漏，或一次性申请了过大的内存，而最终导致，程序耗尽了所有可用的内存，并因此而崩溃的现象。

Q2: 像Java或Python这样有自动垃圾回收的语言，为什么还会发生内存泄漏？

A2: 因为，垃圾回收器，其判断一个对象是否“可被回收”的唯一标准，是“该对象，是否，仍然，存在任何一个有效的‘引用’链条，能够从根节点，访问到它”。它并不具备，从“业务逻辑”上，去判断一个对象是否“不再被需要”的能力。内存泄漏，正是利用了这一点，通过一个“无用”但却“有效”的引用，来“欺骗”了垃圾回收器。

Q3: 什么是“堆”内存和“栈”内存？

A3: “栈”内存，是用于存放函数调用信息和局部的、小的、简单类型变量的，由系统自动管理的、小而快的内存区域。而“堆”内存，则是用于存放对象实例等复杂的、大的、生命周期更长的数据的、需要由垃圾回收器来管理的、大而相对慢的内存区域。

Q4: 我应该如何使用代码审查来发现内存泄漏？

A4: 在代码审查中，应特别地，像“审计”一样，去关注那些“资源申请与释放的对称性”。看到一个“添加监听器”的操作，就要下意识地，去寻找，与之对应的“移除监听器”，是否在合适的时机（例如，组件销毁时），被调用了。看到一个向“全局”或“静态”集合中，添加元素的代码，就要立即质询：“在何种机制下，这些元素，会被从这个集合中，移除出去？”

原创文章，作者：十亿，如若转载，请注明出处：https://docs.pingcode.com/baike/5215002