一段程序跑三天崩一次和跑三年都不喘气差别往往不在算法而在 C/C 内存管理这一层有没有做干净。我见过太多项目业务逻辑写得漂漂亮亮结果一个悬垂指针在生产环境里偶发踩内存排查两周才定位到一行早就被释放的指针还在被读。内存管理这个话题听起来像面试八股实际上它是每个写 C/C 的人绕不过去的基本功栈和堆怎么分、malloc 家族各自什么脾气、new/delete 和它们差在哪、智能指针什么时候该上什么时候是负担、结构体为什么莫名其妙大了 8 个字节、内存泄漏怎么在本地就逮住。这篇文章我打算按我自己平时带人和排障的思路从地址空间分区讲到 C 的手动管理再讲到 C 的对象生命周期与 RAII最后落到对齐、内存池和工具链实战。不管你是刚学完指针、正在用 VS Code 配 C/C 环境的新手还是写过几年代码但对 shared_ptr 循环引用还有点含糊的从业者都能从中拿走可以直接用的东西。1. 进程地址空间的地图先把五块地标清楚1.1 五个分区到底谁管谁很多人背过“栈区、堆区、全局区、常量区、代码区”但真正写代码时对不上号。我习惯用一张表把它们钉死因为后面所有的内存问题本质都是“某个字节属于哪块地、由谁负责释放”。分区典型内容生命周期谁负责回收栈 stack局部变量、函数参数、返回地址随函数调用结束自动销毁编译器生成的指令堆 heapmalloc/new 出来的对象从申请到显式释放程序员全局/静态区全局变量、static 变量程序整个运行期进程退出时系统回收常量区字符串字面量、const 全局量程序整个运行期通常只读系统代码区机器指令程序整个运行期系统这张表里最需要盯住的是堆那一行“程序员负责回收”六个字就是 C/C 内存问题的主要来源。栈上的东西你几乎不用管编译器会在函数返回时插一条调整栈指针的指令整块栈帧一次性回收堆不行堆是一大片由分配器统一管理的区域你必须自己把借出去的那块还回来还早了会踩空还晚了会漏还错了会直接把分配器的元数据搅烂。还有一点容易被忽略全局/静态区其实分成.bss和.data两段。已初始化为非零的全局变量放在.data未初始化或者初始化为 0 的放在.bss。.bss段在可执行文件里不占空间只在加载时由系统清零分配所以一个大数组如果写成int buf[1024*1024];未初始化和写成int buf[1024*1024] {1};已初始化编译出来的二进制体积差别可能有好几 MB。这个细节在做嵌入式或者对包体积敏感的场景里非常实用。1.2 一个变量到底住在哪用代码对照光看表容易忘直接上代码看地址最直观。下面这段在 Linux x86-64 上跑每次输出顺序基本固定数值会变但相对关系稳定#include stdio.h #include stdlib.h int g_init 42; // .data int g_uninit; // .bss const char *msg hello; // 指针在 .datahello 在 .rodata int main(void) { int local 1; // 栈 static int st 2; // .data有初值 int *heap malloc(sizeof(int)); // 堆 *heap 3; printf(code (main) : %p\n, (void*)main); printf(rodata(\hello\) : %p\n, (void*)msg); printf(data (g_init) : %p\n, (void*)g_init); printf(bss (g_uninit): %p\n, (void*)g_uninit); printf(heap (heap) : %p\n, (void*)heap); printf(stack (local) : %p\n, (void*)local); free(heap); return 0; }典型输出从低地址到高地址大致是代码区 → 常量区 → 全局/静态区 → 堆 → 栈。注意堆和栈之间隔着巨大的空洞堆往高地址长栈往低地址长两者相向而行中间那段未映射区域就是保护带一旦哪边越界撞上去操作系统直接给你一个段错误这其实是好事快速暴露问题总比默默改坏数据强。如果你在 VS Code 里调试可以直接在WATCH面板里填local、heap或者在调试控制台敲x/4xb heap用 GDB 的 examine 命令看这四字节内容比 printf 更灵活尤其是-O0编译的时候变量地址和源码能一一对上观察内存布局基本就靠这个手段。1.3 栈为什么放不下大数组栈的大小是有限制的Linux 默认单线程栈通常是 8MB用ulimit -s可以查Mac 上一般是 8MBWindows 默认保留 1MB。这个数字决定了一件很实际的事函数里写char buf[16 * 1024 * 1024];会直接栈溢出程序在进入函数那一刻就崩了甚至连报错信息都来不及打。堆就没这个限制吗也不是堆受限于进程可用的虚拟地址空间和物理内存但在 64 位系统上这个天花板高得多而且分配器是按需向操作系统要页的你不用不花。所以工程上的经验是小于几 KB 的临时缓冲放栈上几十 KB 以上的一律上堆别为了图省事写个大数组在栈上那个坑在本地跑得好好的换台机器栈限制小一点就炸。顺带说一个常见误解alloca也是在栈上分配和malloc长得像但完全不是一回事它随函数返回自动回收且失败行为不可控除了极少数性能敏感的场合我不建议用。2. C 的手动内存管理malloc 家族的脾气2.1 malloc、calloc、realloc 到底怎么选这三个函数加上free构成了 C 语言堆管理的全部原语。它们看着简单但每个都有各自的性格函数是否清零参数含义典型用途malloc(n)否字节数通用分配追求速度calloc(cnt, size)是元素个数 × 元素大小需要零初始化的数组、结构体数组realloc(p, n)新扩展部分不保证清零原指针 新字节数动态扩容free(p)不适用释放指针归还内存关于calloc很多人以为它就是把malloc加memset其实在底层实现上不完全是操作系统给新页的时候本来就是清零的calloc可以省掉一次显式清零所以“为清零付费”这个直觉在很多时候是反的。真正需要小心的是乘法溢出calloc(cnt, size)内部会检查cnt * size是否溢出而malloc(cnt * size)不会你自己算的那一步可能已经把size_t撑爆了结果申请到一块小得多的内存后面写越界。所以凡是用malloc(count * size)的地方稳妥写法是先判断count SIZE_MAX / size。realloc是最容易写错的一个。它有三种返回情形原地扩容成功、搬到新地址、失败返回 NULL 且原指针仍然有效。第三点特别关键下面这个写法是错的p realloc(p, new_size); if (p NULL) { /* 原来的 p 已经丢了内存泄漏 */ }正确姿势永远是先接住返回值确认成功再赋值void *tmp realloc(p, new_size); if (tmp NULL) { /* 处理失败p 仍然指向原来的块可以继续用或者 free(p) */ } else { p tmp; }还有两个边界情况值得记住realloc(p, 0)在 C99 之后行为是实现定义的可能返回 NULL 也可能返回一个可以free的指针别依赖它malloc(0)同样是实现定义可能返回 NULL 也可能返回一个不可解引用但可free的指针实际写业务代码时最好在分配前就挡掉 0 的情况。2.2 分配失败必须处理别假设内存永远够malloc失败返回 NULL这个大家都知道但真正在代码里写检查的人不到一半。桌面程序内存充足时确实很难触发可一旦到了嵌入式设备、容器内存受限环境、或者有内存配额限制的服务里这就是必崩的隐患。更麻烦的是失败之后如果你直接解引用崩溃点往往离真正的原因很远。我的习惯是给分配包一层static void *xmalloc(size_t n) { void *p malloc(n); if (p NULL n ! 0) { fprintf(stderr, out of memory: %zu bytes\n, n); abort(); } return p; }小工具、命令行程序用abort快速失败完全合理因为此时程序已经无力回天硬撑着继续跑只会写出更难查的错误数据。但服务端程序不能这么干得走降级路径拒绝这次请求、释放缓存、返回错误码让上层决定怎么办。2.3 五个高频错误每个都能给你上一课第一个内存泄漏。申请了忘记还或者在某条提前 return 的分支上漏掉了free。长生命周期进程里泄漏会慢慢把内存吃干最终被系统杀掉。它的可怕之处在于短期内完全看不出来。第二个悬垂指针。free(p)之后p的值没变仍然指向那块已经被回收的内存。此时读它可能还是旧数据因为分配器还没复用写它就会污染后来者的数据。我个人的硬规矩是free(p); p NULL;虽然不能解决所有别名问题但能挡掉相当一部分手误。第三个重复释放。同一块内存free两次现代分配器通常会直接 abort 并打印 “double free or corruption”算是比较友好的但在老版本 glibc 上可能被利用来执行任意代码。这个问题的根因通常是所有权不清两个模块都以为自己是 owner。第四个越界写。char buf[10]; strcpy(buf, 0123456789abc);这类写法写坏了堆块的尾部元数据崩溃可能发生在下一次free或者下一次malloc的时候跟出错点隔了十万八千里。这也是为什么这类 bug 特别难查你会一直怀疑分配器而不是自己的代码。第五个sizeof 指针。int *p malloc(sizeof(p));在 64 位机器上只给了 8 字节你以为给了sizeof(int)。更隐蔽的是malloc(n * sizeof(char *))写成malloc(n * sizeof(char))差了一个星号越界写到怀疑人生。这个错我至少见过三次每次都有人盯着看半天没看出来。提示只要是手写malloc就把「分配大小」「判空」「初始化」「释放」「置空」当成五步固定流程写下来别省步骤省下来的那几行迟早要用加班还。3. C 这一层多出来的东西对象生命周期与 RAII3.1 new/delete 和 malloc/free 的本质区别C 里new不只是“分配内存”它是两步先调用operator new拿到一块原始内存然后在这块内存上调用构造函数。delete反过来先调析构函数再调operator delete归还内存。malloc/free只做第一步和最后一步中间的对象构造和析构完全不参与。对比项malloc/freenew/delete构造/析构不调用调用失败行为返回 NULL抛 std::bad_alloc返回类型void*具体类型指针大小计算手动 sizeof编译器推导重载不可重载可重载 operator new与类的关系无关与类绑定可定制实践里最常踩的一点是new出来的对象只能用deletemalloc出来的只能用free两者绝对不能交叉。原因很直接分配器不一样operator new默认最终走malloc但一个类可能重载了operator new走的是自定义内存池你用free去还它等于把内存还给了错误的账本。另一个是失败行为差异。裸new失败抛异常如果你在一个不处理异常的老代码库里用可能直接 terminate。想沿用 C 风格的话写法是new (std::nothrow) T它会返回空指针。我的建议是既然用 C就接受异常语义把new放在能捕获或者能传播的位置别混着用。3.2 new[] 和 delete[] 为什么不能混用new[]在分配数组时会额外存一份“元素个数”的信息特别是在元素类型有非平凡析构函数的时候。delete[]需要读这个 cookie 才知道要调用多少次析构。你如果写成delete p缺了方括号它只析构第一个元素剩下的内存和资源全漏了而且因为没有按数组方式释放还可能把分配器的元数据搞错。对于没有析构函数的基本类型数组比如int* p new int[10]; delete p;很多实现上“看起来没事”因为不需要逐元素析构但这依然是未定义行为换个编译器或者换个类型就可能崩。所以规矩就一条方括号成对出现。顺带提一句现代 C 里裸new[]已经很少见了std::vector、std::array、std::string基本能覆盖绝大部分需求能不用裸数组就别用。3.3 RAII 与智能指针选型RAII 是 C 内存管理的核心思想把资源的生命周期绑定到对象的生命周期上对象出作用域就自动释放。智能指针是这条思想最直接的落地。std::unique_ptr是零开销抽象默认删除器下它的大小和裸指针完全一样拷贝被禁用只能移动表达的是唯一的独占所有权。日常写代码我默认就是它。只要看到“这个资源只在一个地方持有”就用unique_ptr需要传递时用std::move明确表示所有权转移。std::shared_ptr带引用计数拷贝时计数加一最后一个释放时对象销毁代价是一个控制块引用计数、弱引用计数、删除器等拷贝会带来原子操作开销。它适合“多个对象共同持有谁都可能最后退出”的场景比如一个配置对象被多个模块共享。std::weak_ptr不增加强引用计数主要是观察者身份用来打破shared_ptr的循环引用。它不能直接解引用必须先lock()拿到一个临时的shared_ptr判断非空再访问。这里有个选型经验能 unique_ptr 就别 shared_ptr。shared_ptr一旦开始在全项目蔓延对象的销毁时机就变得难以预测而且引用计数循环问题会一个接一个冒出来。我在 review 代码的时候看到不必要的shared_ptr会直接要求改成unique_ptr 裸引用参数。3.4 shared_ptr 的循环引用与 weak_ptr 破环循环引用是shared_ptr最经典的坑标准场景是双向链表或者父子节点互指struct Node { std::shared_ptrNode next; // 强引用 std::shared_ptrNode prev; // 强引用 };两个节点互相持有引用计数永远下不到 0两块内存都泄漏。解决办法是把其中一个方向改成weak_ptrstruct Node { std::shared_ptrNode next; std::weak_ptrNode prev; // 弱引用不计数 };使用prev的时候要auto p prev.lock(); if (p) { ... }。还有一个更隐蔽的泄漏点make_shared会把对象和控制块分配在同一块内存里这本来是性能优势少一次分配、缓存局部性好但它有个副作用——只要有任意一个weak_ptr还活着整块内存包括对象所占的那部分就不能被释放只有对象析构函数会跑。所以如果你的场景里weak_ptr会长期存活而对象本身很大可能反而用shared_ptrT(new T)更合适让对象内存能早一点归还。这个细节很多人不知道但在大对象 大量 weak_ptr 观察者的场景下会造成明显的内存占用。注意自定义删除器也是容易漏的地方。用shared_ptr管理文件句柄、socket、C 库资源的时候一定要在构造时传删除器否则默认走delete直接崩。4. 对齐、padding 和对象布局看不见的内存开销4.1 对齐规则与结构体大小计算CPU 读内存不是一字节一字节读的而是按总线宽度成块读的所以访问对齐的地址要快得多某些架构上访问未对齐地址甚至直接触发异常。编译器为了保证对齐会在结构体成员之间插入填充字节这就是 padding。对齐的基本规则有三条每个成员的起始地址必须是它自身对齐数的整数倍对基本类型来说对齐数通常等于其大小结构体的对齐数等于其成员中最大的对齐数整个结构体的大小必须是这个对齐数的整数倍。拿一个例子算struct A { char a; // 偏移 0占 1 字节 int b; // 需要 4 字节对齐偏移 4前面补 3 字节 char c; // 偏移 8占 1 字节 }; // 结构体对齐数是 4总大小补到 12sizeof(struct A)是 12不是 6。三个成员实际有效数据只有 6 字节一半是填充。把成员顺序调一下struct B { int b; // 偏移 0 char a; // 偏移 4 char c; // 偏移 5 }; // 补到 8sizeof(struct B)变成 8白白省下 4 字节。这个技巧叫“按大小从大到小排列成员”在需要大量实例的场景比如顶点数组、粒子系统里省下来的内存和带宽非常可观。如果你确实需要紧凑布局比如解析网络协议包、读写磁盘格式可以用#pragma pack(1)或者__attribute__((packed))关掉填充。但要注意打包之后成员可能未对齐在部分平台上访问会变慢甚至崩而且不能直接对打包结构里的成员取地址传给需要对齐的函数。我的做法是协议结构用打包内存里的结构用自然对齐两者之间显式做一次转换。C11 之后还可以用alignas/alignof精确控制struct alignas(64) CacheLinePadded { int value; };这样每个实例都占据完整的缓存行避免相邻对象互相干扰。4.2 缓存友好与伪共享比对齐更高一层的是缓存局部性。CPU 缓存以缓存行为单位x86 上一般是 64 字节。如果你的程序频繁访问分散在内存各处的对象每一次都可能触发缓存未命中性能差距可能是几倍到几十倍。一个具体例子遍历一个std::vectorLargeStruct和遍历一个std::vectorLargeStruct*前者内存连续预取器能提前把后面的缓存行拉进来后者每次都是随机跳转。这就是为什么现代 C 强调“数据导向设计”把热数据放在一起用数组代替链表。多线程场景下还有一个坑叫伪共享两个线程分别修改同一缓存行里的不同变量虽然逻辑上没有冲突但硬件层面这一行会被反复失效和同步性能急剧下降。解决办法是给变量加填充让它们落在不同的缓存行上struct Counter { alignas(64) std::atomiclong value{0}; // 后续填充到 64 字节避免和邻居共享缓存行 char pad[64 - sizeof(std::atomiclong)]; };这个技巧在无锁队列、高频计数器里非常常见代价是内存变大需要权衡。4.3 内存池把 malloc 的次数降下来malloc本身并不慢但它在高频小对象场景下有几个问题每次分配都要走一遍分配器的查找逻辑分配出来的块之间不连续头部还有管理元数据开销glibc 里每个块至少有 8 到 16 字节的头部。如果你要分配一百万个 16 字节的小对象光元数据就吃掉几十 MB。内存池的思路很朴素一次性向系统要一大块然后自己切成小片发出去。最简易的实现就是一个空闲链表typedef struct Block { struct Block *next; } Block; typedef struct { Block *free_list; char *chunk; size_t chunk_size; } Pool; void pool_init(Pool *p, size_t chunk_size) { p-chunk_size chunk_size; p-chunk malloc(chunk_size * 1024); p-free_list NULL; char *cur p-chunk; for (int i 0; i 1024; i) { Block *b (Block *)(cur i * chunk_size); b-next p-free_list; p-free_list b; } } void *pool_alloc(Pool *p) { if (!p-free_list) return NULL; // 简化版不考虑扩容 Block *b p-free_list; p-free_list b-next; return b; } void pool_free(Pool *p, void *ptr) { Block *b (Block *)ptr; b-next p-free_list; p-free_list b; }这个版本只适合固定大小对象但已经能覆盖很多场景比如网络库里的连接对象、游戏里的实体节点。真实的生产级内存池还要处理对齐、不同 size class、线程安全通常每线程一个池避免加锁、以及与析构函数的配合。C 里给容器配自定义分配器也是同一思路std::pmr多态内存资源从 C17 开始提供了一套标准化的接口可以给std::pmr::vector指定一个monotonic_buffer_resource在一块预分配的大缓冲区上做 bump 分配退出时一次性释放特别适合请求级别或者帧级别的临时数据。提示内存池不是万能药。它解决的问题是“大量同尺寸小对象、生命周期相近、需要低延迟”。如果你的对象大小差异巨大、生命周期长短不一自建内存池反而容易造成碎片和复杂度失控老老实实用 malloc 或者 jemalloc、tcmalloc 这类成熟分配器更划算。5. 实战把内存问题在现场抓出来5.1 用 VS Code GDB 直接看内存排查内存问题光靠读代码是不够的必须能在现场看内存。VS Code 配 C/C 调试环境是一个性价比很高的选择关键是几个配置细节。编译的时候一定要加-g -O0-g生成调试信息-O0关掉优化否则变量会被优化掉、行号会对不上。tasks.json里大概是这样{ version: 2.0.0, tasks: [ { label: build-debug, type: shell, command: gcc, args: [-g, -O0, -Wall, -Wextra, -fsanitizeaddress, ${file}, -o, ${fileDirname}/a.out], group: { kind: build, isDefault: true } } ] }launch.json里指定用 gdb{ version: 0.2.0, configurations: [ { name: Debug (gdb), type: cppdbg, request: launch, program: ${fileDirname}/a.out, args: [], stopAtEntry: false, MIMode: gdb, setupCommands: [ { description: 启用美化打印, text: -enable-pretty-printing, ignoreFailures: true } ] } ] }调试时最有用的几个操作在WATCH面板里加*(int*)ptr看指针指向的值在调试控制台敲x/16xb ptr看 16 个字节的十六进制敲p *node看结构体展开。如果智能提示偶尔犯懒、结构体成员补全不出来多半是c_cpp_properties.json里的includePath或compileCommands没配好把它指向你的compile_commands.jsonCMake 加-DCMAKE_EXPORT_COMPILE_COMMANDSON就能生成通常一步到位。这里要提醒一句-fsanitizeaddress和某些调试器的内存观察功能会互相干扰如果你要单步看内存可以先用不带 sanitizer 的版本如果只是要跑一遍抓错误那就用带 sanitizer 的版本一次编译两套配置launch.json里配两个 configuration 切换。5.2 valgrind、ASan、mtrace 三件套怎么选工具不在多在于用对场景。我一般按下面的方式选工具使用方式优势局限AddressSanitizer编译期-fsanitizeaddress -g速度快能抓越界、悬垂、泄漏需要重编译内存占用上升valgrind memcheck直接跑二进制不用改编译报告详细慢 10 到 30 倍不适合长跑mtrace链接 glibc 并设置环境变量轻量能看分配调用栈只覆盖 malloc/freeASan 是我日常首选。加-fsanitizeaddress编译程序跑起来越界写会立刻报错并且给出分配点和越界点的两处调用栈定位效率极高。检测泄漏再加-fsanitizeleak或者用ASAN_OPTIONSdetect_leaks1。要注意的是ASan 默认会拦截malloc/free如果你用了自定义分配器或者内存池可能需要给它加注解否则它看到的是大块内存无法知道内部的细分边界。valgrind 的优势是不用重新编译线上出的问题拿个带-g的二进制就能跑。命令大概是这样valgrind --leak-checkfull --show-leak-kindsall --track-originsyes ./a.out--leak-checkfull会区分 definitely lost、indirectly lost、possibly lost、still reachable 四种情况其中 still reachable 通常不用太担心比如全局单例在退出时没释放definitely lost 才是真泄漏。--track-originsyes能追踪未初始化值的来源排查“用了没初始化的内存”类问题特别有效。mtrace 最轻量在代码里加两行#include mcheck.h int main(void) { mtrace(); /* ... 业务代码 ... */ muntrace(); return 0; }然后运行前设MALLOC_TRACE./mtrace.log程序结束后用mtrace ./a.out mtrace.log解析每个未配对的malloc都会列出来。它不会告诉你越界但能干净地告诉你是谁漏了。5.3 内存问题速查表排障的时候我习惯先对症状再看方向症状可能原因首选排查手段程序随机崩溃崩溃点每次不同堆越界写或悬垂指针ASan 重新编译跑一遍运行时间越长内存越大内存泄漏valgrind leak-check 或 ASan leakfree 时报 double free重复释放或所有权不清ASan 看两次 free 的调用栈析构函数只跑了一次new[]/delete 混用检查方括号是否成对结构体大小比预期大对齐填充打印每个成员偏移重排成员多线程下性能突然下降伪共享perf c2c 或手动 padding 验证程序退出时才报错全局对象析构顺序问题检查静态对象间的依赖这里补一句关于“退出代码”的排查经验进程退出码如果是 1341286说明收到了 SIGABRT多半是 glibc 检测到堆损坏主动 abort如果是 13912811是 SIGSEGV 段错误如果退出码是正常返回但内存监控显示没降下来那就要怀疑静态对象或全局缓存没释放这类“退出时泄漏”通常无害但会干扰监控指标值得单独处理。6. 常见问题与我的几条硬规矩6.1 十个被问得最多的问题局部数组能不能 return不能栈帧销毁后那块内存就不属于你了返回的是悬垂指针。要返回就用malloc、static注意线程安全或者让调用方传缓冲区进来。free 之后指针要不要置空要虽然不能解决别名问题但能挡掉一部分重复释放和误用。同理delete之后也建议置空尤其在类的成员里。malloc 和 new 能不能混用分配和释放必须配套跨语言的场景比如 C 库返回的内存要看文档约定的释放方式很多库提供专门的xx_free就是因为它内部有自己的分配器。智能指针能不能管理数组unique_ptrT[]可以shared_ptrT[]从 C17 开始也支持但更推荐用std::vector或std::array语义更清楚。引用计数是不是线程安全的shared_ptr的引用计数操作是原子的所以多线程拷贝、销毁同一个shared_ptr对象是安全的但多个线程同时读写“同一个 shared_ptr 变量本身”不是安全的需要加锁或者用std::atomicstd::shared_ptrTC20。为什么我的程序没泄漏但内存一直涨可能是碎片也可能是分配器缓存glibc 的 arena、tcache没有归还给系统还可能是容器的size()没变但capacity()涨上去没下来shrink_to_fit或者 swap 一下能解决。placement new 出来的对象怎么销毁手动调析构函数p-~T();然后自己归还内存。它不分配内存只是在给定地址上构造配套使用很容易出错非必要不用。为什么结构体加了虚函数就变大了因为多了虚表指针vptr64 位下通常 8 字节而且它是对齐边界的一部分可能连带产生填充。能不能用 memset 初始化包含 std::string 的结构体绝对不能memset只做字节级清零会把std::string的内部指针清成空后续析构直接崩。要清零就用 {}或者显式构造函数。栈溢出怎么提前发现可以用-fstack-protector-strong加金丝雀检测深度递归的场景考虑改成显式栈用std::vector模拟递归既避免栈溢出又能控制内存上限。6.2 我给自己定的几条规矩写了这么多年我慢慢固定下来几条习惯说出来供参考。第一条谁分配谁释放跨模块传递必须写清楚所有权是转移、借用还是共享用类型表达出来unique_ptr表示转移裸指针或引用表示借用shared_ptr表示共享看到类型就知道该怎么用。第二条构造函数里如果申请了资源析构函数必须释放且中间抛异常不能漏这也是为什么优先用容器和智能指针而不是裸指针成员它们已经帮你处理了异常安全。第三条新代码默认开 ASan 跑测试CI 里加一个 sanitizer 构建的 job成本很低收益是所有越界和泄漏在合并前就被挡住。第四条不为了省内存去关掉对齐除非有明确的协议或存储格式需求那点内存换来的性能损失通常不值。最后再分享一个我一直在用的小检测习惯在开发阶段给程序加一个内存统计的钩子重载operator new/operator delete或者用-Wl,--wrapmalloc统计当前未释放的字节数和块数然后在服务的健康检查接口里暴露出去。这样每次压测结束、每次线上跑一段时间之后你都能一眼看到那两条曲线是否回到基线。回归基线就是干净的持续缓慢上升就是有泄漏。这个办法比事后拿 valgrind 追栈要主动得多很多时候问题在冒头阶段就被摁住了。真要遇到曲线异常又一时定位不到再上 ASan 或者 valgrind 做一次定向排查两者配合起来内存这块基本就不会再给你制造意外了。
C/C++内存管理实战：从地址空间、malloc到RAII与内存池
一段程序跑三天崩一次和跑三年都不喘气差别往往不在算法而在 C/C 内存管理这一层有没有做干净。我见过太多项目业务逻辑写得漂漂亮亮结果一个悬垂指针在生产环境里偶发踩内存排查两周才定位到一行早就被释放的指针还在被读。内存管理这个话题听起来像面试八股实际上它是每个写 C/C 的人绕不过去的基本功栈和堆怎么分、malloc 家族各自什么脾气、new/delete 和它们差在哪、智能指针什么时候该上什么时候是负担、结构体为什么莫名其妙大了 8 个字节、内存泄漏怎么在本地就逮住。这篇文章我打算按我自己平时带人和排障的思路从地址空间分区讲到 C 的手动管理再讲到 C 的对象生命周期与 RAII最后落到对齐、内存池和工具链实战。不管你是刚学完指针、正在用 VS Code 配 C/C 环境的新手还是写过几年代码但对 shared_ptr 循环引用还有点含糊的从业者都能从中拿走可以直接用的东西。1. 进程地址空间的地图先把五块地标清楚1.1 五个分区到底谁管谁很多人背过“栈区、堆区、全局区、常量区、代码区”但真正写代码时对不上号。我习惯用一张表把它们钉死因为后面所有的内存问题本质都是“某个字节属于哪块地、由谁负责释放”。分区典型内容生命周期谁负责回收栈 stack局部变量、函数参数、返回地址随函数调用结束自动销毁编译器生成的指令堆 heapmalloc/new 出来的对象从申请到显式释放程序员全局/静态区全局变量、static 变量程序整个运行期进程退出时系统回收常量区字符串字面量、const 全局量程序整个运行期通常只读系统代码区机器指令程序整个运行期系统这张表里最需要盯住的是堆那一行“程序员负责回收”六个字就是 C/C 内存问题的主要来源。栈上的东西你几乎不用管编译器会在函数返回时插一条调整栈指针的指令整块栈帧一次性回收堆不行堆是一大片由分配器统一管理的区域你必须自己把借出去的那块还回来还早了会踩空还晚了会漏还错了会直接把分配器的元数据搅烂。还有一点容易被忽略全局/静态区其实分成.bss和.data两段。已初始化为非零的全局变量放在.data未初始化或者初始化为 0 的放在.bss。.bss段在可执行文件里不占空间只在加载时由系统清零分配所以一个大数组如果写成int buf[1024*1024];未初始化和写成int buf[1024*1024] {1};已初始化编译出来的二进制体积差别可能有好几 MB。这个细节在做嵌入式或者对包体积敏感的场景里非常实用。1.2 一个变量到底住在哪用代码对照光看表容易忘直接上代码看地址最直观。下面这段在 Linux x86-64 上跑每次输出顺序基本固定数值会变但相对关系稳定#include stdio.h #include stdlib.h int g_init 42; // .data int g_uninit; // .bss const char *msg hello; // 指针在 .datahello 在 .rodata int main(void) { int local 1; // 栈 static int st 2; // .data有初值 int *heap malloc(sizeof(int)); // 堆 *heap 3; printf(code (main) : %p\n, (void*)main); printf(rodata(\hello\) : %p\n, (void*)msg); printf(data (g_init) : %p\n, (void*)g_init); printf(bss (g_uninit): %p\n, (void*)g_uninit); printf(heap (heap) : %p\n, (void*)heap); printf(stack (local) : %p\n, (void*)local); free(heap); return 0; }典型输出从低地址到高地址大致是代码区 → 常量区 → 全局/静态区 → 堆 → 栈。注意堆和栈之间隔着巨大的空洞堆往高地址长栈往低地址长两者相向而行中间那段未映射区域就是保护带一旦哪边越界撞上去操作系统直接给你一个段错误这其实是好事快速暴露问题总比默默改坏数据强。如果你在 VS Code 里调试可以直接在WATCH面板里填local、heap或者在调试控制台敲x/4xb heap用 GDB 的 examine 命令看这四字节内容比 printf 更灵活尤其是-O0编译的时候变量地址和源码能一一对上观察内存布局基本就靠这个手段。1.3 栈为什么放不下大数组栈的大小是有限制的Linux 默认单线程栈通常是 8MB用ulimit -s可以查Mac 上一般是 8MBWindows 默认保留 1MB。这个数字决定了一件很实际的事函数里写char buf[16 * 1024 * 1024];会直接栈溢出程序在进入函数那一刻就崩了甚至连报错信息都来不及打。堆就没这个限制吗也不是堆受限于进程可用的虚拟地址空间和物理内存但在 64 位系统上这个天花板高得多而且分配器是按需向操作系统要页的你不用不花。所以工程上的经验是小于几 KB 的临时缓冲放栈上几十 KB 以上的一律上堆别为了图省事写个大数组在栈上那个坑在本地跑得好好的换台机器栈限制小一点就炸。顺带说一个常见误解alloca也是在栈上分配和malloc长得像但完全不是一回事它随函数返回自动回收且失败行为不可控除了极少数性能敏感的场合我不建议用。2. C 的手动内存管理malloc 家族的脾气2.1 malloc、calloc、realloc 到底怎么选这三个函数加上free构成了 C 语言堆管理的全部原语。它们看着简单但每个都有各自的性格函数是否清零参数含义典型用途malloc(n)否字节数通用分配追求速度calloc(cnt, size)是元素个数 × 元素大小需要零初始化的数组、结构体数组realloc(p, n)新扩展部分不保证清零原指针 新字节数动态扩容free(p)不适用释放指针归还内存关于calloc很多人以为它就是把malloc加memset其实在底层实现上不完全是操作系统给新页的时候本来就是清零的calloc可以省掉一次显式清零所以“为清零付费”这个直觉在很多时候是反的。真正需要小心的是乘法溢出calloc(cnt, size)内部会检查cnt * size是否溢出而malloc(cnt * size)不会你自己算的那一步可能已经把size_t撑爆了结果申请到一块小得多的内存后面写越界。所以凡是用malloc(count * size)的地方稳妥写法是先判断count SIZE_MAX / size。realloc是最容易写错的一个。它有三种返回情形原地扩容成功、搬到新地址、失败返回 NULL 且原指针仍然有效。第三点特别关键下面这个写法是错的p realloc(p, new_size); if (p NULL) { /* 原来的 p 已经丢了内存泄漏 */ }正确姿势永远是先接住返回值确认成功再赋值void *tmp realloc(p, new_size); if (tmp NULL) { /* 处理失败p 仍然指向原来的块可以继续用或者 free(p) */ } else { p tmp; }还有两个边界情况值得记住realloc(p, 0)在 C99 之后行为是实现定义的可能返回 NULL 也可能返回一个可以free的指针别依赖它malloc(0)同样是实现定义可能返回 NULL 也可能返回一个不可解引用但可free的指针实际写业务代码时最好在分配前就挡掉 0 的情况。2.2 分配失败必须处理别假设内存永远够malloc失败返回 NULL这个大家都知道但真正在代码里写检查的人不到一半。桌面程序内存充足时确实很难触发可一旦到了嵌入式设备、容器内存受限环境、或者有内存配额限制的服务里这就是必崩的隐患。更麻烦的是失败之后如果你直接解引用崩溃点往往离真正的原因很远。我的习惯是给分配包一层static void *xmalloc(size_t n) { void *p malloc(n); if (p NULL n ! 0) { fprintf(stderr, out of memory: %zu bytes\n, n); abort(); } return p; }小工具、命令行程序用abort快速失败完全合理因为此时程序已经无力回天硬撑着继续跑只会写出更难查的错误数据。但服务端程序不能这么干得走降级路径拒绝这次请求、释放缓存、返回错误码让上层决定怎么办。2.3 五个高频错误每个都能给你上一课第一个内存泄漏。申请了忘记还或者在某条提前 return 的分支上漏掉了free。长生命周期进程里泄漏会慢慢把内存吃干最终被系统杀掉。它的可怕之处在于短期内完全看不出来。第二个悬垂指针。free(p)之后p的值没变仍然指向那块已经被回收的内存。此时读它可能还是旧数据因为分配器还没复用写它就会污染后来者的数据。我个人的硬规矩是free(p); p NULL;虽然不能解决所有别名问题但能挡掉相当一部分手误。第三个重复释放。同一块内存free两次现代分配器通常会直接 abort 并打印 “double free or corruption”算是比较友好的但在老版本 glibc 上可能被利用来执行任意代码。这个问题的根因通常是所有权不清两个模块都以为自己是 owner。第四个越界写。char buf[10]; strcpy(buf, 0123456789abc);这类写法写坏了堆块的尾部元数据崩溃可能发生在下一次free或者下一次malloc的时候跟出错点隔了十万八千里。这也是为什么这类 bug 特别难查你会一直怀疑分配器而不是自己的代码。第五个sizeof 指针。int *p malloc(sizeof(p));在 64 位机器上只给了 8 字节你以为给了sizeof(int)。更隐蔽的是malloc(n * sizeof(char *))写成malloc(n * sizeof(char))差了一个星号越界写到怀疑人生。这个错我至少见过三次每次都有人盯着看半天没看出来。提示只要是手写malloc就把「分配大小」「判空」「初始化」「释放」「置空」当成五步固定流程写下来别省步骤省下来的那几行迟早要用加班还。3. C 这一层多出来的东西对象生命周期与 RAII3.1 new/delete 和 malloc/free 的本质区别C 里new不只是“分配内存”它是两步先调用operator new拿到一块原始内存然后在这块内存上调用构造函数。delete反过来先调析构函数再调operator delete归还内存。malloc/free只做第一步和最后一步中间的对象构造和析构完全不参与。对比项malloc/freenew/delete构造/析构不调用调用失败行为返回 NULL抛 std::bad_alloc返回类型void*具体类型指针大小计算手动 sizeof编译器推导重载不可重载可重载 operator new与类的关系无关与类绑定可定制实践里最常踩的一点是new出来的对象只能用deletemalloc出来的只能用free两者绝对不能交叉。原因很直接分配器不一样operator new默认最终走malloc但一个类可能重载了operator new走的是自定义内存池你用free去还它等于把内存还给了错误的账本。另一个是失败行为差异。裸new失败抛异常如果你在一个不处理异常的老代码库里用可能直接 terminate。想沿用 C 风格的话写法是new (std::nothrow) T它会返回空指针。我的建议是既然用 C就接受异常语义把new放在能捕获或者能传播的位置别混着用。3.2 new[] 和 delete[] 为什么不能混用new[]在分配数组时会额外存一份“元素个数”的信息特别是在元素类型有非平凡析构函数的时候。delete[]需要读这个 cookie 才知道要调用多少次析构。你如果写成delete p缺了方括号它只析构第一个元素剩下的内存和资源全漏了而且因为没有按数组方式释放还可能把分配器的元数据搞错。对于没有析构函数的基本类型数组比如int* p new int[10]; delete p;很多实现上“看起来没事”因为不需要逐元素析构但这依然是未定义行为换个编译器或者换个类型就可能崩。所以规矩就一条方括号成对出现。顺带提一句现代 C 里裸new[]已经很少见了std::vector、std::array、std::string基本能覆盖绝大部分需求能不用裸数组就别用。3.3 RAII 与智能指针选型RAII 是 C 内存管理的核心思想把资源的生命周期绑定到对象的生命周期上对象出作用域就自动释放。智能指针是这条思想最直接的落地。std::unique_ptr是零开销抽象默认删除器下它的大小和裸指针完全一样拷贝被禁用只能移动表达的是唯一的独占所有权。日常写代码我默认就是它。只要看到“这个资源只在一个地方持有”就用unique_ptr需要传递时用std::move明确表示所有权转移。std::shared_ptr带引用计数拷贝时计数加一最后一个释放时对象销毁代价是一个控制块引用计数、弱引用计数、删除器等拷贝会带来原子操作开销。它适合“多个对象共同持有谁都可能最后退出”的场景比如一个配置对象被多个模块共享。std::weak_ptr不增加强引用计数主要是观察者身份用来打破shared_ptr的循环引用。它不能直接解引用必须先lock()拿到一个临时的shared_ptr判断非空再访问。这里有个选型经验能 unique_ptr 就别 shared_ptr。shared_ptr一旦开始在全项目蔓延对象的销毁时机就变得难以预测而且引用计数循环问题会一个接一个冒出来。我在 review 代码的时候看到不必要的shared_ptr会直接要求改成unique_ptr 裸引用参数。3.4 shared_ptr 的循环引用与 weak_ptr 破环循环引用是shared_ptr最经典的坑标准场景是双向链表或者父子节点互指struct Node { std::shared_ptrNode next; // 强引用 std::shared_ptrNode prev; // 强引用 };两个节点互相持有引用计数永远下不到 0两块内存都泄漏。解决办法是把其中一个方向改成weak_ptrstruct Node { std::shared_ptrNode next; std::weak_ptrNode prev; // 弱引用不计数 };使用prev的时候要auto p prev.lock(); if (p) { ... }。还有一个更隐蔽的泄漏点make_shared会把对象和控制块分配在同一块内存里这本来是性能优势少一次分配、缓存局部性好但它有个副作用——只要有任意一个weak_ptr还活着整块内存包括对象所占的那部分就不能被释放只有对象析构函数会跑。所以如果你的场景里weak_ptr会长期存活而对象本身很大可能反而用shared_ptrT(new T)更合适让对象内存能早一点归还。这个细节很多人不知道但在大对象 大量 weak_ptr 观察者的场景下会造成明显的内存占用。注意自定义删除器也是容易漏的地方。用shared_ptr管理文件句柄、socket、C 库资源的时候一定要在构造时传删除器否则默认走delete直接崩。4. 对齐、padding 和对象布局看不见的内存开销4.1 对齐规则与结构体大小计算CPU 读内存不是一字节一字节读的而是按总线宽度成块读的所以访问对齐的地址要快得多某些架构上访问未对齐地址甚至直接触发异常。编译器为了保证对齐会在结构体成员之间插入填充字节这就是 padding。对齐的基本规则有三条每个成员的起始地址必须是它自身对齐数的整数倍对基本类型来说对齐数通常等于其大小结构体的对齐数等于其成员中最大的对齐数整个结构体的大小必须是这个对齐数的整数倍。拿一个例子算struct A { char a; // 偏移 0占 1 字节 int b; // 需要 4 字节对齐偏移 4前面补 3 字节 char c; // 偏移 8占 1 字节 }; // 结构体对齐数是 4总大小补到 12sizeof(struct A)是 12不是 6。三个成员实际有效数据只有 6 字节一半是填充。把成员顺序调一下struct B { int b; // 偏移 0 char a; // 偏移 4 char c; // 偏移 5 }; // 补到 8sizeof(struct B)变成 8白白省下 4 字节。这个技巧叫“按大小从大到小排列成员”在需要大量实例的场景比如顶点数组、粒子系统里省下来的内存和带宽非常可观。如果你确实需要紧凑布局比如解析网络协议包、读写磁盘格式可以用#pragma pack(1)或者__attribute__((packed))关掉填充。但要注意打包之后成员可能未对齐在部分平台上访问会变慢甚至崩而且不能直接对打包结构里的成员取地址传给需要对齐的函数。我的做法是协议结构用打包内存里的结构用自然对齐两者之间显式做一次转换。C11 之后还可以用alignas/alignof精确控制struct alignas(64) CacheLinePadded { int value; };这样每个实例都占据完整的缓存行避免相邻对象互相干扰。4.2 缓存友好与伪共享比对齐更高一层的是缓存局部性。CPU 缓存以缓存行为单位x86 上一般是 64 字节。如果你的程序频繁访问分散在内存各处的对象每一次都可能触发缓存未命中性能差距可能是几倍到几十倍。一个具体例子遍历一个std::vectorLargeStruct和遍历一个std::vectorLargeStruct*前者内存连续预取器能提前把后面的缓存行拉进来后者每次都是随机跳转。这就是为什么现代 C 强调“数据导向设计”把热数据放在一起用数组代替链表。多线程场景下还有一个坑叫伪共享两个线程分别修改同一缓存行里的不同变量虽然逻辑上没有冲突但硬件层面这一行会被反复失效和同步性能急剧下降。解决办法是给变量加填充让它们落在不同的缓存行上struct Counter { alignas(64) std::atomiclong value{0}; // 后续填充到 64 字节避免和邻居共享缓存行 char pad[64 - sizeof(std::atomiclong)]; };这个技巧在无锁队列、高频计数器里非常常见代价是内存变大需要权衡。4.3 内存池把 malloc 的次数降下来malloc本身并不慢但它在高频小对象场景下有几个问题每次分配都要走一遍分配器的查找逻辑分配出来的块之间不连续头部还有管理元数据开销glibc 里每个块至少有 8 到 16 字节的头部。如果你要分配一百万个 16 字节的小对象光元数据就吃掉几十 MB。内存池的思路很朴素一次性向系统要一大块然后自己切成小片发出去。最简易的实现就是一个空闲链表typedef struct Block { struct Block *next; } Block; typedef struct { Block *free_list; char *chunk; size_t chunk_size; } Pool; void pool_init(Pool *p, size_t chunk_size) { p-chunk_size chunk_size; p-chunk malloc(chunk_size * 1024); p-free_list NULL; char *cur p-chunk; for (int i 0; i 1024; i) { Block *b (Block *)(cur i * chunk_size); b-next p-free_list; p-free_list b; } } void *pool_alloc(Pool *p) { if (!p-free_list) return NULL; // 简化版不考虑扩容 Block *b p-free_list; p-free_list b-next; return b; } void pool_free(Pool *p, void *ptr) { Block *b (Block *)ptr; b-next p-free_list; p-free_list b; }这个版本只适合固定大小对象但已经能覆盖很多场景比如网络库里的连接对象、游戏里的实体节点。真实的生产级内存池还要处理对齐、不同 size class、线程安全通常每线程一个池避免加锁、以及与析构函数的配合。C 里给容器配自定义分配器也是同一思路std::pmr多态内存资源从 C17 开始提供了一套标准化的接口可以给std::pmr::vector指定一个monotonic_buffer_resource在一块预分配的大缓冲区上做 bump 分配退出时一次性释放特别适合请求级别或者帧级别的临时数据。提示内存池不是万能药。它解决的问题是“大量同尺寸小对象、生命周期相近、需要低延迟”。如果你的对象大小差异巨大、生命周期长短不一自建内存池反而容易造成碎片和复杂度失控老老实实用 malloc 或者 jemalloc、tcmalloc 这类成熟分配器更划算。5. 实战把内存问题在现场抓出来5.1 用 VS Code GDB 直接看内存排查内存问题光靠读代码是不够的必须能在现场看内存。VS Code 配 C/C 调试环境是一个性价比很高的选择关键是几个配置细节。编译的时候一定要加-g -O0-g生成调试信息-O0关掉优化否则变量会被优化掉、行号会对不上。tasks.json里大概是这样{ version: 2.0.0, tasks: [ { label: build-debug, type: shell, command: gcc, args: [-g, -O0, -Wall, -Wextra, -fsanitizeaddress, ${file}, -o, ${fileDirname}/a.out], group: { kind: build, isDefault: true } } ] }launch.json里指定用 gdb{ version: 0.2.0, configurations: [ { name: Debug (gdb), type: cppdbg, request: launch, program: ${fileDirname}/a.out, args: [], stopAtEntry: false, MIMode: gdb, setupCommands: [ { description: 启用美化打印, text: -enable-pretty-printing, ignoreFailures: true } ] } ] }调试时最有用的几个操作在WATCH面板里加*(int*)ptr看指针指向的值在调试控制台敲x/16xb ptr看 16 个字节的十六进制敲p *node看结构体展开。如果智能提示偶尔犯懒、结构体成员补全不出来多半是c_cpp_properties.json里的includePath或compileCommands没配好把它指向你的compile_commands.jsonCMake 加-DCMAKE_EXPORT_COMPILE_COMMANDSON就能生成通常一步到位。这里要提醒一句-fsanitizeaddress和某些调试器的内存观察功能会互相干扰如果你要单步看内存可以先用不带 sanitizer 的版本如果只是要跑一遍抓错误那就用带 sanitizer 的版本一次编译两套配置launch.json里配两个 configuration 切换。5.2 valgrind、ASan、mtrace 三件套怎么选工具不在多在于用对场景。我一般按下面的方式选工具使用方式优势局限AddressSanitizer编译期-fsanitizeaddress -g速度快能抓越界、悬垂、泄漏需要重编译内存占用上升valgrind memcheck直接跑二进制不用改编译报告详细慢 10 到 30 倍不适合长跑mtrace链接 glibc 并设置环境变量轻量能看分配调用栈只覆盖 malloc/freeASan 是我日常首选。加-fsanitizeaddress编译程序跑起来越界写会立刻报错并且给出分配点和越界点的两处调用栈定位效率极高。检测泄漏再加-fsanitizeleak或者用ASAN_OPTIONSdetect_leaks1。要注意的是ASan 默认会拦截malloc/free如果你用了自定义分配器或者内存池可能需要给它加注解否则它看到的是大块内存无法知道内部的细分边界。valgrind 的优势是不用重新编译线上出的问题拿个带-g的二进制就能跑。命令大概是这样valgrind --leak-checkfull --show-leak-kindsall --track-originsyes ./a.out--leak-checkfull会区分 definitely lost、indirectly lost、possibly lost、still reachable 四种情况其中 still reachable 通常不用太担心比如全局单例在退出时没释放definitely lost 才是真泄漏。--track-originsyes能追踪未初始化值的来源排查“用了没初始化的内存”类问题特别有效。mtrace 最轻量在代码里加两行#include mcheck.h int main(void) { mtrace(); /* ... 业务代码 ... */ muntrace(); return 0; }然后运行前设MALLOC_TRACE./mtrace.log程序结束后用mtrace ./a.out mtrace.log解析每个未配对的malloc都会列出来。它不会告诉你越界但能干净地告诉你是谁漏了。5.3 内存问题速查表排障的时候我习惯先对症状再看方向症状可能原因首选排查手段程序随机崩溃崩溃点每次不同堆越界写或悬垂指针ASan 重新编译跑一遍运行时间越长内存越大内存泄漏valgrind leak-check 或 ASan leakfree 时报 double free重复释放或所有权不清ASan 看两次 free 的调用栈析构函数只跑了一次new[]/delete 混用检查方括号是否成对结构体大小比预期大对齐填充打印每个成员偏移重排成员多线程下性能突然下降伪共享perf c2c 或手动 padding 验证程序退出时才报错全局对象析构顺序问题检查静态对象间的依赖这里补一句关于“退出代码”的排查经验进程退出码如果是 1341286说明收到了 SIGABRT多半是 glibc 检测到堆损坏主动 abort如果是 13912811是 SIGSEGV 段错误如果退出码是正常返回但内存监控显示没降下来那就要怀疑静态对象或全局缓存没释放这类“退出时泄漏”通常无害但会干扰监控指标值得单独处理。6. 常见问题与我的几条硬规矩6.1 十个被问得最多的问题局部数组能不能 return不能栈帧销毁后那块内存就不属于你了返回的是悬垂指针。要返回就用malloc、static注意线程安全或者让调用方传缓冲区进来。free 之后指针要不要置空要虽然不能解决别名问题但能挡掉一部分重复释放和误用。同理delete之后也建议置空尤其在类的成员里。malloc 和 new 能不能混用分配和释放必须配套跨语言的场景比如 C 库返回的内存要看文档约定的释放方式很多库提供专门的xx_free就是因为它内部有自己的分配器。智能指针能不能管理数组unique_ptrT[]可以shared_ptrT[]从 C17 开始也支持但更推荐用std::vector或std::array语义更清楚。引用计数是不是线程安全的shared_ptr的引用计数操作是原子的所以多线程拷贝、销毁同一个shared_ptr对象是安全的但多个线程同时读写“同一个 shared_ptr 变量本身”不是安全的需要加锁或者用std::atomicstd::shared_ptrTC20。为什么我的程序没泄漏但内存一直涨可能是碎片也可能是分配器缓存glibc 的 arena、tcache没有归还给系统还可能是容器的size()没变但capacity()涨上去没下来shrink_to_fit或者 swap 一下能解决。placement new 出来的对象怎么销毁手动调析构函数p-~T();然后自己归还内存。它不分配内存只是在给定地址上构造配套使用很容易出错非必要不用。为什么结构体加了虚函数就变大了因为多了虚表指针vptr64 位下通常 8 字节而且它是对齐边界的一部分可能连带产生填充。能不能用 memset 初始化包含 std::string 的结构体绝对不能memset只做字节级清零会把std::string的内部指针清成空后续析构直接崩。要清零就用 {}或者显式构造函数。栈溢出怎么提前发现可以用-fstack-protector-strong加金丝雀检测深度递归的场景考虑改成显式栈用std::vector模拟递归既避免栈溢出又能控制内存上限。6.2 我给自己定的几条规矩写了这么多年我慢慢固定下来几条习惯说出来供参考。第一条谁分配谁释放跨模块传递必须写清楚所有权是转移、借用还是共享用类型表达出来unique_ptr表示转移裸指针或引用表示借用shared_ptr表示共享看到类型就知道该怎么用。第二条构造函数里如果申请了资源析构函数必须释放且中间抛异常不能漏这也是为什么优先用容器和智能指针而不是裸指针成员它们已经帮你处理了异常安全。第三条新代码默认开 ASan 跑测试CI 里加一个 sanitizer 构建的 job成本很低收益是所有越界和泄漏在合并前就被挡住。第四条不为了省内存去关掉对齐除非有明确的协议或存储格式需求那点内存换来的性能损失通常不值。最后再分享一个我一直在用的小检测习惯在开发阶段给程序加一个内存统计的钩子重载operator new/operator delete或者用-Wl,--wrapmalloc统计当前未释放的字节数和块数然后在服务的健康检查接口里暴露出去。这样每次压测结束、每次线上跑一段时间之后你都能一眼看到那两条曲线是否回到基线。回归基线就是干净的持续缓慢上升就是有泄漏。这个办法比事后拿 valgrind 追栈要主动得多很多时候问题在冒头阶段就被摁住了。真要遇到曲线异常又一时定位不到再上 ASan 或者 valgrind 做一次定向排查两者配合起来内存这块基本就不会再给你制造意外了。
