1. C/C 内存分布全景程序运行时你的代码到底住进了哪些格子间很多初学者刚开始学 C/C 的时候都会被“内存分布”这个词吓到觉得是个很高深的概念。其实说白了这就是搞清楚一件事你写的那几行代码、声明的变量在程序跑起来之后到底被放进了哪块区域各自的存活时间又是多久。我见过不少朋友学了半年指针还时常把栈和堆搞混写出来的程序要么莫名其妙崩溃要么内存泄漏到怀疑人生根子就在于对内存分布没有建立起“地图感”。一个正在运行的 C/C 程序它的地址空间从低地址到高地址大致可以分为这几个区域代码区、常量区、全局区静态区、堆区、栈区。每个区域都有自己的脾气和规矩谁放错了地方谁提前被释放程序就会用段错误或者乱码来惩罚你。这里澄清一个常见的误区很多人以为栈是高地址、堆是低地址这个说法没问题但同时要知道不同的操作系统、不同的编译器和链接脚本具体的地址布局会有细微差别我们讨论的是一种典型布局这一点在排查问题时很重要。搞清楚内存地图的意义在于你写的每一行代码都在和这些区域打交道。函数调用时的参数、局间变量走栈程序运行期间动态创建的对象走堆字符串字面量、全局变量、static 变量走常量区和全局区。而这篇文章标题里提到的 new/delete 和 malloc/free正是堆区操作的两大核心工具。它们俩是很多人从 C 过渡到 C 后最容易原地犯迷糊的地方也是面试中被问烂了却依然能问出花来的知识点。接下来我带着你把这几个区域逐一走一遍然后用一次完整的项目实操把 new/delete 和 malloc/free 的底层差异、搭配陷阱全部串起来最后附上我这些年踩过的坑和排查经验。2. 五块核心内存区域拆解先给代码和变量“对号入座”2.1 代码区与常量区程序启动阶段就已经定下来的“规矩”代码区存放的是编译后生成的机器指令也就是程序的可执行二进制内容。它在程序运行之前就已经确定并且在运行期间只读任何人想往代码区里写数据操作系统会直接拦下来报一个写入权限错误。这块区域不需要我们主动管理编译器、链接器已经在生成可执行文件的时候处理好了分配和布局。常量区紧挨着代码区存放的是诸如字符串字面量比如hello world、全局常量const int g_x 10这类在编译期就能确定值的数据。这里有个很重要的细节字符串字面量和const修饰的全局变量虽然在语义上都是“常量”但它们的存放位置和可变性在标准 C 里并不完全一致。拿字符串字面量举例const char* p abc;这里的abc存在常量区理论上不允许修改一旦你写出p[0] x;这种代码在部分编译器上可能编译通过但运行时就崩给你看。这是因为 C 标准明确规定修改字符串字面量属于未定义行为不同平台的具体表现差异极大我在某套老旧嵌入式工具链上甚至见过它被放在可写区域的情况。代码区和常量区还有一个特点它们的地址在整个程序生命周期内都不会变化也不会被释放。这跟后面的堆和栈形成了鲜明对比所以你在调试的时候如果发现某个指针指向的地址非常低比如0x8048xxx基本可以判断它指到了代码区或者常量区这时候去修改它就等于找不自在。2.2 全局区与静态区static 和全局变量的“养老院”全局区也叫静态区存放的是全局变量、静态变量static 修饰的局部变量或全局变量以及常量中的一部分。它通常在程序加载完成后就分配完毕一直存活到程序结束才被系统回收。注意全局区里面还可以细分已初始化的全局变量和静态变量放在.data段未初始化的放在.bss段。.bss段有个特殊之处它不占用可执行文件里的实际磁盘空间只是一个占位标记程序装载时由操作系统清零。这就解答了一个经典的初学者困惑为什么未初始化的全局变量默认是 0而局部变量是随机值因为全局变量走的是.bss段系统会统一清零而局部变量走栈栈上存着上一次函数调用留下的残留数据读出来自然是“脏”的。static 局部变量也是一个经常被误解的角色它虽然在函数内部声明但作用域被限制在函数内生命周期却和全局变量一样长。它在首次执行到声明语句时才完成初始化之后即使函数退出再重新进入也不会重新初始化。这里给大家一个实际排查场景我去年在做网络协议栈优化的时候发现一个统计连接数的计数器在并发场景下数据错乱查了半天最后发现是定义成了普通的局部变量每次进函数都被重新初始化。把它改成 static 之后问题当场消失。这就是内存区域选择直接影响程序行为的典型例子每个区域都有自己的生存周期不匹配就会出问题。2.3 栈区函数调用的“临时工”聚集地栈区是个后进先出的结构每次函数调用都会在栈上压入一块栈帧函数返回时自动弹栈释放。栈上存放的内容包括函数参数、局部变量、函数返回地址等。这个“自动”是栈最迷人的地方——不需要我们手动管理内存进入作用域分配离开作用域释放一气呵成。但自动也意味着约束。栈的大小不是无限的Linux 下默认通常是 8MBWindows 下一般是 1MB 左右具体可以通过ulimit -s或者编译器选项查看调整。如果你的函数里定义一个超大的局部数组比如int a[1000000]4MB 直接压栈很可能当场栈溢出崩溃。这不是危言耸听我见过不少同学在递归函数里声明大数组或者大对象然后运行就段错误跑回来问为什么——其实就是栈被撑爆了系统无路可退只能强杀进程。栈上分配还有一个显著特点分配速度极快因为它本质上只是移动一下栈顶指针。这样我们在写高频调用的函数时应优先考虑把临时的小对象放在栈上而不是动不动就 new 到堆里。栈上对象大小在编译期就确定了不存在动态分配的开销更没有内存碎片的问题这对性能敏感型应用非常重要。2.4 堆区唯一需要“手动记账”的动态内存区域堆区是 C/C 程序里最自由也最危险的地方。它是一个大容量的动态内存池程序在运行期间可以随时向操作系统申请任意大小的内存块用完再归还。也正是因为这个“随时申请”堆区必须由程序员自己管理申请和释放必须成对出现漏一个就泄漏重复释放就会崩溃。堆区的位置在全局区和栈区之间在典型 Linux 进程地址空间里它从低地址往高地址增长而栈从高地址往低地址增长两个区域相向而行。历史上有个著名梗如果堆和栈在中间相遇了通常意味着内存耗尽或者栈溢出。现代操作系统已经有非常完善的虚拟内存管理和进程隔离机制实际场景基本不会走到这一步但理解这个相向而行的模型对理解地址布局还是有很大好处。malloc/free 和 new/delete 操作的内存都属于堆区。它们底层都会向操作系统申请内存但实现机制上有明显差异malloc 通常会维护一个空闲链表管理已申请的内存块通过首次适配或最佳适配算法找到合适的空闲块new 在 C 里则是一个运算符由编译器隐式地调用 operator new 和构造函数。这个差异后续章节会专门展开。在使用堆区时有两条铁律。第一谁申请谁释放严禁跨模块释放内存比如 A 模块用 malloc 申请的内存交给 B 模块用 free 释放在部分运行时环境里会造成堆管理数据结构错乱。第二申请完必须立即检查返回值malloc 失败会返回 NULLnew 失败虽然不推荐旧式写法会抛出异常或返回空指针忽略返回值随便写等于埋了一颗定时炸弹。3. new/delete 与 malloc/free 正面硬刚从底层原理到使用禁忌3.1 函数与运算符的本质差异为什么说 new 是“开箱即用”第一个根本性差异malloc/free 是 C 标准库提供的函数new/delete 是 C 语言层面的运算符。这不是文字游戏而是底层机制上的分道扬镳。malloc 只做一件事分配一块裸内存返回 void* 指针它压根不知道什么是对象什么是构造函数。new 则做了三件事调用 operator new 函数通常是封装了类似 malloc 的底层逻辑申请内存、调用类型对应的构造函数初始化对象、最终返回类型化指针。delete 做的则是调用析构函数销毁对象、调用 operator delete 释放内存。因为 new 是运算符所以 C 允许我们对它进行重载。当你用new创建一个自定义类型对象时编译器会生成大致如下的伪代码// 编译器视角的 new 处理过程伪代码 void* mem operator new(sizeof(MyClass)); // 1. 分配原始内存 MyClass* obj new (mem) MyClass(); // 2. 在内存上调用构造函数placement new看到了吗分配内存和构造对象是拆成两步的。这也解释了为什么 new[] 在分配对象数组时会在实际数据块前面额外申请一小块内存来记录数组元素个数这样 delete[] 才能正确地逐个调用析构函数。如果你写的是delete而不是delete[]编译器会按单个对象处理数组里其他对象的析构函数不会被调用同时可能引发内存释放时的地址错位问题。而 malloc 根本不知道构造函数这回事它只负责把内存交给你。如果你用 malloc 去“创建”一个 C 对象你得手动调用构造函数技术上可以通过 placement new 实现用完之后还得手动调用析构函数再用 free 释放。麻烦不说还容易漏掉中间步骤。这就是很多人过渡到 C 之后坚决拥抱 new/delete 的原因——安全、语义统一、不易出错。3.2 内存大小计算sizeof 与元素个数的关系一个非常经典的坑new MyClass[10]到底申请了多少内存很多人以为就是sizeof(MyClass) * 10但前面提到编译器为了支持 delete[] 正确调用析构函数会在实际数组内存块之前额外存一个“元素计数”对某些编译器而言也可能存在对齐填充。所以底层申请的内存大小实际上是sizeof(size_t) sizeof(MyClass) * 10这里 的sizeof(size_t)就是那个额外的计数区域。如果你用malloc手动分配一个类似的数组malloc(sizeof(MyClass) * 10)然后再试图用delete[]去释放它就把释放的起始地址也搞错了——delete[] 会假设某个偏移量处有个计数这块区域不是你分配出来的于是堆管理器直接判定非法释放程序崩溃。这是我见过最经典的跨用崩溃场景之一实际报错信息千奇百怪有的在 free 阶段就挂有的在后续自检时才被发现。从工程角度这个“额外计数”的精确实现依赖编译器和运行时库标准并没有规定细节。所以最安全的做法就是代码里绝对不要手动猜测数组内存布局老老实实让 new[]/delete[] 成对出现。如果你确实需要精确控制内存就完全用 malloc/free 或者封装自己的内存分配器不要混用。3.3 失败处理与返回值异常机制带来的戏剧性差异malloc 分配失败时返回 NULL你检查返回值就知道了。new 分配失败时标准行为是抛出std::bad_alloc异常而不是返回 NULL除非使用nothrow版本int* p new (std::nothrow) int[100];。这个差异在实际工程里会产生很大的分支影响。假设你在一个使用旧式异常规范的项目里或者出于某种原因不想让异常跨模块传播用 new 分配内存不做保护一旦内存不足抛出异常而外层又没有捕获程序会直接终止。反过来如果你用malloc而不检查返回值返回 NULL 后直接解引用操作系统的内存保护机制会立刻用段错误回应你。两种失败模式的崩溃形式完全不同。从稳健工程的角度我建议当项目选择使用 C 异常机制时用 new 并在外层统一捕获 std::bad_alloc如果项目是嵌入式、或者禁用异常那就显式使用new (std::nothrow)并检查返回指针或者干脆退回 C 风格的 malloc 并检查 NULL。决定好了就统一到底不要在代码里今天用 new 明天用 malloc两手抓的结果就是两边的风险都踩。3.4 内存对齐与内部碎片malloc 和 new 都会面对的问题很多人有个误解觉得 malloc/new 从操作系统拿到内存之后我想怎么用就怎么用。事实上内存分配器为了保证任何类型的变量都能安全地存储到返回的地址上默认会按最大对齐要求来处理。常见的最大对齐是 16 字节x86-64 架构下SIMD 类型需要 16 或 32、64 字节对齐但标准库通常会保守地选择至少能兼容内置类型的对齐值。这也是为什么 malloc 的实现在底层往往还有一个对齐处理逻辑比如 glibc 的 malloc返回的地址至少是 8 字节对齐在 64 位平台上通常满足 16 字节对齐。如果你明确需要一个超大对齐的缓冲区比如用 AVX-512 指令集需要 64 字节对齐就得使用 C11 引入的alignasaligned_allocC11或std::aligned_allocC17或者用posix_memalign这类平台扩展。内部碎片这个问题则更隐蔽你申请 35 字节分配器为了保证对齐、方便追踪可能在一整块 48 字节的空闲块里切出 40 字节给你剩下的 8 字节就成了碎片。长年累月混用不同大小的分配堆里留下的碎块会越来越多大块分配申请失败的次数也会增加。这正是我下面要讲的几个实战经验中非常核心的一个。4. 实操从零搭建一个内存分配器监控示例亲测上线4.1 环境与工程结构手把手确认你的编译器行为聊了这么多原理咱们直接动手做个实验把上述所有差异通过代码验证一遍。我用的是 Ubuntu 22.04 g 11.4内存监控用的是 system 自带的/proc/PID/status里的VmSize、VmRSS字段。这套方法不管在 Linux 服务器还是树莓派上都能直接用Windows 上想复现类似效果可以用任务管理器或 Process Explorer 观察但字段含义有差异。工程很简单就三个文件MemTest.cpp主逻辑、MemoryStats.h/cpp封装一段读取 /proc 字段的辅助代码。然后我们逐步测试全局变量位置、static 变量生命周期、栈上对象地址趋势、堆上对象地址趋势、new/delete 与 malloc/free 混用时的崩溃现场。# 编译方式注意 -g 保留调试信息方便看崩溃栈 g -g -O0 MemTest.cpp MemoryStats.cpp -o memtest ./memtest我特意用-O0而不用优化是因为优化后的代码可能把变量优化掉也会改变栈帧布局导致地址趋势不明显。做这种内存地址实验优化级别越接近零越好这一点在对比测试时必须注意。4.2 地址趋势观测亲手画出堆和栈的“面对面增长”这套实验的核心代码是对同一进程打印各阶段指针地址并进行排序比较。下面是关键片段#include cstdio #include cstdlib #include new #include vector void PrintAddr(const char* tag, void* ptr) { std::printf([%s] %p\n, tag, ptr); } int GlobalVar 42; // 全局区 const char* GlobalStr Hi; // 常量区指针 void StackDump() { int local_a 0; int local_b 1; PrintAddr(栈上局部变量 local_a, local_a); PrintAddr(栈上局部变量 local_b, local_b); } void HeapDump() { int* p1 new int(10); int* p2 new int(20); PrintAddr(堆上对象 p1, p1); PrintAddr(堆上对象 p2, p2); delete p1; delete p2; } void StaticLocalDump() { static int static_local 99; PrintAddr(函数内 static 局部变量, static_local); } int main() { PrintAddr(.data 全局变量 GlobalVar, GlobalVar); PrintAddr(函数内局部变量 main 栈帧标记, GlobalStr); // 注意上面为了示范特意打印了 GlobalStr 本身地址 StackDump(); StaticLocalDump(); HeapDump(); // 对比混用崩溃场景注释掉单独放开看效果 // int* mix (int*)malloc(sizeof(int) * 5); // delete[] mix; // 这个操作很容易崩溃 return 0; }实测下来的地址排序非常清晰代码区/常量区最低全局区其次堆区在中间并随申请次数递增栈区在高地址端并随调用深度递减。这就是我前面说的“相向而行”的实体证据。把这个地址排序记在脑子里对排查指针非法访问有奇效——比如你看到一个野指针指向了栈区就知道它来自一个已经返回的局部变量。4.3 构造与析构调用时机用日志证明 new/delete 与 malloc/free 的不同光看地址还不够有说服力我再做一个关键实验用自定义类型记录构造/析构的调用时机。自定义类型本身不复杂重点是在构造函数和析构函数里打印一行日志。class Tracked { public: explicit Tracked(int id) : id_(id) { std::printf(构造 Tracked(%d) %p\n, id_, this); } ~Tracked() { std::printf(析构 Tracked(%d) %p\n, id_, this); } private: int id_; }; void Step_A() { // new/delete 正确配对 Tracked* t new Tracked(1); delete t; } void Step_B() { // malloc 手动 placement new再手动析构 free void* raw std::malloc(sizeof(Tracked)); Tracked* t new (raw) Tracked(2); t-~Tracked(); std::free(raw); } void Step_C() { // malloc 假装 new然后直接 free无析构 void* raw std::malloc(sizeof(Tracked)); Tracked* t static_castTracked*(raw); // 注意这里没有调用构造函数对象处于“未初始化”状态 std::free(raw); // 隐患如果 Tracked 内部有堆成员此步会泄漏 }运行日志一目了然Step_A 输出构造析构Step_B 输出构造析构但显式调用了析构函数Step_C 什么都不输出如果 Tracked 内部持有堆资源资源直接泄漏。实际上 Step_C 这种“裸奔”对象在真实项目里并不罕见——很多人图省事用 malloc 分配 C 对象然后忘记调用构造函数或者构造函数内部已经申请了堆资源导致整个对象生命周期里资源管理逻辑完全错乱。这个实验还揭示了一个日常非常常见的问题场景自定义结构体内含有 std::string 或 std::vector 等成员时绝对不能用 malloc 来“创建”它。原因在于malloc 不会调用构造函数std::string 内部指向字符缓冲的指针就不会被正确初始化。你以为内存里是一片零值但对 std::string 来说零值可能被当作空指针也可能被当作某段非法地址一旦调用任何成员函数就是崩溃或者未定义行为。具体表现五花八门有的立即段错误有的等到字符串做 append 时才爆炸。这种 bug 极难Location因为出错位置和根源位置常常相距几万行代码。5. 内存管理实战中的七大类疑难突发状况定位思路与解决速查5.1 内存泄漏RSS 直线上升服务越跑越“胖”内存泄漏是所有 C/C 服务端程序最原始也最常见的病痛。症状是进程的 RSS常驻内存持续走高从不回落时间一长就可能被操作系统 OOM Killer 给杀掉或者导致容器频繁重启。泄漏的来源不外乎三个方向new 了不 delete、malloc 了不 free、容器或资源拿取了不归还。定位内存泄漏我推荐几个从易到难的手段。第一步肉眼复查所有动态分配点尤其是错误分支。第二步用编译器自带工具Linux 下 valgrind 是首选valgrind --leak-checkfull ./server一份报告能精确到文件和行号。第三步如果你用的是 glibc 环境可以打开MALLOC_CHECK_环境变量或设置malloc hooks在运行时对非法写进行诊断。第四步深入到自定义分配器层面维护一个全局分配表每次 malloc/new 时记录地址、大小、调用栈释放时移除程序退出时把剩余项打出来。我在工作中还踩过一个隐蔽的坑第三方静态库内部用了static std::map收取数据退出时 map 本身会被析构但 map 里存的裸指针元素没人释放导致退出阶段的大量泄漏。这种情况 valgrind 能出来但信息不够直观所以遇到第三方库的分配/释放建议通过包装层统一拦截分配调用。5.2 悬空指针与重复释放访问了“已经离职的员工”悬空指针是指指向的内存已经被释放但指针变量本身还保留着旧地址。此时再通过这个指针访问数据内存里的值可能已经被改掉也可能触发崩溃结果不确定这让它比空指针更阴险。空指针崩溃至少能快速定位到行悬空指针则是时好时坏偶现崩溃最折磨人。重复释放和悬空指针是一对孪生兄弟释放掉一块内存后没有把指针置空后来又释放一次第二个 delete/free 会直接操作堆管理器的释放路径大概率触发崩溃或者堆元数据损坏这个损坏可能不是立刻崩而是隔了很久才在某个不相关的操作上炸开。预防手段很简单三条铁律第一释放后立即ptr nullptr;标准允许对空指针重复 delete/free虽然不算好习惯但至少不会让堆管理器析构同一块内存两次。第二生命周期管理统一交给智能指针std::unique_ptr和std::shared_ptr能在绝大多数场景下消灭裸指针的悬空问题。第三模块边界不要传递裸指针的“管理权”传出去谁释放、何时释放必须在设计文档里写清楚。5.3 栈溢出函数调用“深不见底”导致的瞬间死亡栈溢出最常见的场景就是递归没有正确终止条件。一个简单的例子二分查找递归版里传错了区间边界导致永远递归不出去每递归一层就是几 KB 到几十 KB几万层下去8MB 栈空间瞬间告罄。崩溃现场通常看不出和递归有关的线索因为栈已经被彻底耗尽异常处理程序自己都没栈可用了。排查和修复方面我的建议是三步走。第一拿到崩溃信息先用gdb查看调用栈bt命令能打印出完整调用链如果发现有可疑的重复函数帧基本就是无终止递归。第二考察是不是单帧栈需求过大把大数组和庞然大物对象从栈上挪到堆上。在函数里不过定义一个 1MB 的局部数组却为了一次简单调用付出了栈溢出的代价非常不划算。第三评估是否启用-fstack-protector-strong和地址消毒器AddressSanitizer它们在开发调试阶段可以精准报告栈溢出位置。5.4 内存踩踏不相关的两块数据互相“串门”有一类现象比内存泄漏更隐蔽你的程序没有泄漏任何内存也没有越界访问但两个不相关的对象互相篡改数据。典型场景是数组越界写比如int a[10]; a[10] 1;——这行代码编译能过警告可能都不出但它在栈上把紧挨着数组末尾的另一块内存给改了。如果那块内存恰好是另一个变量的值你看到的现象就是“莫名其妙变量被改”定位起来极其痛苦。这类问题我强烈建议用 AddressSanitizerASan来抓编译时加-fsanitizeaddress -fno-omit-frame-pointer链接时也加-fsanitizeaddress运行到越界写的位置程序会立刻输出带调用栈的报错。在我的经验里ASan 抓到这种问题几乎百发百中定位速度和准度远高于手动排查。实战中我遇到过一次同事排查了一周的内存篡改问题用 ASan 十分钟就锁定了具体行号记忆非常深刻。5.5 字节对齐问题旧代码在 ARM 上突然翻车字节对齐问题在 x86 平台往往不明显因为 x86 对非对齐访问有较好的硬件容忍度只是速度损失。但在 ARM、RISC-V 等 RISC 架构上部分指令对非对齐访问会直接触发硬件异常程序就崩了。最常见的触发场景是你用#pragma pack(1)定义了一堆紧凑结构体然后把这些结构体的指针强转成别的类型或者直接把 char 缓冲区里的数据 reinterpret_cast 成一个结构体指针。解决思路第一非必要不调用#pragma pack或者只在网络协议解析的局部场景使用第二做类型转换前先确认内存地址确实满足目标类型的对齐要求第三在高性能计算场景中统一使用alignas显式声明对齐。如果确实需要字节流解析建议用memcpy逐字段拷贝到对齐好的局部结构中避免未对齐处的直接解析这种“拷贝成本”远小于对齐错误的排查成本。5.6 跨模块内存释放运行时库不同导致的崩溃疑难杂症Windows 上的 DLL 边界问题是个非常典型的例子。如果一个 DLL 用自己链接的 CRT 分配内存返回给主程序后主程序用另一个 CRT 的 free/delete 去释放堆管理器会判定这块内存不是自己管理的直接崩溃。这就是为什么有很多“接口内封装申请释放函数”的规范谁制造的垃圾谁负责处理。跨模块问题的检测同样困难因为很多时候同样的工具链、同样的配置都没事换一个 DLL 的 Release/Debug 编译模式就崩。原因在于 Debug CRT 和 Release CRT 的堆实现不同Debug 模式下还会填充特殊的边界标记值检测到被破坏时主动报错。工程上的通用做法是所有跨模块传出的动态内存必须经由导出函数内部的配对的 release 函数回收宁可多导出一个DestroyObject接口也不要让调用方直接 delete。5.7 内存碎片分配多了堆变得像一块瑞士奶酪长生命周期服务跑几个礼拜后明明总剩余内存不小却申请一个大一点的缓冲区会失败这就是内存碎片问题。分配器手里有大量碎片但每一块都不够大无法拼出满足请求的连续区域。Linux 下 glibc malloc 有 trim 和 arena 机制但碎片严重时也未必能自救。缓解碎片的主流办法有使用内存池对象池/大小分级池把相同大小的对象统一从池里分配或者使用 jemalloc、tcmalloc 这类更注重碎片控制的高性能分配器。jemalloc 对多线程场景尤其友好在 Redis、MySQL 等知名项目中都有应用。如果你的业务里有大量消息对象往返创建释放强烈建议按消息大小分级设计缓存池碎片问题和性能问题一次全解决。6. new/delete 与 malloc/free 高频使用场景的决策对照很多读者到这一步会问那到底是全用 new/delete 好还是回归 malloc/free 好这没有标准答案取决于你的项目背景。我这里给出一个针对常见场景的对照表方便你快速做技术选型。场景推荐方案原因纯 C 工程或 C 代码模块malloc/freeC 语言没有构造/析构概念new/delete 语义不成立硬用反而要背跨语言桥接的包袱C 工程创建自定义类对象new/delete构造/析构自动触发避免对象资源管理错乱C 工程创建 POD 类型数组无析构需求两者均可但建议统一用 new[]/delete[]虽然 malloc/free 也行但风格一致能降低混用的心理负担需要精确控制内存布局嵌入式、驱动malloc/free 自定义分配器嵌入式环境往往禁用异常且分配器可控性要求高高性能服务端高频小对象分配内存池 配合 tcmalloc/jemalloc裸 malloc/new 的开销在高频下不容忽视甚至可能成为性能瓶颈实现容器、智能指针等库内部机制malloc 的底层封装operator new 内部实际封装了 allocator库内部通常需要精确控制对齐或实现内存池或者需要自定义分配策略从工程习惯角度我给一个保守但绝对不出错的建议除非有明确理由C 项目一律使用 new/delete 和配套的 RAII 工具比如 std::vector、std::string、std::unique_ptr。malloc/free 留给纯 C 代码或者确实需要 C 接口对接的场景。只要把“惯例”统一掉一半以上的内存 bug 能在代码审查阶段直接消灭。7. 最后一次分享几个小技巧内存调试中用过的顺手工具和心得调试内存问题的时候我常用的工具有几个顺手程度很高。Linux 下必推 valgrind虽然它会让程序运行慢 20 到 50 倍但换来的定位精度值回票价Google 的 AddressSanitizer 则是现代编译器生态的首选速度快、告警准确几乎每个 C 项目都该开起来跑一轮测试如果你在排查线程相关的竞态和堆问题helgrind 和 TSANThreadSanitizer也值得花时间熟悉。Windows 下 Visual Studio 自带 CRT 调试堆通过_CrtSetBreakAlloc可以精确打断指定编号的内存分配不用装额外工具就能定位到第一次分配出错的代码位置。再分享一个我个人的土办法在代码里给每个 new 和 malloc 打上标签。比如在分配后立刻把一个哨兵值写入最后一个字节释放前检查这个哨兵是否还在。如果检查的时候发现它被改了说明分配的区域发生了越界写排查范围大幅收敛。这招在无法使用外部工具的老旧嵌入式环境里救过我很多次虽然笨但确实有效。哨兵检查的额外开销可以压在极低水平生产环境带上也完全可承受。最后我在实际项目中碰到的最大体会是内存问题几乎没有一次是“看代码就秒懂”的绝大多数都要靠工具、日志、地址描述来逼近。但只要心里有内存分布的图身边有顺手好用的工具再有排查问题时的耐心再顽固的 bug 也只是时间问题。希望这整套从理论到实战再到工具的拆解能让你以后看内存相关的报错时少一点心慌多一点胸有成竹。