17370845950

RAII是C++管理资源的底层契约，要求资源在构造时获取、析构时无条件释放，依赖栈对象生命周期自动保证，不靠手动调用或try/finally。

RAII 不是语法糖，也不是可选技巧，而是 C++ 管理资源（内存、文件、锁、句柄等）的底层契约。它要求：资源必须在对象构造时获取，在析构时无条件释放——靠栈对象生命周期自动保证，不依赖程序员手动调用 close() 或 delete。

为什么不用 try/finally 或手动 free？

C++ 没有 finally，异常可能在任意位置抛出；手动管理极易漏掉释放点，尤其在多分支或早期返回场景下。RAII 把“获取-释放”绑定到对象生存期，由编译器保证析构执行（除非 std::terminate 被触发）。

常见错误现象：
• 函数中途 return 导致 fclose(fp) 未执行
• 异常传播跳过 delete ptr
• 多线程中忘记 pthread_mutex_unlock()

• RAII 对象必须是栈分配（或智能指针托管），堆上裸 new 的对象无法自动析构
• 析构函数不能抛异常（否则栈展开时二次崩溃），需用 noexcept 显式标注
• 移动语义下，资源所有权应转移而非复制（如 std::unique_ptr 的 move 构造）

典型 RAII 类怎么写？

以封装文件描述符为例，关键在于：构造函数负责 open()，析构函数负责 close()，且禁止拷贝（避免双重关闭）：

class FileDescriptor {
    int fd_;
public:
    explicit FileDescriptor(const char* path) : fd_(open(path, O_RDONLY)) {
        if (fd_ == -1) throw std::runtime_error("open failed");
    }
    ~FileDescriptor() noexcept { 
        if (fd_ != -1) close(fd_); 
    }
    FileDescriptor(const FileDescriptor&) = delete;
    FileDescriptor& operator=(const FileDescriptor&) = delete;
    FileDescriptor(FileDescriptor&& other) noexcept : fd_(other.fd_) { 
        other.fd_ = -1; 
    }
    FileDescriptor& operator=(FileDescriptor&& other) noexcept {
        if (this != &other) {
            if (fd_ != -1) close(fd_);
            fd_ = other.fd_;
            other.fd_ = -1;
        }
        return *this;
    }
};

使用时：FileDescriptor f("/etc/passwd"); —— 出作用域自动关 fd，无需关心 return 或异常路径。

标准库里哪些是 RAII？

几乎所有带“自动管理”语义的类都是 RAII 实现：

• std::vector：构造时分配内存，析构时 delete[]
• std::lock_guard：构造时加锁，析构时解锁（即使临界区 throw 也安全）
• std::unique_ptr：构造时接管裸指针，析构时 delete
• std::fstream：构造时可打开文件，析构时自动 close()

注意：std::shared_ptr 是 RAII，但它的析构只减少引用计数；真正释放资源发生在最后一个引用消失时——这仍是 RAII，只是延迟了释放时机。

容易被忽略的坑

RAII 的可靠性高度依赖正确实现。几个隐蔽陷阱：

• 析构函数里调用虚函数：此时虚表已部分销毁，行为未定义
• 在构造函数中抛异常：对象未完全构造，析构函数不会被调用（但已构造的成员会析

  

  构）
• 把 RAII 对象存进容器后又用 std::move：原对象状态必须置为“无效但可析构”（如 fd 设为 -1）
• 跨 DLL 边界传递 RAII 对象：若两边 STL 版本/ABI 不一致，析构可能崩溃

最常被低估的一点：RAII 解决的是“何时释放”，不是“是否该释放”。如果资源本身不该被自动释放（比如全局 OpenGL 上下文），强行套 RAII 反而引入错误语义。