C++ 什么是RAII C++ 资源获取即初始化设计模式详解【理念】

RaiI的本质是构造函数获取资源、析构函数释放资源，要求资源申请必须在构造中完成并确保可用，释放必须且仅在noexcept析构中执行，适用于内存、文件、锁等所有成对资源操作。

RAII 的本质是构造函数获取资源、析构函数释放资源

RAII（Resource Acquisition Is Initialization）不是语法特性，而是一种强制绑定资源生命周期与对象生命周期的设计约定。它的核心判断标准只有一条：资源的申请必须发生在构造函数中，且必须确保一旦构造成功，资源就处于可用状态；资源的释放必须且仅发生在析构函数中，且析构函数不得抛出异常。

常见误用是把“带构造/析构的类”等同于 RAII——比如一个类在构造时打开文件但没检查 fopen 返回值，或析构时调用 fclose 却忽略失败可能，这都不算真正 RAII，因为资源状态不可靠。

• 必须在构造函数内完成资源获取，并做完整错误处理（如抛异常或设置状态位）
• 析构函数必须是 noexcept，且内部释放逻辑不能失败（如 close() 失败应记录而非抛出）
• 禁止裸指针管理资源：像 new 出来的内存若由用户手动 delete，就脱离了 RAII 范畴

std::unique_ptr 和 std::shared_ptr 是 RAII 的标准实现

它们不是“支持 RAII”，而是 RAII 在动态内存管理上的直接落地。关键在于：它们的构造函数接管原始指针（或执行 new），析构函数自动调用 delete 或自定义删除器。

区别在于所有权语义：

立即学习“C++免费学习笔记（深入）”；

• std::unique_ptr：独占所有权，移动后原对象为空，不可拷贝
• std::shared_ptr：共享所有权，引用计数为 0 时才释放资源；注意循环引用会导致资源泄漏
• 自定义删除器必须是 noexcept，否则破坏 RAII 的析构安全性

示例：std::unique_ptr fp(fopen("log.txt", "w"), &fclose); —— 文件句柄被严格绑定到 fp 对象生命周期。

RAII 不止用于内存，也适用于文件、互斥锁、套接字等所有稀缺资源

只要资源需要成对操作（获取/释放、加锁/解锁、绑定/解绑），就适合用 RAII 封装。c++ 标准库已提供多个现成工具：

• std::lock_guard 和 std::unique_lock：封装 mutex.lock()/unlock()，避免忘记解锁或异常跳过
• std::fstream：构造时可打开文件，析构时自动关闭（但注意：不保证刷新缓冲区，显式调用 close() 更稳妥）
• 自定义 RAII 类常需禁用拷贝（= delete），允许移动（如文件句柄、socket fd）

陷阱：某些系统 API（如 linux 的 epoll_ctl）没有天然配对操作，需人工抽象出“资源类型”再封装——比如把 epoll_fd 和注册的 fd 一起打包进一个类，析构时统一 epoll_ctl(EPOLL_CTL_DEL) 并 close()。

RAII 失效的典型场景：异常未被拦截、跨线程转移、返回局部对象引用

RAII 安全的前提是对象生命周期清晰可控。以下情况会绕过析构函数，导致资源泄漏：

• 在构造函数中抛异常：若部分资源已分配但后续步骤失败，需在 catch 块中清理（或使用“两阶段构造”，但违背 RAII 简洁性）
• 用 longjmp 或信号处理函数跳转出作用域：C++ 标准不保证此时析构函数被调用
• 将 RAII 对象的内部裸资源（如 get() 返回的指针）传递给外部并长期持有，而原对象已销毁
• 多线程中将 std::unique_ptr 所有权转移到另一线程，但未同步或使用 std::move，导致双重析构或空悬指针

最易被忽略的一点：RAII 解决的是单次作用域内的确定性释放，它不解决资源竞争、全局初始化顺序、或跨模块生命周期协调问题——这些得靠更高层设计（如服务定位器、依赖注入）补足。