线上服务又崩了，登录日志齐刷刷地堆到半夜三点，中间断档的那几分钟，就是进程被系统用 SIGSEGV 干掉的时间。点开 core dump，栈上全是同一个函数名，一层套一层，套了几千层没到头——不用猜，栈溢出。隔壁团队更惨，服务没崩，但内存像拧不紧的水龙头，跑一周就得重启一次，不然看着监控曲线心里发慌。

这两类问题——栈溢出和内存泄漏——几乎是每个写 C/C++、甚至写 Java、Go 的人都会撞上的墙。我见过不少同学把“栈”和“堆”挂在嘴边，可真到排查的时候，连栈帧长什么样、栈容量由谁决定、泄漏到底漏在哪一步，都说不清。这篇就把这三个概念一次讲透，讲完你能明白它们的前因后果，也能拿着现成的排查思路去处理真实故障。

1. 先搞明白：栈到底是什么

1.1 不是“堆栈”的那个“栈”

很多人一听到“栈”，脑子里蹦出来的是数据结构里的“堆栈（Stack）”，什么先进后出、压栈弹栈，这没错，但程序运行时用到的栈，和数据结构里的栈是两码事，虽然它俩在抽象行为上确实一个样：后进先出。

进程里的栈，是一块由操作系统分配、由编译器自动管理的内存区域。它的核心用途是配合函数调用：你每调用一个函数，系统就在栈上“压入”一块区域，用来放这个函数的局部变量、参数、返回地址、保存的寄存器现场等。当函数返回时，这块区域被整体弹走，什么都不用你操心。这也是为什么局部变量在函数结束后就“消失”了。

这块内存区域有一个非常关键的属性：它是线性的、固定大小的。线性是说它的地址从高到低连续延伸；固定大小是说它有一个上限，这个上限在进程创建时基本就定死了。所以栈本质上就是一段“预分配好的临时工位”，谁来谁用，用完即走，但工位总数有限。

注意区分：栈上的分配和释放完全由编译器在幕后生成指令完成，不需要你手动管理。这和堆上需要 malloc/new 手动申请、free/delete 手动释放是完全不同的路径。理解了这一点，才能理解为什么“栈上不会泄漏”——因为栈根本没有“长期持有”的概念。

1.2 栈帧：每一次函数调用都租了一间房

我们常说的“栈帧（Stack Frame）”，就是一次函数调用在栈上占用的那一整块区域。你可以把进程的调用栈想成一摞租房合同：main 函数先签一份，它调用 funcA，又签一份叠在上面，funcA 再调用 funcB，再叠一份。当前正在执行的函数永远在最顶层。

每一份栈帧里一般装着这几样东西：

• 返回地址：函数执行完后，回到调用方下一条指令的地址。这是栈溢出攻击里最常被盯上的目标。

• 保存的寄存器值：比如 ebp/rbp、以及被调用方需要用到的其他寄存器，为了恢复现场。

• 局部变量：包括值类型的局部变量、数组、结构体，以及引用类型变量本身（在 Java 里是引用，在 C++ 里可能是对象本体）。

• 函数参数：参数按调用约定放入寄存器或栈上。

一个函数被调用时，栈指针（SP）往下挪，腾出这块空间；函数返回时，SP 挪回来，这块空间宣告失效。所有这一切都在纳秒级别完成，所以栈的效率极高，比堆上的动态分配快了一个数量级都不止。

但代价就是：栈帧在函数没有返回之前，会一直压在栈上。如果 funcA 调用 funcB，funcB 又调用 funcC，funcC 又调用 funcA……只要它们互相不返回，栈帧就会一层层叠高，直到把栈的固定容量用完，这就是栈溢出的直接物理成因。

2. 栈容量：那一块固定尺寸的“临时工位”

2.1 默认栈大小到底是多少

很多程序员写代码写了一两年，从没关心过自己的进程栈到底有多大。直到遇到一次崩溃，才好奇地去查，哦，原来还有这种东西。

不同操作系统、不同编译环境下默认的栈大小差别很大，我列几个最常见的：

看到没有，Windows 上默认只有 1MB，特别容易踩栈溢出；Linux 主线程的 8MB 看着不小，但如果你的递归函数里每个栈帧占地很大，一样分分钟爆掉。

