1. 项目概述为什么要啃下堆内存管理这块硬骨头堆内存管理这个话题说大不大说小不小。说它小是因为日常写业务代码的时候绝大多数人根本碰不到它——malloc/free、new/delete随手一调内存的申请和释放就交给运行时库去处理了。说它大是因为一旦你开始接触嵌入式开发、高性能服务器、游戏引擎、数据库内核或者哪怕只是准备一场偏底层的技术面试堆内存管理立刻就会变成绕不开的关卡。面试官爱问是因为它能把基础是否扎实、是否真读过底层源码、有没有实际排查过内存问题的经验一次性全部暴露出来。项目里遇到内存碎片、内存泄漏、分配延迟抖动最终也都要回到堆管理器的工作机制上找答案。这份复习笔记就是围绕“堆内存管理核心逻辑”来梳理的。不会去逐行读某个特定分配器的源码——那样太劝退了——而是把堆内存管理要解决的几个核心问题拆开讲透堆从哪里来、内存块怎么组织、分配器如何快速找到合适的内存块、释放之后内存又去了哪里、为什么会有碎片、线程安全怎么做、mmap 和 brk 的分界线到底在哪。内容定位在“原理 关键数据结构 流程拆解 排查思路”这个粒度适合三类人阅读准备校招或社招、需要系统过一遍内存管理知识点的同学正在学 glibc/ptmalloc 源码但觉得入门困难、想先有全局框架再深入代码的开发者以及在实际项目中遇到了内存问题、想搞清楚底层机制以便定位问题的同行。文章从我对堆管理器的理解讲起会穿插一些实际的参数、阈值和计算过程也会把我在排查内存问题过程中踩过的坑放进来。我个人是建议配合 gdb、perf 和 glibc 源码一起看这篇笔记效果会更好。2. 堆内存管理到底在管什么先建立全景视图2.1 认识堆它不是一块简单的空闲内存在讲管理逻辑之前先得把“堆”这个概念和“堆内存”的关系捋清楚。在很多开发者的印象里堆就是一段很大的、可以通过malloc按需取用的内存区域这不算错但不够精确。从进程地址空间的角度看堆是位于数据段BSS / Data和内存映射段之间的一块动态扩展区域。它的边界由两个指针刻画一个是start_brk指向堆的起始地址通常这个地址在进程生命周期内不会变化另一个是brkprogram break指向堆当前结束的位置。brk是可以移动的内核通过brk()系统调用允许进程调整这一边界从而实现堆的扩张与收缩。以 Linux 下的 glibc 为例当堆空间不够时分配器会调用sbrk()或brk()向内核“购买”更多内存当释放的内存足够多时堆顶可能被回缩将页面还给操作系统。这里有个很容易被忽略的细节操作系统给分配器的内存粒度是“页”通常是 4KB而应用通过malloc申请的最小单位往往只是几十字节。也就是说在进程和内核之间隔着一个处于中间层的用户态堆管理器它负责把从内核拿到的整块内存进行二次切分、登记、分配和回收。堆内存管理的核心逻辑本质上是这个“中间商”的内部运作机制。2.2 分配器的三个核心目标和一组矛盾理解堆内存管理先要理解它要解决的问题。把分配器看成一个负责内存出租的房东它有三个核心目标第一分配速度快。每次malloc的开销必须尽量小尤其在高频分配场景下慢 100ns 和慢 1us 的差距都会被放大到肉眼可见。第二内存利用率高。不能让大量内存因为碎片化而闲置也不能让管理结构本身占用太多额外空间。第三释放可复用。free释放掉的内存要能尽快被后续的分配请求复用而不是把内存还给操作系统——因为还回去再申请回来代价很高。这三个目标之间存在明显的矛盾要分配快就得多预留一些内存块甚至维护复杂的缓存结构这会牺牲内存利用率要最大化利用内存就得在释放时做大量的合并、分割、整理工作分配速度必然受影响。堆内存管理的全部演化历史本质上就是在这三个目标之间寻找平衡点。2.3 从内核到应用一次 malloc 的完整旅程理解一次malloc(100)到底发生了什么比死记硬背数据结构更有用。整个过程可以分成四层第一层是应用层代码里调用malloc(100)期望获得一个至少 100 字节的可用内存指针第二层是分配器层glibc 的 ptmalloc 负责接手这个请求先查线程本地的缓存再查空闲链表都不行才会向内核要内存第三层是内核层内核通过brk或mmap机制将物理内存页映射到进程的虚拟地址空间——注意这一步只是建立映射物理页通常是懒分配的真正写入时才触发缺页中断分配物理页第四层是硬件层MMU 通过页表完成虚拟地址到物理地址的转换。有一个重要概念必须刻在脑子里malloc分配的是虚拟地址空间只有真正访问这块内存时操作系统才会把物理页补上。这解释了为什么malloc一块很大的区域通常不慢但第一次逐页写入的时候会有并不均匀的延迟。堆内存管理要优化的对象是第二层——用户态的分配器——以及它和第三层之间的交互策略。搞清楚了堆内存管理的定位后面的内容就好理解了。分配器的所有结构设计和算法选择都在回答同一个问题在内存块大小不确定、分配释放次序不确定、线程并发不确定的前提下用什么数据结构、以什么策略来组织这些内存块才能又快又不浪费。3. 核心机制深度拆解堆管理器的经典设计与关键参数3.1 内存块的组织方式从隐式空闲链表说起堆管理器要管理的最小单位是“内存块”chunk。每个 chunk 不仅包含用户可用的数据区还包含一个管理头部。在最简单的设计里每个 chunk 的头部记录三个信息前一个 chunk 是否空闲、当前 chunk 的大小、当前 chunk 是否空闲。这些 chunk 在物理地址上相邻排列通过头部的大小信息就能从一块走到下一块形成一条隐式空闲链表。之所以叫“隐式”是因为链表是通过“头部里的 size 字段 地址运算”来遍历的而不是通过显式的 next 指针。这种设计的优点是内存利用率高——不需要为链表指针额外占用空间缺点是分配时要遍历链表查找足够大的空闲块复杂度是 O(n)而且释放时需要检查前后邻居是否空闲、决定是否合并。对于现代多线程应用来说纯隐式链表的效率完全不够看但它是理解所有后续复杂设计的基础。在实际的 glibc 实现中chunk 头部结构要更精细一些。64 位系统下一个已分配的 chunk 头部是 16 字节其中prev_size字段在前一个 chunk 空闲时才有意义用于前向合并size字段包含当前 chunk 大小和三个标志位P前一个块是否已被分配、M是否通过mmap分配、A是否属于主分配区。大小字段中包含标志位这一点很关键它解释了为什么申请的内存大小总会被对齐——保证 size 的低 3 位是 0才能腾出位置放标志位。3.2 自由列表的进化分箱bin设计与多级缓存纯链表遍历太慢于是引入了按大小分箱的设计。核心思想是把空闲 chunk 按大小范围分成多个容器每个容器内部用双向链表组织。分配时先根据请求大小找到对应的容器如果容器非空直接取一块如果为空再到更大的容器中找。glibc 的 bin 体系分三类。第一类是 fast bins用于处理小内存块的快速分配释放默认最多维护 10 个链表每个链表对应一个固定大小的 chunk 区间64 位系统下从 32 字节开始以 8 字节或 16 字节为单位递增。fast bins 里的 chunk 释放时不会立即合并而是留在链表中供快速复用这是典型的用内存换时间。第二类是 unsorted bin只维护一个链表释放的 chunk 和从大 bin 分裂出的剩余块会先被扔进这里。这意味着释放操作的开销极低——只需要把头结点插到 unsorted bin 里——而下次分配时优先从 unsorted bin 中找找到了直接用找不到再做整理。第三类是 sorted bins包括 small bins 和 large bins。small bins 按固定大小区间划分同样用双向链表large bins 则是按区间段组织的同一条链表里的空闲块按大小排序。这里有一个新手很容易懵的参数M_MXFAST默认值是 64 字节。它控制的是 fast bins 能处理的最大请求大小超过这个值的释放块会进入 unsorted bin 或做合并处理。理解这个阈值对后面分析“为什么我的小内存块释放后内存没有立刻降下来”这个问题至关重要。3.3 tcache现代分配器的性能利器如果要选一个对性能提升最明显的设计我会把票投给 tcacheThread Local Cache线程本地缓存。glibc 从 2.26 版本开始默认开启 tcache它的思路非常直观每个线程维护一组属于自己的空闲链表在小内存分配和释放时优先从自己的缓存中取或放回完全不加锁。tcache 有两个关键参数。一个是tcache_count每个 bin 里最多缓存多少个 chunk默认是 7另一个是tcache_max_bytes默认是 1032 字节单次申请超过这个大小的内存不会走 tcache。这两个参数解释了一个非常常见的现象为什么在高并发下小块内存的分配速度可以快到几乎不影响整体性能而大块内存的分配性能提升却有限。理解 tcache 还需要知道一个安全相关的点因为它使用单向链表且不校验历史上出过多次针对 tcache poisoning 的堆利用漏洞。从防御角度看glibc 引入了 key 字段和双重释放检测从理解角度看这恰好说明 tcache 为了速度牺牲了部分安全性。做安全方向研究的同行这里值得单独深挖。3.4 三个核心阈值MMAP_THRESHOLD、trim 与动态调整堆内存管理里光知道“怎么分”不够还得知道“什么时候向内核要内存什么时候还回去”。这里有两组重要的阈值。第一组是MMAP_THRESHOLD默认 128KB。当malloc的请求大小超过这个值时分配器不会从堆里切一块出来而是直接调用mmap创建一块独立的内存映射区域释放时再munmap整块归还。这避免了大量大块内存长期占用堆导致无法复用的问题也避免了将大块内存作为 chunk 放入 bin 后因合并困难而产生严重碎片。这个阈值是动态调整的当程序频繁分配并释放超过当前阈值的大块内存时glibc 会逐渐提高阈值减少 mmap 的调用次数反之则会降低。第二组是trim阈值默认是 128KB配合M_TRIM_THRESHOLD使用。当堆顶的空闲内存量超过这个值分配器会尝试通过sbrk(-n)把堆收缩把页面归还给操作系统。注意“堆顶”这个限定词——只有堆最后面的连续空闲区域才能被 trim中间的空闲块无论多大都无法还回去。这就直接引出了内存碎片化的一个关键后果碎片越多堆顶越难形成大规模连续空闲区内存越难归还。另一个容易混淆的是M_MMAP_MAX默认 65536限制了使用 mmap 的最大次数。超过这个上限后即使请求大小超过 MMAP_THRESHOLD也改用堆切分的方式来分配。从其内部逻辑我们还能理解为什么有些大块内存明明应该被 mmap 分配观察/proc/pid/maps时却没有看到单独的映射段——阈值调整和次数上限在起作用。4. 实操视角分配与释放的完整生命周期4.1 malloc(100) 的路径解析一次典型的小块分配把前面几节的内容串起来以 64 位 Linux 系统、glibc 默认配置为例完整走一遍malloc(100)的路径。第一步计算实际需要的内存大小。用户请求 100 字节加上 chunk 头部 16 字节得到 116 字节再按 16 字节对齐到 128 字节——这是分配的元数据开销。很多人第一次看源码时会产生疑问为什么明明申请 1 字节实际却占用了 32 字节答案就在这个头部和对齐机制里。所以“malloc 的实际内存开销不是请求大小而是请求大小加上头部并向上对齐到对齐边界”这句话建议刻下来。第二步检查 tcache。请求大小 128 字节小于tcache_max_bytes1032 字节所以分配器先查看当前线程 tcache 中大小为 128 字节的 bin 是否有空闲 chunk。如果有直接出链并返回整个过程无锁大概 20~30ns 就能完成。如果为空进入下一步。第三步检查 fast bins。同样128 字节小于M_MXFAST默认 64KB注意这里是 64 字节的误区对应的范围。这里补充一个重要细节64 位系统下fast bins 的默认最大处理能力不是从任意值算的而是由M_MXFAST的默认值 64十进制的字节数不对M_MXFAST单位是字节默认 64决定的超过 64 字节的申请是不会直接走 fast bins 的。等等读者看到这里可能已经发现了前面说 fast bins 覆盖从 32 字节到 128 字节的大小区间但M_MXFAST的默认值 64 字节却把阈值卡在了一个相对低的位置。我需要把这个细节澄清清楚M_MXFAST控制的是 fast bin 请求的“最大值”默认 64 字节而 fast bins 数组本身可以容纳更大范围的链表。但在默认配置下只有不超过 64 字节的请求才会直接命中 fast bins。这个误区和底层机制是看源码和看文章时常见的坑。第四步检查 unsorted bin。fast bins 没有命中分配器会把 unsorted bin 中的 chunk 拿出来挨个检查是否刚好足够大、能否直接切分。unsorted bin 里的块会在这时被整理并分类到 small bins 或 large bins 中——这是“延迟整理”策略的核心不在释放时做昂贵的分类工作而是放到分配时顺带完成。第五步如果没有合适的 chunk分配器进入 small bins 和 large bins 查找找到合适的块后取出如果块比请求大很多就分裂成两块一块返回给用户另一块作为空闲块插入 unsorted bin。如果没有找到会尝试从 top chunk 切一块出来。top chunk 是堆末尾的一块“保留缓冲”区域。如果 top chunk 也不够就只能调用sbrk扩展堆或者调用mmap当请求大于 MMAP_THRESHOLD 时。这一套流程走下来核心逻辑就一句话访问路径从快到慢逐层推进不到万不得已不打扰内核。这种分层设计的哲学在整个系统软件领域都能看到。4.2 free 之后释放逻辑与合并条件free的逻辑比malloc简单一些但同样有几个关键分支。第一步根据 chunk 的M标志判断是不是通过mmap分配的。如果是直接munmap释放。注意mmap 块的释放不经过 bin这也是大块内存申请释放时开销相对稳定可预测的原因。第二步对于普通 chunk检查请求大小是否小于tcache_max_bytes。如果是先把 chunk 插入 tcache 的对应 bin如果该 bin 已满超过 7 个则会从尾部弹出一个 chunk再把它交给后续的 bin 处理流程。这个“先塞 tcache、溢出才走慢路径”的设计让小块内存的释放也几乎无锁。第三步对于超过 tcache 范围或 tcache 溢出的块检查相邻物理 chunk 的空闲状态。由于当前 chunk 头的size字段里有P标志位可以得知“前一个 chunk”是否空闲同时通过当前 chunk 的 size 计算出下一个 chunk 的地址再读下一个 chunk 的P标志位得知“后一个 chunk”是否空闲。如果前后有空闲块就拼接成大块更新头部信息。合并后的 chunk 放入 unsorted bin。这里有一个隐藏很深的细节释放时检查的是“物理相邻”的 chunk而不是链表相邻。因为堆内存本身就是一段连续地址通过地址运算就能找到邻居。所以碎片化的本质就是物理相邻的空闲块被已分配的块隔开无法合并成一个大块。应用程序反复分配和释放不同大小的内存就会在堆上留下一个个“孤岛”最终导致明明空闲总量足够却没有连续内存满足大块分配请求。4.3 内存碎片成因、分类与缓解手段碎片分两种。内部碎片是指分配给用户的内存块大于实际请求导致的多余空间比如 16 字节对齐导致申请 100 字节实际占用 128 字节多出的 28 字节就是内部碎片。外部碎片是指堆中存在大量小且不连续的空闲块导致大请求无法满足。两种碎片都会降低内存利用率但成因和缓解手段不同。设计层面可以通过增大对齐粒度或调整 bin 大小区间来减少内部碎片通过及时合并空闲 chunk 和在合适时机使用 mmap 来减少外部碎片。应用层面最常见也最有效的手段是引入内存池。从一个实际项目为例我曾维护过一个处理大量连接的网络服务每条连接需要分配几块大小不一的缓冲区频繁申请释放导致堆上碎片率一度很高峰值内存接近理论值的两倍。后来引入了一个简单的 slab 内存池把缓冲区按 2KB、4KB、8KB 分桶各自维护空闲链表碎片率立刻降了下来gc 和 OOM 的问题也随之消失。如果你是做服务端开发的并且观察到了“内存总量不高但分配失败”的现象优先怀疑外部碎片。不过也要提醒一句内存池不是万能的。池化内存的桶大小划分如果和业务申请大小匹配不好反而会加剧内部碎片。调优的关键是先通过实际日志或 profile 统计申请大小的分布再设计桶的规格。5. 实战演练一个可复现的分配器模型5.1 从零实现一个最简堆分配器原理讲得再多不如动手写一个微型分配器来得直观。我建议有兴趣的读者按下面这个顺序自己实现一版简化但功能完整的堆分配器。这个过程能帮你把所有抽象概念落到具体的数据结构和代码路径上。第一步定义 chunk 头。这里我们实现一个隐式空闲链表版的最简分配器typedef struct chunk_header { size_t size; // 当前块总大小含头部低 1 位存空闲标志 struct chunk_header *next; // 仅空闲块使用或者用显式链表 } chunk_header_t; #define CHUNK_HEADER_SIZE sizeof(chunk_header_t) #define ALIGN_TO_16(x) (((x) 15) ~(size_t)15)第二步维护一个静态数组模拟堆空间初始化时只有一个大空闲块和一个边界块static char heap[HEAP_SIZE]; static chunk_header_t *free_list_head; void heap_init() { chunk_header_t *first (chunk_header_t *)heap; first-size HEAP_SIZE - CHUNK_HEADER_SIZE; first-next NULL; free_list_head first; }第三步实现my_malloc。采用最基础的 first fit 算法遍历空闲链表找到第一个足够大的块。如果块大小远大于请求就分裂成两块剩余块重新入链void *my_malloc(size_t size) { size_t aligned ALIGN_TO_16(size); size_t need aligned CHUNK_HEADER_SIZE; chunk_header_t *cur free_list_head; chunk_header_t *prev NULL; while (cur) { if (cur-size need) { if (cur-size need CHUNK_HEADER_SIZE 16) { // 分裂 chunk_header_t *rest (chunk_header_t *)((char *)cur need); rest-size cur-size - need; rest-next cur-next; if (prev) prev-next rest; else free_list_head rest; cur-size need; } else { // 直接取下整块 if (prev) prev-next cur-next; else free_list_head cur-next; } cur-next NULL; return (char *)cur CHUNK_HEADER_SIZE; } prev cur; cur cur-next; } return NULL; // 堆空间不足 }第四步实现my_free。最简版本里释放就是把块重新插入空闲链表头部。如果要做合并就需要通过地址运算找到物理相邻的块检查它们是否空闲然后合并成一个大块。这一步建议读者自己动手实现它远比看十篇文章更能让你理解前向合并和后向合并的边界条件。5.2 观察行为验证分配器的内存布局写完之后怎么验证逻辑是否正确很简单打印每次返回的地址和分配后的堆布局。你会发现一个很有意思的现象连续的几次my_malloc(100)返回的地址间隔并不是 100而是 100 对齐到 16 后再加头部大小也就是 128。这就直观地展示了元数据开销和内部碎片。还可以做一个实验分配 A(100)、B(200)、C(100)释放 B再分配 D(150)。如果分配器支持分裂D 会直接复用 B 的位置并把剩下的空闲块重新入链。如果不支持分裂D 就会越过 B 的空闲区域从堆尾新切一块——后者的内存利用率会迅速恶化。这就是为什么所有正经分配器都一定会实现分裂。对于想做更深入实验的读者可以尝试把静态数组替换成通过sbrk获取的内存这样就把一个玩具分配器变成了真正能从系统获取内存的分配器。再进一步可以给 chunk 头加上前后邻居指针实现双向链表和按地址排序、释放时合并相邻空闲块这样就更接近 ptmalloc 的核心骨架了。6. 问题排查与调优实践从现象定位到参数调整6.1 内存泄漏排查先分清是泄漏还是持有排查内存问题第一步往往不是看代码而是先判断问题的性质。内存增长过快有三种可能真正的泄漏分配了但永远不释放、长生命周期对象累积不泄漏但持有时间过长、以及内存碎片导致的虚高。Linux 下我常用的排查路径是这样的。先用/proc/pid/status里的VmRSS和VmSize观察内存增长趋势配合top或htop确认是常驻内存增长还是虚拟内存增长——如果只有 VmSize 增长而 RSS 不涨多半是分配了但没访问。接着用 valgrind 定位泄漏点但是 valgrind 慢得让人抓狂。也可以用 glibc 自带的mtrace通过环境变量开启适合小规模测试。生产环境里效果最好的是打造一个标准的 malloc hook 分析工具或者直接用MALLOC_CHECK_环境变量检查堆结构异常。MALLOC_CHECK_是 glibc 自带的一个调试开关设置为 3 时会启用额外的堆完整性检查并在出错时 abort。它非常擅长捕捉重复释放、越界写坏 chunk 头这类问题。一个快速定位手段是把MALLOC_CHECK_3加到环境变量后重跑复现路径如果程序直接崩在某个 malloc 调用上说明堆已经被写坏了接着用 gdb 检查 chunk 头里的 size 字段和标志位往往能很快找到越界写的位置。6.2 高频分配场景的调优参数如果程序确有高频的小块分配可以从这几个方面调整。第一开启并合理配置 tcache。glibc 2.26 之后默认开启但如果你的运行环境比较老可能需要设置GLIBC_TUNABLESglibc.malloc.tcache_count32这类环境变量来调整。对于分配频率极高的小对象增大tcache_count能显著减少慢路径调用。第二配合M_MMAP_THRESHOLD调整大块分配策略。如果程序频繁分配 100KB~200KB 的内存默认阈值 128KB 会导致这些分配走 mmap如果分配释放频率很高mmap munmap 的开销会很明显。可以通过mallopt(M_MMAP_THRESHOLD, 256*1024)调高阈值让这些分配改走堆切分。但注意提高了阈值意味着大块内存释放后不一定立即归还系统堆的峰值内存会上升。第三在多线程场景下默认的 per-thread arena 机制会为每个线程创建独立的堆。当线程数很多时每个 arena 都有自己的 top chunk内存碎片和虚拟内存占用会显著增加。可以通过设置环境变量MALLOC_ARENA_MAX2或通过 mallopt限制 arena 数量代价是线程之间会竞争分配锁。这个参数在多线程服务里经常能立竿见影地降低内存占用但会给吞吐量带来轻微影响。6.3 核对性能用原子变量和性能分析工具做前后对比调优不能靠感觉数据才可信。我一般会用两套工具valgrind --toolmassif做堆内存快照分析看哪个调用栈分配了最多内存用perf record -e cycles配合--call-graph dwarf看 malloc 的调用频率。一个实际案例是这样的某个服务上线后内存持续增长RSS 从 300MB 涨到 1.2GB 后触发报警。先用 massif 发现 60% 的内存集中在某个网络包解析函数里再读代码发现每一帧都会 new 一个临时对象在异常路径上漏了 delete。修复后内存稳定在 400MB 左右。这种问题光看代码确实不容易发现尤其是异常路径上的遗漏但工具一上调用栈清清楚楚几分钟就能定位。我在实际排查中的体会是内存问题排查本质是“工具 对分配器机制的理解”这两者的结合。7. 复习路线设计从原理到面试通关7.1 知识图谱与记忆锚点如果要把这份笔记浓缩成一份复习大纲我会按下面这个顺序过地址空间布局与堆的位置brk / mmap 分界线chunk 结构与 size 字段的标志位含义P/M/A隐式空闲链表与显式空闲链表、分裂与合并分箱设计思路fast bins、unsorted bin、small bins、large binstcache 的引入背景与关键参数分配流程tcache → fast bins → unsorted bin → small bins → large bins → top chunk → 系统调用释放流程tcache → 合并 → unsorted bin → trim三个阈值MMAP_THRESHOLD、M_TRIM_THRESHOLD、M_MMAP_MAX碎片产生的机制与缓解策略常见内存问题的排查工具链记这几个“锚点”是很有用的chunk 头 16 字节、对齐到 16、tcache 每 bin 最多 7 个、MMAP_THRESHOLD 默认 128KB、M_MXFAST 默认 64 字节。这些具体数字一旦掌握面试时能立刻展示出你不是只背概念而是真的理解过实现细节。7.2 常见面试题的底层回答思路面试官问“malloc 是怎么实现的”不要只答“从堆上分配”。一个好的回答结构是先说明堆的边界由 brk 决定、大块内存走 mmap再讲分配器的分层结构从 tcache 到 fast bins 再到 unsorted bin 和 sorted bins最后提一句 top chunk 耗尽后会通过 sbrk 扩展堆。如果能把每个层级的适用大小范围说清楚就已经超过大多数候选人了。问“free 怎么知道要释放多大”时直接答 chunk 头部 size 字段并补充最小分配单位的计算方式。问“什么是内存碎片怎么解决”时先分内部碎片和外部碎片再讲合并、分裂、内存池、调整阈值这几种手段。问“为什么多线程下 malloc 性能差”时原因在于锁竞争和 arena 的分配策略同时提一下 tcache 如何绕过锁。按照这种“先说机制再说参数最后给实际案例”的思路去准备基本可以覆盖绝大多数堆内存相关的问题。最后我强烈建议所有学习者自己动手编译一个 glibc 的早期版本2.23 或 2.27 都行在代码里加 printf 打印分配路径上的关键分支。这个过程会让你对堆内存管理的理解发生质的飞跃——从“知道大概”变成“真的懂”。这种通过源码阅读获得的通透感是看任何二手资料都替代不了的。