博主介绍程序喵大人35 - 资深C/C/Rust/Android/iOS客户端开发10年大厂工作经验嵌入式/人工智能/自动驾驶/音视频/游戏开发入门级选手《C20高级编程》《C23高级编程》等多本书籍著译者更多原创精品文章首发gzh见文末记得订阅专栏以防走丢C基础系列专栏C语言基础系列专栏C大佬养成攻略专栏C训练营个人网站好文推荐【AIAgent项目】从零构建一个代码PRAgent【C入门】内存模型与资源管理 - 01 对象到底住在哪里【C入门】内存模型与资源管理 - 02 名字、地址、指针和引用不是一回事【C入门】内存模型与资源管理 - 03 数组为什么容易把内存边界弄丢【C入门】内存模型与资源管理 - 04 new 和 delete 到底做了几件事【C入门】内存模型与资源管理 - 05 对象生命周期从构造开始到析构结束【C入门】内存模型与资源管理 - 06 拷贝、移动和析构为什么要一起看有一种 bug 的排查过程极其消耗意志力程序在某个完全无法复现的低频条件下偶尔崩溃回溯栈指向的位置每次都不一样内存使用曲线在监控面板上缓步爬升但永远找不到对应的泄漏点测试用例全部通过但生产环境每周总有那么几次不明原因的服务降级。当你花了三天时间排除了并发问题、排除了硬件故障、排除了第三方依赖的降级影响之后最终回到代码里逐函数审讨资源获取和释放的配对关系时会发现问题不在某一个被遗忘的 delete 上——而是项目里有一百多处各自手写的获取-释放对每一对在每一条控制流分支上是否配对正确完全依赖当初写代码的那位同事在那一刻的记忆状态和实践纪律。手工管理资源的问题从来不是程序员忘了——忘了只是最终表现形式。真正的问题是手工管理把两条从根上应该绑定在一起的动作——获取和释放——放在了代码的两个不同位置然后让程序员的记忆和测试覆盖来担保这两个动作之间的控制和顺序永远一致。当函数只有一个出口、没有异常时这种担保几乎没有成本。当函数有三个出口、五个出口、十层调用深度、中间夹杂着四个可能抛异常的 C 库调用时担保的成本从零飙到了不可持续。换个角度看手工管理其实是在要求程序员在每一次写new、malloc、open、lock的时候都在脑中预演一遍当前函数从这一点往后所有可能执行到的路径——包括那些尚未被写出来的、未来重构者将会插入的新路径——然后在每一条路径的终点上各自安放正确的释放语句。这不是一个人脑在工程规模下能够胜任的任务。RAII 要做的事就是把这两条动作重新绑回一个对象里——获取放进构造函数释放放进析构函数——然后让 C 语言规则层面的作用域退出机制而不是分散在代码里各处的手工释放语句来确保每一次获取最终都对应一次释放。为什么多出口是手工管理的天敌在一个结构极简单的函数中——从顶到底一条直线中间没有条件分支末尾有一个释放——资源管理和执行流控制之间的张力几乎不可见。获取在开头释放在末尾中间的使用路径没有分叉任何一个有基本代码阅读能力的人都能在五秒内确认这条释放语句是否总能被执行。但实际生产代码中很少有这种单入口单出口干净线的函数更常见的形态是从获取点往下有若干条件分支——if (!valid) return;——每一个分支都是一个潜在的新出口每一个新出口都需要在离开前释放当前已获取的所有资源。出口的数量直接影响着配对的维护成本三个出口对应着释放逻辑在三个不同位置的各自一份副本五条出口对应着五份。voidProcessRequest(constConfigcfg){Connection*connOpenConnection(cfg.host);if(!conn)return;Buffer*bufAllocateBuffer(conn-max_size());if(!buf){ReleaseConnection(conn);return;}if(!Validate(cfg)){ReleaseBuffer(buf);ReleaseConnection(conn);return;}Execute(conn,buf);ReleaseBuffer(buf);ReleaseConnection(conn);}ReleaseConnection在此出现了三次——在buf被分配之前的出口、在buf被分配之后但在Validate之前的出口、在函数末尾。ReleaseBuffer出现两次——只在buf被分配之后的出口。这不是因为释放逻辑本身有多复杂而是因为手工释放写在了每一个独立的控制流出口上而一个资源被获取之后、函数结束之前的所有出口都必须各自记得释放这个资源。在这种结构下如果有人后来在这个函数中间加了一个新的早退条件——比如if (cfg.timeout_ms 0) return;——他必须精确地判断出这个新出口处在哪两个资源的获取窗口之间然后准确地释放当前已获取的全部资源。类型系统既不知道这个函数里有哪些资源正在被手工管理也不知道释放的顺序是否和获取顺序一致更不知道新加入的出口有没有漏掉某一条释放语句——所有这些一致性完全建立在程序员的头脑中。这种情况在同时管理多个资源的函数中会变得更麻烦。资源之间常常存在依赖顺序——buf的分配需要用到conn提供的最大容量——因此释放顺序也不能是任意的buf必须先于conn被释放。每增加一个资源出口上的释放组合就从简单的N 选 1变成按顺序释放已获取的 M 个资源中的 N 个而出错的可能性随着资源数量的增加而组合增长。更关键的是这个问题在代码审查中几乎是透明的——审查者在看这个函数时不太可能对每一个出口逐个验证释放组合是否完整因为出口上的释放逻辑分散在函数的不同位置没有集中到任何一眼可以覆盖的区域内。手工管理的脆弱性不在写代码的那个时间点上——那时候逻辑还在短期记忆里——而在后来的每一个修改点上当修改者的注意力聚焦在新功能的行为而不是资源配对的一致性时。异常出口把这个脆弱性从容易漏推到了写了也执行不到。如果Execute(conn, buf)内部抛出了一个异常函数末尾的那两行手工释放语句就在被跳过的代码区域内——异常沿调用栈向上传播跳过当前作用域的所有残留语句。你想不出用纯手工管理来解决这个问题的方法在每个可能抛出异常的调用后嵌入try-catch会把原本线性可读的业务逻辑碾碎成层层嵌套的异常处理块而放弃处理意味着接受每次异常都是潜在的一次性的资源泄漏。手工管理在多出口上的困境放到异常路径上就不再是容易出错而是在路径上根本无法执行到释放语句——这是两个不同级别的问题。用析构函数把释放从每个出口变成唯一入口RAII 处理这个问题的方式不是把释放写得更多或更小心——它把释放语句的位置从每一个控制流出口的旁边挪到了析构函数里面然后把析构函数的调用时机交给语言的作用域规则。析构函数不关心当前是通过正常return、提前return还是异常传播离开作用域的——这些控制流差异对它来说不可见它只在作用域退出的那一刻被调用而那一刻一定会到来。classConnectionHandle{public:explicitConnectionHandle(conststd::stringhost):conn_(OpenConnection(host)){}~ConnectionHandle(){if(conn_)ReleaseConnection(conn_);}Connection*get(){returnconn_;}ConnectionHandle(constConnectionHandle)delete;ConnectionHandleoperator(constConnectionHandle)delete;private:Connection*conn_;};classBufferHandle{public:explicitBufferHandle(size_t size):buf_(AllocateBuffer(size)){}~BufferHandle(){if(buf_)ReleaseBuffer(buf_);}Buffer*get(){returnbuf_;}BufferHandle(constBufferHandle)delete;BufferHandleoperator(constBufferHandle)delete;private:Buffer*buf_;};这两个包装类的骨架是完全相同的构造调用获取析构调用释放拷贝被禁掉因为裸资源的所有权不应被隐式复制移动可以按需实现。这个骨架在定义时写一次之后在该类型的任何使用点上都不需要再写释放代码。当你把这两个类型放进实际函数中时释放语句从源代码里完全消失了函数回到了纯粹的业务逻辑形态voidProcessRequest(constConfigcfg){ConnectionHandleconn(cfg.host);if(!conn.get())return;BufferHandlebuf(conn.get()-max_size());if(!buf.get())return;if(!Validate(cfg))return;Execute(conn.get(),buf.get());}这个版本的ProcessRequest有三个出口但源代码里一个Release都没有。不是不需要释放——每次return触发作用域退出的那一刻buf的析构函数被调用然后conn的析构函数被调用释放在这个不可见的瞬间自动完成——而是释放已经不需要被每个出口各自记住。你已经把释放的逻辑写在了BufferHandle和ConnectionHandle的析构函数里各一次之后所有使用这两个类型的函数——不管是三个出口还是三百个出口——都不需要再为释放这两个资源写任何额外代码。资源之间的依赖关系在 RAII 版本中由声明顺序自动维护。conn声明在buf前面所以conn先于buf构造后于buf析构——buf在整个存活期内都可以安全使用conn提供的数据buf析构时conn还活着。这个依赖顺序不需要在当前函数里做任何手工检查——声明顺序本身就把它编码进了代码结构里而 C 的逆序析构规则保证了这个结构在运行时被严格执行。RAII 在一个层次上做到的本质上有三个层次其一释放语句不再堆在每个出口旁边——它只存在于析构函数的一个地方所有出口通过析构函数的统一触发间接抵达。其二依赖顺序由对象声明顺序表达不再需要程序员在每一个出口上手工维护释放的组合和次序。其三析构函数的调用是作用域退出机制的必然副作用不受任何控制流分支的选择影响因此不存在这条路径上没有释放语句的可能性。栈展开RAII 为什么连异常路径都不怕RAII 在异常路径上的安全性不来自析构函数内部写了什么特殊判断——析构函数不知道自己是被正常的return、提前的return、还是异常传播调用的也不需要知道。安全性来自 C 异常处理机制里的一条底层规则——栈展开stack unwinding——当异常被抛出后运行时从throw点沿着调用栈逐层向上搜索匹配的catch子句每离开一层作用域该作用域内所有已完成构造的自动对象都会被逆序析构。栈展开在每一个栈帧上的行为和前一章描述的作用域退出时局部对象逆序析构是完全同构的——唯一的区别在于作用域退出的触发原因从执行流自然到达花括号末尾变成了异常传播强制离开作用域但析构函数的调用方式和调用顺序在两种情况下没有任何区别。当A()调用B()B()中某处抛出异常且当前作用域和所有中间调用层都没有匹配的catch时栈展开会先离开B的最内层作用域——析构B中已构造的局部 RAII 对象——然后离开B的函数体——析构剩余的局部 RAII 对象——然后退出到A——析构A中已构造的 RAII 对象——以此类推直到在某一层栈帧上遇到一个匹配的catch子句。在整个传播路径上不需要任何一层作用域内的任何一行代码显式写try-catch来清理资源——栈展开机制从语言层面确保了这个清理一定会发生。这种保证对工程实践最大的冲击是你可以写一个函数开头打开三个文件、锁住两个互斥量、分配几个动态缓冲作为局部 RAII 对象中间调用任意多个可能抛出异常的第三方库函数末尾一行清理代码都不写——不写try-catch不写 release不做任何手工清理——然后相信当异常在任何嵌套深度被抛出时所有被 RAII 覆盖的资源都会在栈展开的过程中被自动逐层释放完毕就像有一条看不见的线程跟着异常的传播路径在收拣沿途的东西。这意味着你在写业务逻辑中的资源获取代码时不再需要为当前这条执行路径上每一个可能被异常跳过的出口提前在脑子里规划清理顺序——RAII 已经把异常路径上的资源正确释放从需要在每个异常点上游显式编写的事变成了在 RAII 类型定义时一次性编写然后在所有异常路径上自动生效的事。栈展开本身不关心你的资源是哪种内核对象——它只做一件事检查当前栈帧上有哪些已完成构造的自动对象然后逆序调用它们的析构函数。至于析构函数里面是delete、close、unlock还是Destroy对栈展开来说是完全透明的——它只是一条在离开作用域时必然会路过的门。栈展开与 RAII 之间有一条需要精准掌握的边界只有构造已经完成的 RAII 对象才会在栈展开中被析构。如果异常抛出的位置恰好在某个 RAII 对象的构造函数体内部——资源被部分获取但对象整体还没有完成构造——这个对象的析构函数不会被调用因为标准规定析构函数的调用对象必须是已构造完成的完整对象一个被异常中断在构造过程中的半成品不符合析构的前置条件。这就要求 RAII 类型的构造函数在设计上保持全有或全无的原子性成功返回意味着所有内部资源已获取完毕中途抛出异常意味着在构造函数内部应当确保所有已获取的部分资源已经被妥善清理。好在第 5 章详细论证过的已完成子对象的自动逆序析构恰好为此提供了自动化保障——只要每个子对象自身是正确实现的 RAII 类型构造失败时已完成子对象的清理就是自动的不需要手工介入。在 C 社区里有一个经常被说反的因果顺序不是因为 C 有异常处理机制所以需要发明 RAII 来应对异常。事实是反过来的——因为 C 有 RAII异常才能在不要求程序员在每个调用点嵌入层层try-catch释放代码的前提下成为一种可用的语言特性。在纯 C 或仅用malloc/free手工管理资源的代码中异常要么意味着接受每次异常都是潜在的资源泄漏要么意味着在每一个可能抛出异常的调用周围用try-catch包裹并手工释放所有已获取资源——两个选项都是工程灾难。正是 RAII 先提供了析构函数在所有出口上必然执行的保证异常才能在不违背资源安全的前提下被广泛使用。异常安全不是 RAII 的附带收益——RAII 是异常安全的前提条件。资源不只指内存——这句废话在工程中是排第一位的盲区RAII 的讨论里最容易被一句话带过的部分是资源不只指内存还包括文件句柄、锁、socket 等。这句话在绝大多数教材里就占一行——写完立刻转入用new/delete做例子的代码演示。一行的体量远远不足以承载这句话在工程中的实际重量。堆内存泄漏的症状单调且无处可逃——监控面板上的 RSS 曲线持续爬升超过阈值后进程被 OOM killer 干掉排查者拿着 heapprofiler 追到某段代码里一个被遗忘的delete定位路径虽然长但方向是单向的。锁泄漏的症状则完全是另一副面孔——一个互斥量被获取后未释放下一段需要同一把锁的代码会在完全无关的另一条线程上死锁而死锁的现场在调试器里展现为某个线程永远停在pthread_mutex_lock上没有任何回溯线索指向那把锁最初是在哪里被获取的。文件描述符泄漏表现为Too many open files的系统级错误但这个错误爆发的位置往往不是文件打开最频繁的那个模块而是系统里碰巧触发 per-process 硬限制的那条 API 调用——很可能是一个和文件操作毫无关系的 socket 创建。数据库连接泄漏的症状随机性更强——连接池耗尽之后的新请求失败在一个甚至不直接依赖数据库的入口层而真正的泄漏点埋在某个低频触发的异常分支里的一条数据库查询路径上。这些不同资源类型的泄漏在各自环境下的表现形式和排查难度差异大得惊人但它们的共同源头是完全相同的获取和释放之间的对应关系被某条控制流路径破坏而破坏者——无论是提前返回、异常传播还是被重构者无意间绕过——和资源的具体类型无关。RAII 对所有这些资源类型提供的是完全同一套保护机制构造里写获取调用和错误检查析构里写释放调用包装完成之后所有使用这个包装类的代码都自动获得了多出口和异常路径下的安全保障。你用同一个 RAII 骨架包了一个 TCP socket 和一个 CUDA 流句柄在调用方那边这两者的释放行为是完全统一、完全不需要被区别对待的。这种统一性有一种容易被低估的间接收益当你把项目中所有类型的资源都封装进了各自的 RAII 包装类型之后资源管理正确性的代码审查负担就从对每个函数的每条控制流分支逐一检查获取-释放配对降到了对每种 RAII 包装类型在引入时审查一次其构造和析构的逻辑是否完备。前者随着函数数量和控制流复杂度的增长而线性发散后者只在每种新资源类型被引入时产生一次固定的审查成本。项目中引入新资源类型的频率远低于函数中新增控制流出口的频率——在 RAII 体系下成本曲线从发散变成了收敛。RAII 包装类在正确实现之后还有一个不易察觉的安全特性资源获取失败时的自动清理。如果构造函数的初始化列表或函数体中抛出了异常而该 RAII 对象的某些成员已经在异常点之前成功构造那些成员的析构函数会被自动调用——这就是第 5 章详述的已完成子对象逆序析构规则在 RAII 场景下的直接作用。你不需要在 RAII 包装类的构造函数里针对获取到一半失败了怎么办手工写补偿清理逻辑——只要把每一种子资源各自封装成独立的 RAII 成员例如把裸指针升级为unique_ptr把裸文件描述符升级为fstream组合而成的上层 RAII 对象在构造失败时就自动执行了正确的逐层回滚。这也正是为什么第 6 章强调的 Rule of Zero 和 RAII 之间存在共生关系——Rule of Zero 让你不写特殊成员RAII 让你在构造失败时仍能自动清理——而这两个机制共同依赖的底层基础就是 C 的逆序析构和构造失败补偿规则。标准库只是把同一个骨架套在了不同的资源上当你同时在代码里写std::string s(hello)、std::vectorint v(100)、auto p std::make_uniqueWidget()和std::lock_guardstd::mutex lock(mtx)时你不需要——也确实不应该——去逐一回想每种类型各自的释放机制是什么。std::string释放字符缓冲区std::vector释放元素存储区std::unique_ptr对其管理的对象执行deletestd::lock_guard解锁它所持有的互斥量。四个释放在底层操作着四种完全不同的系统资源——堆内存、另一块堆内存、一个对象的独占所有权、操作系统的互斥锁——但在你的代码层面它们共用完全同一条接口约定构造获取析构释放。这条约定不是这四个类型在各自文档的角落里偶然写出的巧合而是 RAII 作为设计模式在标准库的多个子系统上被统一部署的结果。std::fstream管理文件——构造时打开可选析构时关闭——函数从任何一个出口返回时文件被自动关闭你不需要在return之前手工调用close()。std::jthreadC20在构造时创建线程句柄析构时自动join或detach让线程生命周期也一并受 RAII 支配。std::shared_ptr的构造参与了共享所有权的引用计数析构递减计数并在归零时销毁托管对象——比单纯的析构时delete多了一层引用计数的间接逻辑但骨架仍然是 RAII构造获取一次共享所有权析构释放退出共享最后一个退出者执行销毁。标准库以同一个骨架覆盖了从堆内存、字符缓冲、动态数组、互斥锁、文件句柄、线程句柄一直到共享生命周期管理的动态对象的全部基础资源类型。对调用方而言这种全类型一致的安全意味着你可以在同一段代码里组合多种完全不同的 RAII 类型而不需要逐件协调各自的释放时机。函数开头锁住互斥锁std::lock_guard分配一个临时动态数组std::vector从配置文件读入路径std::string——当函数从任何一个出口退出时锁、数组缓冲和路径字符串的堆内存都经由同一套逆序析构被归还释放的顺序由声明顺序决定释放的正确性不需要在这段代码的任何一行进行额外的显式检查。程序设计阶段也不再需要为每一种新引入的资源种类单独设计独立的释放策略——只要该资源被正确封装进一个 RAII 包装的类型里它的释放就自动纳入与所有已有资源完全相同的析构保障体系。标准库 RAII 类型的覆盖范围在 C11 之后持续扩大。第 6 章 Rule of Zero 的讨论中已经从类不需要手写特殊成员函数的角度提过这一趋势从 RAII 本位的角度值得再总结一次C11 以前程序员连一个标准的互斥锁 RAII 包装或独占所有权的智能指针都需要自行手写或从第三方库引入那个时代手工管理资源的比例之所以居高不下不是因为当时的人喜欢手工控制而是因为标准库提供的 RAII 类型覆盖面太窄了窄到连最基础的动态对象所有权和互斥锁保护都需要自己封装。C11 补上了unique_ptr、shared_ptr、lock_guardC14 补上了std::make_uniqueC17 补上了scoped_lockC20 补上了jthread。到了今天一个新写 C 项目中需要用 Rule of Five 亲手管理裸资源的类理应是极少数——它们应该集中在与 C 接口对接的平台特定封装层标准库已经管好了覆盖绝大多数通用场景的基础资源类型。需要清醒认识的一点是标准库的 RAII 覆盖面虽然已经非常广但不可能覆盖每一种操作系统平台、每一种第三方 C 库、每一种硬件驱动包里独有的资源类型。当你遇到一个标准库没有覆盖的资源类型——比如 GNUTLS 的会话句柄、libcurl 的 easy handle、Windows 的 HANDLE、CUDA 的流对象——你只需要给它写一次 RAII 包装一个构造函数封装获取逻辑和错误检查一个析构函数封装释放逻辑然后按照此资源的所有权语义决定拷贝和移动是被禁止还是需要实现。这个包装类就是你项目中连接这个外部资源类型和 C RAII 体系之间的唯一桥梁。写完之后这个资源在剩下的全部使用场景里就和其他标准库 RAII 类型共用同一条安全保障——析构函数在一切出口上必然执行逆序析构自动维护资源依赖顺序栈展开在异常路径上覆盖所有已构造对象。RAII 在这类场景中不是一个理论上的设计模式——它是把外部 C 接口的资源一下子拉进 C 安全体系里的实际入口。RAII 不是技巧之一而是所有资源管理策略的容器第 4 章到第 6 章的结论全部摊开之后RAII 就不再是需要额外记忆的一条独立规则而是那些分散结论的顺畅汇聚。第 4 章把new/delete拆成了分配、构造、析构、释放四个独立动作证明了手工管理要求程序员在代码的不同位置分别调用这四个动作而各动作之间的配对正确性只存在于程序员的记忆里。第 5 章证明了析构函数在一切正常的代码退出路径上——正常return、提前return、异常传播——都会被无条件触发且触发顺序在所有对象层级上严格遵循后构造先析构。第 6 章证明了当类开始手工持有资源时五个特殊成员函数必须在同一张设计图里审视同时也证明了让标准库 RAII 类型承接资源管理——Rule of Zero——是这五个函数在设计层面最经济的决策。把这三条结论拼在一起析构函数覆盖所有出口 → 把释放写在析构里。构造可以完成复杂初始化和资源获取 → 把获取写在构造里。五个特殊成员函数的行为和资源所有权深度耦合 → 不要让类直接裸管资源把资源所有权集中到标准库已经实现好的 RAII 类型里自己的类不写特殊成员函数。RAII 在这条推导链里扮演的不是又多了一个新概念需要背而是对前述全部分散结论的一次系统性重组——把各自独立被证明正确的规则析构的确定性、构造和析构的对称性、逆序析构的层级一致性、Rule of Zero 的经济性装配到了一起得到了一个可以提炼为资源跟着对象走对象析构资源就析构的完整管理框架。在这个框架下再面对第 8 章和第 9 章的智能指针它们就不会再让你觉得是两个需要从零开始学习的新工具——它们只是 RAII 在动态对象所有权上的两个参数化应用。std::unique_ptr就是 RAII 独占所有权 禁止拷贝 允许移动构造时接管裸指针的释放责任析构时销毁所管对象不允许多个unique_ptr共享同一个对象。std::shared_ptr就是 RAII 共享所有权 引用计数 控制块构造时加入对象的所有权组并增加计数析构时退出该组并递减计数在归零的瞬间销毁对象。两者的骨架和std::string、std::vector、std::lock_guard的骨架完全同构——构造获取析构释放——差异只在获取和释放在两种不同所有权模式下的语义一个是独占转移一个是共享计数一个是禁止拷贝允许移动一个是拷贝即增加计数、移动即转移计数。本质是同一个 RAII 原语在不同所有权场景下的不同外沿配置。RAII 被反复讲了这么多年不是因为它属于 C 社群的某种审美偏好。它是 C 的语言规则体系——确定性析构、逆序销毁、栈展开——所提供的唯一一种能把资源释放的正确性从依赖程序员在每一次使用时的正确手工纪律转化为依赖编译器在每一次作用域退出时的机械执行的组织形式。当你把一种资源的获取和释放正确地封装进一个 RAII 类型的构造和析构里之后这个资源在所有使用场景下的释放就由编译器接手了——不需要单元测试覆盖所有出口不需要代码审查逐出口确认释放组合不需要生产监控面板去寻找那条在黑暗中悄悄泄漏的低频路径。责任从人的记忆里移到了语言的机械规则里——这就是 RAII 为 C 资源管理体系提供的根本价值。码字不易欢迎大家点赞关注评论谢谢
语法分析器实战指南)
