正常
Deep Dive into RAII: The Cornerstone of Resource Management
When I first learned C++, I had zero concept of "resource management"—I would new an object and forget to delete it, open a file and forget to fclose it, lock a mutex and forget to unlock it. As my projects grew larger, these "hand-slip, forgot-to-release" bugs started showing up like cockroaches: spotting one meant ten more were hiding in the corners (and, as things invariably turned out, by the time I spotted one I'd probably also be writing a project postmortem at the same time—sob). Then one day I seriously read Bjarne Stroustrup's book, and finally understood that C++ had an elegant solution prepared for us all along: RAII [1] Bjarne Stroustrup, The C++ Programming Language, 4th ed., ch.13 Exception Handling.
RAII (Resource Acquisition Is Initialization) is C++'s most central idea about resource management, and the foundation of every "automatic cleanup" mechanism in modern C++—smart pointers, lock guards, file handle wrappers, and so on. Once you understand RAII, you are no longer just "using the tools"; you are understanding the design philosophy behind them. In today's article, we will work from mechanism to practice and nail RAII down completely.
What RAII Really Is: A One-Sentence Summary
The core idea of RAII is utterly plain: put resource acquisition in the constructor, and resource release in the destructor. Once an object is created successfully, the resource is in hand; the moment the object leaves its scope (whether by a normal return, an early return, or a thrown exception), the destructor is guaranteed to be called, and the resource is guaranteed to be released.
My first reaction was—huh? That's it? What else would you even do? But once I let it sink in—hey, there's real wisdom here! I used to write drivers, and in C (especially back in my driver days, the mere thought of wrangling four or five gotos makes me chuckle), if dodging bugs rests entirely on programmers remembering "release the resources on every return path", then I don't think I could keep calling myself a human programmer.
Enough chatter—let's look at the plainest possible example, wrapping a file handle with RAII:
Expand codeCollapse44 lines
C++
#include <cstdio>
#include <stdexcept>
class FileHandle {
public:
explicit FileHandle(const char* path, const char* mode)
: file_(std::fopen(path, mode))
{
if (!file_) {
throw std::runtime_error("failed to open file");
}
}
~FileHandle() noexcept {
if (file_) {
std::fclose(file_);
}
}
// Copying is forbidden—a file handle should not be held by two objects at once
FileHandle(const FileHandle&) = delete;
FileHandle& operator=(const FileHandle&) = delete;
// Moving is allowed—ownership can be transferred
FileHandle(FileHandle&& other) noexcept
: file_(other.file_)
{
other.file_ = nullptr;
}
FileHandle& operator=(FileHandle&& other) noexcept {
if (this != &other) {
if (file_) std::fclose(file_);
file_ = other.file_;
other.file_ = nullptr;
}
return *this;
}
std::FILE* get() const noexcept { return file_; }
private:
std::FILE* file_;
};Usage is minimal:
C++
void write_log(const char* msg) {
FileHandle fh("/tmp/app.log", "a");
std::fprintf(fh.get(), "%s\n", msg);
// When the function ends, fh's destructor fcloses automatically
// Normal return, early return, or thrown exception—no leak in any case
}If you come from C, one comparison tells you everything: in C, every branch that can return early needs a manual fclose, and missing a single one leaks a file descriptor. RAII hands this "don't forget" burden over to the compiler—the destructor will be invoked (as long as the program exits through normal control flow, rather than calling std::exit() or std::abort() directly). That is not a convention; it is a guarantee from the C++ language standard [2] cppreference RAII — lifetime-based resource management.
We turned the manual-fclose versus FileHandle comparison into an animation—you can play it, pause it, or single-step it with the step controls, and watch clearly what happens to the resource on the two exit paths, the early return and the thrown exception:
Stack Unwinding: The Engine Behind RAII
The key mechanism that makes RAII work is called stack unwinding. When a program leaves a scope—whether by executing to the end, hitting a return statement, or throwing an exception—the C++ runtime automatically destroys every already-constructed local object in that scope, calling their destructors one after another, from the most recent to the oldest.
This is a language-level guarantee, not some "best practice" or "compiler optimization". Let's feel the power of stack unwinding with a concrete example:
Expand codeCollapse30 lines
C++
#include <iostream>
#include <stdexcept>
struct Tracer {
explicit Tracer(const char* name) : name_(name) {
std::cout << "Tracer(" << name_ << ") 构造\n";
}
~Tracer() noexcept {
std::cout << "~Tracer(" << name_ << ") 析构\n";
}
Tracer(const Tracer&) = delete;
Tracer& operator=(const Tracer&) = delete;
private:
const char* name_;
};
void demo_stack_unwinding() {
Tracer a("a");
Tracer b("b");
throw std::runtime_error("boom!");
Tracer c("c"); // Execution never reaches this point
}
int main() {
try {
demo_stack_unwinding();
} catch (const std::exception& e) {
std::cout << "捕获异常: " << e.what() << "\n";
}
}This demo program is right below—click "Try it yourself" to run it directly:
Compiler Explorer
Hands-On Verification: Destructor Order During Stack Unwinding
Watch stack unwinding online after an exception is thrown. Note the destruction order: b, constructed last, is destroyed first (LIFO), and c, never constructed, never appears in the output.
Watch closely: after the exception is thrown, b and a are still correctly destroyed—and in the order last constructed, first destroyed (LIFO). c was never constructed, so it needs no destruction. That is the whole secret of stack unwinding: no matter how control flow leaves the scope, all fully constructed local objects are destroyed in turn.
We can verify this guarantee with code:
Expand codeCollapse32 lines
C++
// GCC 16.1.1, -O2 -std=c++11
#include <iostream>
#include <stdexcept>
struct Tracer {
const char* name;
explicit Tracer(const char* n) : name(n) {
std::cout << "Tracer(" << name << ") constructed\n";
}
~Tracer() {
std::cout << "~Tracer(" << name << ") destroyed\n";
}
};
void may_throw() {
throw std::runtime_error("Exception thrown");
}
void test_stack_unwinding() {
Tracer t1("t1");
Tracer t2("t2");
may_throw(); // The exception is thrown here
Tracer t3("t3"); // Execution never reaches this point
}
int main() {
try {
test_stack_unwinding();
} catch (const std::exception& e) {
std::cout << "Caught: " << e.what() << "\n";
}
}This verification program is right below—click "Try it yourself" to run it directly:
Compiler Explorer
Hands-On Verification: Stack Unwinding Across Functions
Verify online how unwinding propagates across functions: after may_throw throws, t2 and t1 are destroyed in order, and finally main catches the exception.
Destructors should guarantee that they do not throw. If a destructor throws a new exception while an exception is propagating (during stack unwinding), the program calls std::terminate(). Since C++11, a user-declared destructor is noexcept(true) by default (even without an explicit annotation), so throwing means termination. Therefore a destructor should catch and handle all exceptions inside it, or move operations that might fail out of the destructor and expose an explicit interface for error handling [3] cppreference Exceptions — stack unwinding; std::terminate if a destructor throws during unwinding.
We can verify this behavior:
C++
// GCC 16.1.1, -O2 -std=c++11
#include <iostream>
#include <type_traits>
struct TestDestructor {
~TestDestructor() {
std::cout << "Destructor called\n";
}
};
int main() {
std::cout << "Is destructor noexcept? "
<< std::is_nothrow_destructible<TestDestructor>::value << "\n";
// Output: Is destructor noexcept? 1
}If you try to throw from a destructor (even with an explicit noexcept(false)), doing so during stack unwinding still causes std::terminate() to be called. This is a hard requirement of the C++ standard, and its purpose is to keep the exception-handling machinery itself from crashing.
Edge case: the destructor guarantee only applies to "exit through normal control flow". If the program calls std::exit(), std::abort(), or _exit(), or gets killed by a signal, no stack unwinding takes place, and destructors of local objects are not called. This is one of the reasons you should prefer exceptions over std::exit().
Exception Safety Guarantees: RAII's Practical Value
Exception safety is the standard for judging whether code behaves "correctly" when an exception occurs. The C++ community defines three levels of exception safety guarantee [4] Herb Sutter, Exceptional C++, 1999 — Exception-Safety Issues and Techniques, from weakest to strongest:
Basic guarantee: after an exception, the program remains in a valid state—no resources are leaked, and every object's invariants still hold. The program's concrete state may have changed, though (a container, for example, may have lost some of its elements). RAII alone gets you to this level automatically: as long as all resources are managed by RAII objects, stack unwinding releases them for you.
Strong guarantee: after an exception, the program state rolls back to what it was before the operation—either the operation succeeds completely or it fails completely, with no "half-finished" intermediate state. Implementing the strong guarantee usually requires the copy-and-swap idiom or a transactional rollback mechanism. This guarantee is not something RAII can deliver on its own, but RAII is the foundational tool for building it.
Nothrow guarantee: the operation guarantees that it will not throw. Destructors, deallocation, and certain low-level operations (such as moving an int) belong to this class. This is the strongest guarantee, but not every operation can achieve it.
Let's look at a practical example: suppose we are writing a configuration-update function and want it to reach at least the basic guarantee:
Expand codeCollapse28 lines
C++
#include <vector>
#include <string>
#include <fstream>
#include <mutex>
class ConfigManager {
public:
void update_config(const std::string& key, const std::string& value) {
// std::lock_guard is a classic application of RAII
// Locks on construction, unlocks on destruction—even an exception in between cannot deadlock
std::lock_guard<std::mutex> lock(mutex_);
// std::vector and std::string are both RAII containers
// If push_back throws bad_alloc, lock_guard's destructor still unlocks
entries_.push_back({key, value});
// Writing the file is RAII too: ofstream closes the file automatically on destruction
std::ofstream out(config_path_, std::ios::app);
if (out) {
out << key << "=" << value << "\n";
}
}
private:
std::mutex mutex_;
std::vector<std::pair<std::string, std::string>> entries_;
std::string config_path_ = "/tmp/config.ini";
};In this code, std::lock_guard, std::string, std::vector, and std::ofstream are all RAII-managed resources. No matter which step inside update_config throws, the mutex gets unlocked, the file gets closed, and the string's and vector's memory gets released—that is the basic exception safety guarantee RAII hands you, obtained essentially for free.
The RAII Wrapper Design Pattern
In real-world engineering we often need to write RAII wrappers for all kinds of resources. Although the C++ standard library already provides many (std::unique_ptr, std::shared_ptr, std::lock_guard, std::fstream, and so on), you will always run into scenarios it does not cover. That is when mastering the design recipe of an RAII wrapper becomes really important.
A well-formed RAII wrapper usually follows this design pattern: the constructor acquires the resource (throwing or entering an invalid state if acquisition fails); the destructor releases the resource (and must be noexcept); copying is forbidden (to prevent double release); moving is allowed (to support ownership transfer). Let's look at another example, a network socket:
Expand codeCollapse47 lines
C++
#include <sys/socket.h>
#include <unistd.h>
#include <stdexcept>
#include <utility>
class Socket {
public:
explicit Socket(int domain, int type, int protocol = 0)
: fd_(::socket(domain, type, protocol))
{
if (fd_ < 0) {
throw std::runtime_error("socket creation failed");
}
}
~Socket() noexcept {
if (fd_ >= 0) {
::close(fd_);
}
}
// Copying is forbidden
Socket(const Socket&) = delete;
Socket& operator=(const Socket&) = delete;
// Move constructor
Socket(Socket&& other) noexcept
: fd_(other.fd_)
{
other.fd_ = -1;
}
// Move assignment
Socket& operator=(Socket&& other) noexcept {
if (this != &other) {
if (fd_ >= 0) ::close(fd_);
fd_ = other.fd_;
other.fd_ = -1;
}
return *this;
}
int get() const noexcept { return fd_; }
private:
int fd_;
};You will notice this pattern is almost identical to the earlier FileHandle—acquire, release, forbid copying, allow moving: the "four-piece set" of an RAII wrapper. Once you have this pattern down, wrapping a database connection, an OpenGL texture, an SDL window, or a CUDA stream is all the same routine.
RAII for Mutexes: Why You Should Never Call unlock Manually
Two of the most classic RAII examples in the C++ standard library are std::lock_guard and std::unique_lock. Many beginners feel that "manually locking/unlocking works just fine"—I thought so too, back in the day. Until, in one 200-line function with 5 return paths and 3 exception-throwing points, I spent an entire afternoon tracking down an intermittent deadlock bug—from that day on, I never manually unlocked again.
Expand codeCollapse24 lines
C++
#include <mutex>
#include <iostream>
// Wrong way: managing the lock manually
void bad_increment(std::mutex& m, int& counter) {
m.lock();
if (counter > 100) {
m.unlock(); // Don't forget to unlock before every return
return;
}
counter++;
// What if an exception is thrown here? The lock is never released → deadlock
m.unlock(); // And don't forget this final unlock either
}
// Right way: RAII management
void good_increment(std::mutex& m, int& counter) {
std::lock_guard<std::mutex> lock(m);
if (counter > 100) {
return; // lock_guard's destructor unlocks automatically
}
counter++;
// However we exit, lock_guard will unlock
}How std::lock_guard works is extremely simple—its constructor calls mutex.lock(), and its destructor calls mutex.unlock(). Yet the reliability it brings is enormous. My advice: wherever locking is needed, always use an RAII wrapper (lock_guard, unique_lock, or scoped_lock), and never manage lock state by hand [5] C++ Core Guidelines, Section R: Resource Management.
Embedded in Practice: GPIO Pin Management and SPI Chip-Select Control
The idea of RAII applies just as well to embedded development. In an embedded system, "resources" are no longer file descriptors or mutexes, but hardware resources such as GPIO pins, SPI chip-select lines, DMA channels, and I2C buses. Forgetting to release these resources can have more serious consequences than in desktop programs—peripherals hang, power consumption rises, even the whole system becomes unstable.
First, an example of GPIO pin management. We use RAII to bind the pin's lifetime to the object's lifetime: the constructor initializes the pin, and the destructor restores it to a safe state (usually a high-impedance input mode).
Expand codeCollapse45 lines
C++
// gpio_raii.h
#pragma once
#include <cstdint>
enum class GpioDir { kInput, kOutput };
class GpioPin {
public:
GpioPin(uint8_t pin, GpioDir dir, bool init_level = false) noexcept
: pin_(pin), dir_(dir)
{
// Assume an underlying HAL API
hal_gpio_config(pin_, dir_, /*pull=*/false, init_level);
if (dir_ == GpioDir::kOutput) {
hal_gpio_write(pin_, init_level);
}
}
~GpioPin() noexcept {
if (moved_) return;
// Restore to a safe state: input (high impedance), to prevent leakage from a floating pin
hal_gpio_config(pin_, GpioDir::kInput, false, false);
}
// Copying forbidden, moving allowed
GpioPin(const GpioPin&) = delete;
GpioPin& operator=(const GpioPin&) = delete;
GpioPin(GpioPin&& other) noexcept
: pin_(other.pin_), dir_(other.dir_), moved_(other.moved_)
{
other.moved_ = true;
}
void write(bool v) noexcept {
if (dir_ == GpioDir::kOutput) hal_gpio_write(pin_, v);
}
bool read() const noexcept { return hal_gpio_read(pin_); }
private:
uint8_t pin_;
GpioDir dir_;
bool moved_ = false;
};The usage is just as clean as on the desktop:
C++
void blink_once() {
GpioPin led(13, GpioDir::kOutput, false);
led.write(true);
hal_delay_ms(100);
led.write(false);
// When the function ends, led automatically returns to a safe input state
}Managing an SPI chip-select (CS) line is another classic RAII scenario. During SPI communication, the CS line must be pulled low at the start of each transaction and pulled high at the end. If you forget to pull it high, the slave device stays busy and all subsequent communication goes wrong. Use RAII to bind the CS line's state to the transaction:
Expand codeCollapse25 lines
C++
class SpiTransaction {
public:
SpiTransaction(SpiBus& bus, uint8_t cs_pin) noexcept
: bus_(bus), cs_pin_(cs_pin), active_(true)
{
bus_.begin_transaction();
bus_.set_cs(cs_pin_, false); // CS active low
}
~SpiTransaction() noexcept {
if (!active_) return;
bus_.set_cs(cs_pin_, true); // CS deassert
bus_.end_transaction();
}
// Copying and moving both forbidden
SpiTransaction(const SpiTransaction&) = delete;
SpiTransaction& operator=(const SpiTransaction&) = delete;
SpiTransaction(SpiTransaction&&) = delete;
private:
SpiBus& bus_;
uint8_t cs_pin_;
bool active_;
};When using it, you only need to place the transaction object in scope:
C++
void read_sensor(SpiBus& spi, uint8_t cs) {
SpiTransaction t(spi, cs);
spi.transfer(tx_buf, rx_buf, len);
// Any return, break, or exception releases CS correctly
}Using RAII in embedded scenarios comes with a few special constraints: destructors must not perform blocking operations (otherwise real-time behavior suffers) and must not allocate heap memory (many embedded systems have no heap, or a limited one), and creating RAII objects in an ISR (interrupt service routine) calls for extra caution—ISR stack space is limited, and destructors cannot afford complex work.
Exercise: Designing a General-Purpose ScopeGuard Class
As the closing exercise of this article, let's design a general-purpose ScopeGuard class. Its design goal: wrap any "cleanup action to execute on exit" into a RAII object at minimal cost. This class is extremely useful in real-world engineering—when you have operations that don't fit a dedicated RAII class but still need guaranteed execution on exit, ScopeGuard is the best choice.
Expand codeCollapse41 lines
C++
#include <utility>
#include <exception>
#include <cstdlib>
template <typename F>
class ScopeGuard {
public:
explicit ScopeGuard(F&& func) noexcept
: func_(std::move(func)), active_(true)
{}
ScopeGuard(ScopeGuard&& other) noexcept
: func_(std::move(other.func_)), active_(other.active_)
{
other.active_ = false;
}
~ScopeGuard() noexcept {
if (active_) {
func_();
// If func_() throws, since the destructor is marked noexcept
// the C++ runtime calls std::terminate() automatically
}
}
// Dismiss the guard—sometimes, after success, you don't want the cleanup to run
void dismiss() noexcept { active_ = false; }
// Copying is forbidden
ScopeGuard(const ScopeGuard&) = delete;
ScopeGuard& operator=(const ScopeGuard&) = delete;
private:
F func_;
bool active_;
};
template <typename F>
ScopeGuard<F> make_scope_guard(F&& func) noexcept {
return ScopeGuard<F>(std::forward<F>(func));
}Example usage:
C++
void complex_operation() {
auto guard = make_scope_guard([]{
std::cout << "清理工作执行\n";
cleanup_temp_files();
});
// ... a series of operations that might fail ...
if (error_occurred) {
return; // guard's destructor runs the cleanup
}
// Success—no cleanup needed
guard.dismiss();
}This ScopeGuard implementation is a direct descendant of the classic design Andrei Alexandrescu proposed in the 2000s. In later chapters we will see how the C++ standard standardized this pattern into std::scope_exit / std::scope_fail, and how the Boost.Scope library provides richer functionality.
Probing the Boundary: When Destructors Do Not Get Called
To fully understand where RAII's guarantee ends, we need to be clear about which situations do not invoke the destructor. This helps us make the right decisions when designing systems:
Expand codeCollapse30 lines
C++
// GCC 16.1.1, -O2 -std=c++11
#include <iostream>
#include <cstdlib>
struct Tracer {
const char* name;
explicit Tracer(const char* n) : name(n) {
std::cout << "Tracer(" << name << ") constructed\n";
}
~Tracer() {
std::cout << "~Tracer(" << name << ") destroyed\n";
}
};
void test_normal_return() {
Tracer t("normal");
return; // The destructor gets called
}
void test_exit() {
Tracer t("exit");
std::exit(0); // The destructor does NOT get called!
}
int main() {
std::cout << "Normal case:\n";
test_normal_return();
std::cout << "\nstd::exit() case:\n";
test_exit(); // Constructs Tracer("exit") internally, then std::exit terminates the process directly
}This boundary-verification program is right below—click "Try it yourself" to run it directly:
Compiler Explorer
Hands-On Verification: std::exit() Does Not Trigger Destructors
Verify the std::exit() boundary online: the normal branch shows both construction and destruction, while the exit branch shows only construction—the process terminates directly, and the destructor never gets a chance to run.
After std::exit() there is no ~Tracer(exit) destroyed anywhere—the process terminates directly inside test_exit, and Tracer("exit")'s destructor never gets a chance to run.
This verification tells us: RAII's guarantee applies only to normal control flow (exception handling included). If the program exits abnormally through std::exit(), std::abort(), _exit(), or signal handling, destructors do not execute. This is one more reason modern C++ recommends exceptions over std::exit()—exceptions guarantee stack unwinding and resource cleanup, while std::exit() does not.
In the next article we won't rush into the tools—first we will set up the concept of "ownership": what exclusive, shared, and borrowed each mean, and how a function signature can state its ownership intent plainly. Once that model stands, unique_ptr and shared_ptr stop being two scattered tools and become two implementations of the same idea.
References
1
2
3
4
5