这里要特别注意一个坑：主线程和子线程的栈大小往往是分开设置的。Linux 下创建线程时，pthread_create 可以传入 attr 指定栈大小，默认值是 8MB；但如果你的系统是嵌入式环境，或者你用了一些轻量级线程库，默认栈可能只有几十 KB。嵌入式设备上跑代码，我吃过一个亏，一个看起来人畜无害的递归函数在 PC 上跑得好好的，搬到开发板上直接崩，查了半天，发现板子上的默认线程栈只有 64KB。

2.2 栈容量可以改吗

可以，但分情况。

• 主线程栈大小：Linux 下通常由启动时的 ulimit -s 决定（软限制），你可以在 shell 里用ulimit -s unlimited临时放开，也可以写死在程序里，通过 setrlimit 修改。但生产环境中一般不建议把这个值调得太离谱，栈太大意味着每个线程都预留着巨大的虚拟地址空间，线程数量多了，虚拟内存占用会非常难看。

• 子线程栈大小：在创建线程时通过线程属性指定。拿 C 语言的 pthread 举例：

pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setstacksize(&attr, 16 * 1024 * 1024); // 16 MB pthread_t tid; pthread_create(&tid, &attr, worker_func, NULL); pthread_attr_destroy(&attr);

• Java 虚拟机：每个线程的栈大小由 -Xss 参数控制，比如启动参数里加-Xss2m，就把每个线程的栈设为 2MB。改大有风险，改小可以让单进程起更多线程，但改太小直接启动就 StackOverflowError，得实测权衡。

• Go 语言：比较特殊，它的 goroutine 栈不是固定大小，而是小栈起步（2KB），用完就扩容，上限默认可以到 1GB。所以 Go 里写递归，只要你能撑住性能，栈空间通常不是瓶颈。

但我的个人体会是：调大栈容量永远只是缓兵之计，不是治本方案。真正该做的是搞清楚为什么你的代码需要那么深的栈——十有八九是递归没写好，或者数据结构设计有问题。

2.3 栈容量用尽前的几个信号

栈空间将满时，程序通常不会直接给你一句“栈要满了”，而是以各种形式表现出来，稍不留神就会被误判。

• 最直接的是崩溃，报错信息里出现stack overflow、Segmentation fault、StackOverflowError；

• 在嵌入式或 RTOS 环境下，栈溢出可能会表现为“神秘变量被篡改”。因为栈向低地址增长，溢出的数据会踩到栈底以下的区域，如果那片区域有其他任务的栈或全局变量，数值就突然不对了，bug 看起来像是灵异事件；

• 在 Linux 下，进程可能收到 SIGSEGV，日志里留下 core dump，用 gdb 查看时 backtrace 全是重复的调用序列；

• 更隐蔽的是，栈溢出不一定会马上崩，可能只是把返回地址改成了一个“看起来合法但其实莫名其妙的位置”，程序继续执行，行为完全错乱，之后在完全不相干的地方抛出异常。

这些信号里，最值得提防的是“变量被篡改型”溢出。因为它不崩溃、不报错，你的第一反应往往是去检查业务逻辑，甚至怀疑编译器有问题，浪费大量时间。

3. 栈溢出：大多不是“内存不够”，而是“递归太深”

3.1 经典场景一：无限递归

递归是栈溢出的头号制造者。最原生态的例子：

int sum(int n) { return n + sum(n - 1); // 忘写终止条件 }

这个函数在 n 递减到 0 之后不会停，而是继续变成负数无限调用，每次调用压一个栈帧，直到栈容量耗尽。这段代码有几层栈帧才会爆？可以做一个计算。

假设 x86_64 环境下，这个简单函数的栈帧约 32 字节（返回地址 8 字节 + 保存的寄存器 8~16 字节 + 局部空间若干）。Linux 默认栈 8MB = 8,388,608 字节。那么大约能递归：

8,388,608 / 32 = 262,144 层

看起来挺多的对吧？但如果你把局部变量加大，比如在函数里声明一个 4KB 的数组：

void work() { char buffer[4096]; work(); // 递归 }

每一层栈帧至少 4KB 出头，8MB 栈只够大约 2000 层递归。如果输入数据稍微大一点，直接爆。很多业务上的“正当递归”，比如遍历一棵深度很大的树、解析深层嵌套的 JSON，就能轻松超过 2000 层。

所以递归本身不是错，错的是你没有评估递归深度和单层栈帧大小的乘积。

一个可以快速估算的方法：单层栈帧大小 × 最大递归深度，如果这个乘积接近栈容量的一半，你就该警惕了。栈上除了递归占用的帧，还有调用方的大栈帧、临时变量等额外开销，留出充足余量。

3.2 经典场景二：大数组在栈上“安家”

递归之外的另一个高频踩坑点，是在栈上直接声明超大数组。

void process_matrix() { double data[1024][1024]; // 8 * 1M = 8MB，正正好好把 Linux 主线程栈吃光 // 做点什么... }

一个二维数组直接宣告栈死刑。这种代码在测试小规模数据时看似没问题，一旦数据量变大或者被多层函数嵌套调用，栈上同时压着多个大数组，很快就会爆掉。

这种问题的解法非常直接：大块内存不要放栈上，要么用堆上的动态分配（malloc/new），要么用静态存储区（static/global），要么用 C++ 的 std::vector（它内部在堆上）。

我知道会有同学问：“为什么编译器不能自动把这么大的数组放到堆上？”关键原因在于：栈上分配是编译期静态决定偏移量、运行时只需改一个栈指针，性能极高；如果编译器在幕后引入堆分配，就需要在函数入口插入内存分配代码，还要处理分配失败的异常路径，函数调用开销从“纳秒级”变成“微秒级”，完全破坏了栈的高效特性。所以语言设计里，这个责任坚定地留给开发者。

3.3 排查栈溢出的思路

遇到栈溢出，我的排查套路基本是固定的，你可以直接照抄。

第一步，拿到现场：如果是线上 Linux 服务，确认 core dump 开关有没有打开（ulimit -c unlimited），没开就只能靠监控日志找崩溃时的调用上下文。如果日志也缺失，建议后续在关键入口加日志，或者在测试环境复现。

第二步，复现并抓 backtrace：开发环境用调试模式编译（-g 选项），运行到崩溃点时用 gdb 看栈：

gdb ./your_program core.12345 (gdb) bt

看到一大串重复的调用，恭喜你，递归问题实锤。看到一大堆正常的调用序列但突然断了，可能就是栈上放了大数组，或者更糟——返回地址被写坏。

第三步，看递归深度和帧大小：可以从 backtrace 数出重复调用的层数，再用info frame查单帧大小，估算出总消耗。比如发现 6000 层递归，每层约 1.2KB，那就是大约 7.2MB，已经逼近 8MB 的极限。这时候你还去调大栈到 64MB？可以，但你的递归深度如果受输入控制，输入一旦变大，还会再炸。治本的办法是改写成迭代，或自建显式栈，把“深递归”变成“循环+自己的栈容器”。

我见过一个真实的案例，某团队处理一份深度约 4000 的 JSON 配置，用了一个递归解析函数，单帧约 2KB，稳定在 8MB 边缘反复横跳，一周崩两三次。后来把递归改成显式栈后，再没因为这个崩过。这个案例提醒我们，在栈容量有限的平台上，递归深度是硬约束，不是码风格问题。

4. 内存泄漏：程序“越吃越胖”的隐形病

4.1 泄漏的定义和常见路径

栈溢出还是“瞬间爆炸型”问题，内存泄漏则是“慢性中毒型”问题。它的定义很简单：程序申请了内存，但用完之后没有归还给操作系统或内存分配器，而且这块内存在代码逻辑上已经不可访问或永远不会再被释放。

我经常用一个生活化类比：去食堂打饭，你拿了一个餐盘，吃完本该放到回收处，结果你随手塞进座位底下，第二天又拿一个新盘，日复一日，食堂的餐盘越来越少，直到某天你连盘都拿不到——进程 OOM 被系统杀掉。

内存泄漏的路径，按内存管理方式不同，大概分成几类：

• 手动管理型语言：C 里 malloc 后没 free，C++ 里 new 后没 delete；每次执行这段代码都丢一块；

• 引用型语言：Java、Go、Python 里有垃圾回收，泄漏不是“指针丢失”，而是“对象明明没用了，却还被某个全局容器、缓存、监听器引用着”，导致 GC 认为它“还活着”，永远回收不了；

• 资源型泄漏：socket 文件描述符、文件句柄、数据库连接、线程——本质和内存泄漏一样，都是“拿而不还”，只是对象不是堆内存而是系统资源。

4.2 为什么内存泄漏非常隐蔽

内存泄漏最折磨人的地方在于：它不会立刻报错。程序第一次运行，内存还充足，完全不觉得有问题。泄漏速度慢的话，可能要几小时甚至几天才会出症状。等发现时，进程 RSS（常驻内存）已经几十个 GB，系统频繁换页，服务响应变慢，甚至直接被 OOM Killer 杀掉。

我总结过泄漏的“三段式症状曲线”：

• 初期：内存缓慢爬升，业务无明显异常，监控如果不看趋势根本发现不了；

• 中期：GC（如果有）压力增大，频繁 Full GC，响应延迟升高，CPU 利用率异常；

• 末期：内存达到阈值，进程 OOM 崩溃或系统响应瘫痪。重启之后一切正常，但过段时间再次循环。

这种“循环性崩溃”最迷惑人，因为你看系统日志，重启前没有任何明显报错，重启后一切正常，第一反应往往是“是不是有人上线了什么新配置”，实际上就是泄漏在慢慢发作。所以团队里如果服务每隔固定时间就会卡死或重启，内存趋势图是一定要第一时间看的。

4.3 常见泄漏场景一：忘记释放或引用丢失

C 代码里最简单的泄漏：

char *read_config(const char *path) { char *buf = malloc(4096); // 读文件... return buf; // 调用方必须记得 free } void process() { char *data = read_config("a.conf"); // 用一下 data // 忘!记!free! }

每次调用 process，4096 字节的堆内存就丢了。这段代码在循环里跑一万次，丢 40MB。这种问题在 C 语言初学者的代码里极其常见，特别是“返回局部堆指针”的函数风格，容易让人忘记当初是谁分配的内存。

C++ 里对应的坑是 raw pointer：

auto* obj = new Widget(); // 用完了，但没人 delete obj;

解决方案相对成熟：用 RAII，用智能指针。std::unique_ptr 和 std::shared_ptr 能把释放动作绑定到对象生命周期上，作用域结束自动析构。一个团队如果还允许裸 new/delete 随意飘散，内存泄漏基本是必然的，只是时间问题。

4.4 常见泄漏场景二：静态容器无限增长

这种泄漏在 Java/C++/Python/Go 里都常见，而且隐蔽性更强。文档上这不是“传统泄漏”，它其实是有根的，但在逻辑上它是无效数据，被容器无限收集。我举一个 C++ 的例子：

std::map<std::string, std::string> g_cache; void cache_response(const std::string& key, const std::string& body) { g_cache[key] = body; }

如果这个 cache 的 key 是不断变化的东西（比如带时间戳的 URL 参数），那每次调用都会往 map 里塞新键值对，但从来没有人清理过期条目。从 C++ 内存管理的角度看，map 节点都是“活”的，没有泄漏；但从业务生命周期看，这些数据早就没用了，占着内存不放，这就是逻辑泄漏。

这类问题在 Go 里也有。比如把一个 channel 的接收结果 append 到全局 slice，但没有按需清理尾部；Python 里全局 dict 存了每次请求的临时对象，一样。

排查这类问题，光靠 malloc/free 对不上账的工具是不够的，你得盯住那些“只增不减”的容器。我们团队以前有个服务，每天半夜 0 点内存暴涨不回落，查了半天，发现是定时任务往全局 map 里塞当天日志统计，从不清除上一天的。一个晚上的数据几 GB。

4.5 常见泄漏场景三：回调/事件监听器没注销

这个坑在 GUI 程序和事件驱动服务里特别常见。你在某个全局事件中心注册了一个回调，持有某个大对象的引用，但对象生命周期结束时，你忘记把回调注销了。于是这个“已经死了”的对象一直被回调中心强引用着，没法被 GC 回收。

典型的场景：

class Player { public Player() { EventBus.register(this); // 把自己注册进全局事件总线 } } // 玩家下线，Player 对象本应被回收 // 但 EventBus 还握着它的引用，永远收不掉

每次玩家上线创建一个 Player、注册一次监听，下线时没人注销，内存就多一份残留。线上游戏服务器跑几天内存几个 GB，全是这种“幽灵玩家”。

排查这种泄漏，认真留意“注册”与“注销”是否成对出现。凡是有 addListener/register/subscribe 的地方，必须有对应 removeListener/unregister/unsubscribe 的路径。如果代码里只有注册没有注销，别犹豫，这就是泄漏源。

5. 栈溢出和内存泄漏的伴生关系

5.1 泄漏把堆挤爆，栈也受影响

有些人以为栈和堆是两块井水不犯河水的内存区域，实际上它们共享同一个地址空间里的物理内存，只是使用方式不同。

在 Linux 上，进程的虚拟地址空间布局大概是：低位是代码段和数据段，往上是堆（低地址向高地址增长），再往上是一片映射区（共享库、mmap 区域），最高地址那头是栈（高地址向低地址长）。堆往下顶，栈往上压，中间是自由空间。正常情况下两者离得很远。

但当堆内存泄漏越来越严重时，堆不断向高地址扩张，映射区跟着移动，栈可以使用的地址空间区域就会被压缩。如果你的程序同时是栈“大户”（深层递归、大栈帧），一不留神就触发栈溢出。某些场景下，你可能看到一个“莫名其妙”的栈溢出崩溃，追根溯源，其实根因是堆泄漏导致整个地址空间布局被破坏。

在 32 位系统上这个问题尤其致命，因为整个地址空间只有 4GB，堆和栈之间的可分配空间很小。可能你的栈本身没有逻辑错误，就是被堆挤得没地方站了。这也是为什么现在新开发的服务基本都要求 64 位——不仅仅是为了能用大内存，更是为了给栈和堆留出足够的隔离度。

5.2 一个典型崩溃现场的拆解

我把一个真实事故的排查过程拆给大家看，这是理解两者伴生关系最好的教材。

某服务运行 7 天后崩溃，当时内存趋势如下图（描述，不配图）：第 1 天 RSS 2GB，第 3 天 5GB，第 5 天 9GB，第 7 天冲上 14GB 后 OOM。崩溃时日志显示的是“std::bad_alloc”或“Cannot allocate memory”，但开发团队一开始以为是内存不够用了，简单粗暴地把容器内存配额从 16GB 调到 32GB，结果 9 天后又崩了。

后来认真做 heap profile，发现是某个地图数据结构里的 key 使用了带毫秒时间戳的字符串，导致每秒钟新增一条记录，无人清理。这就是典型的逻辑泄漏。泄漏问题解决后，内存稳定在 3GB 左右，再也没崩过。

这个案例告诉我们的道理是：不要把系统物理内存不足当成第一怀疑对象，先怀疑你的程序有没有泄漏，再怀疑配额。调大内存只是拖延问题，泄漏不解决，调多大都不够。

6. 排查工具与日常预防

6.1 栈溢出的排查工具

栈溢出的排查工具相对基础，重点在“重现现场”。

• gdb：Linux 下最通用的调试器。崩溃后bt看调用栈，info frame N看指定帧的大小。如果要看某个局部变量的内容，用frame N切换过去info locals。

• AddressSanitizer（ASan）：编译时加-fsanitize=address，它会在栈上布置 redzone（警戒区），一旦写入越过边界，立即报告。对定位“栈上大数组越界”问题极其高效。代价是运行效率明显下降，适合测试环境，不适合生产长期开着。

• valgrind --tool=memcheck：能检测栈上的未初始化读取和越界访问，但速度较慢，一般用于复现问题的小用例。

验证栈溢出的一个简易方法是：在可疑函数入口打印当前栈指针地址（取局部变量的地址即可），递归深度增加时观察地址变化趋势，如果地址已经逼近栈底（线程的栈底需要查 pthread_attr_getstack 获得），就说明快溢出了。

6.2 内存泄漏的排查工具

内存泄漏的工具选择，取决于你的语言和平台。

Valgrind 的--leak-check=full会直接告诉你哪一行分配的内存在退出时仍被持有，这是最简单的“先跑一遍再修”的闭环。不过要注意：Valgrind 慢得感人，不适合大流量服务在线开，适合把触发泄漏的测试用例摘下来单独跑。

Java 这边，最经典的路径是：发生 OOM 时让 JVM 自动 dump 堆（-XX:+HeapDumpOnOutOfMemoryError），再用 MAT 打开，查看“Leak Suspects”报告，它会自动帮你找“该对象不该活着但还活着”的集合。VisualVM 可以在线观察堆内存曲线，适合复现场景。

Go 这边，pprof 的 heap profile 用起来非常简单：

import _ "net/http/pprof" // 在代码里开一个 HTTP 端口 // 通过 go tool pprof http://localhost:6060/debug/pprof/heap 拿到 profile // 在交互界面输入 top，就能看到内存占用最大的调用点

它的好处是可以在生产环境短暂开启（按需拉取样），不影响业务的长时间稳定运行。

6.3 日常预防：把问题消灭在编码阶段

工具是事后止损，真正高效的做法是把风险在编码阶段就按住。我这几年的经验，预防措施集中在下面几条。

第一，约定栈内存使用规范。不要在大函数里声明超大数组；如果数组大小不是编译期常量，直接用堆分配；递归函数里避免声明大局部变量；对递归深度设置阈值检查，超过比如 1000 层直接抛异常终止，防止悄悄炸穿栈。

第二，C/C++ 全面转 RAII。容器用标准库容器，资源用智能指针，禁止裸 new/delete 散落在业务代码里。代码 review 时如果看到裸 new，必须解释清楚为什么不能用 unique_ptr、为什么生命周期超出了作用域。我见过太多“我很懂 RAII 但代码里全是 new”的情况，说到底还是习惯问题。

第三，建立内存增长告警。每个服务都要有 RSS 的监控曲线，设置增长率和绝对阈值告警。增长率的告警最重要——就算当前内存 2GB 看起来不高，只要每小时稳定涨 100MB，这就是一颗定时炸弹。这类告警能在代码 bug 变成线上事故之前，提前几天暴露问题。

第四，定期做 heap dump 对比。我的习惯是每周拉一次内存在低峰期和高峰期的 heap profile 对比，如果发现某些容器在高峰期的内存占用是低峰期的 5 倍以上，就重点查它的生命周期管理。很多逻辑泄漏，都是靠这种对比发现的。

第五，用测试用例覆盖资源释放路径。如果你有错误处理分支，确保错误分支也释放资源。常见的泄漏点恰恰在那些“异常返回路径”上——正常路径 free 了，异常路径直接 return，内存就丢在那里了。写单测时故意触发异常分支，配合 Valgrind 跑一遍，能捞到不少漏网之鱼。

7. 写在最后：我的三点经验

做完各种线上故障排查之后，我对栈容量、栈溢出和内存泄漏这三者的理解，浓缩成了几条个人体会，供你参考。

栈溢出往往是“写的时候爽，排查的时候疯”。递归写起来特别优雅，三行代码搞定一个复杂遍历，但上线之后深度一高就崩。如果你在写递归时，心里从来不想“这个函数最大会被调用多深”，那基本确定在埋雷。我自己的标准是：业务代码里递归深度超过几百层的地方，全都改成迭代或者显式栈，不仅栈安全，调试还方便，backtrace 一眼能看到当前走到哪一步了。

内存泄漏不是“内存的问题”，而是“生命周期管理的问题”。每次看到泄漏，不要只盯着 allocate 和 free，要多问一句：这块数据的生命周期和谁的绑定？它应该在哪个环节失效？如果你能把“何时创建、何时销毁、谁持有引用”写清楚，泄漏基本不会发生。反过来，这种分析能力对设计高并发、长生命周期的服务也是一种核心能力。

堆和栈是同一片战场的两个方向。只看一面往往会误判，我看到过太多因为“内存不足”就去调实例配置的团队，折腾一圈没解决，最终发现是代码泄漏。排查内存类问题时，你的第一反应应该是“先看堆的增长规律、再看栈的调用深度”，而不是“直接加内存”。调配置只能掩盖问题，让下一次事故来得更猛烈。

最后分享一个小技巧：排查内存问题时，养成“先抓趋势、再看峰值”的习惯。不要被某一个时刻的内存曲线吓到，先把整段时间的趋势拉出来，计算斜率，就能快速判断它是泄漏（持续上升）还是波动（有涨有跌）。再结合对象分布或者调用栈，基本能一击命中根因。这几个概念看似基础，但把这些基础彻底搞透，比背一百个高级特性更值钱。