1. 异常安全：C++资源管理的生死线
第一次在线上服务崩溃日志里看到"Resource leak detected"时，我正端着咖啡的手抖了一下。那个内存泄漏导致的服务雪崩，让我连续72小时没合眼。从那天起，我真正理解了Bjarne Stroustrup说的："C++的异常安全不是可选项，而是生存必需。"
现代C++开发中，异常处理绝非简单的try-catch游戏。当你在构造函数里抛出异常时，析构函数根本不会被调用——这个残酷的事实曾让无数项目付出惨痛代价。更可怕的是，在多线程环境下，不安全的异常处理会导致资源死锁，就像去年某交易所系统宕机事件，根源竟是一个没写好的文件锁异常处理。
2. 异常安全三级标准解析
2.1 基本保证（Basic Guarantee）实战
在重构日志系统时，我遇到过这样的场景：
cpp复制class LogWriter {
FILE* file;
std::mutex mtx;
public:
void write(const std::string& msg) {
std::lock_guard<std::mutex> lock(mtx); // 即使异常发生也会解锁
if (!file) throw std::runtime_error("File not open");
if (fwrite(msg.data(), 1, msg.size(), file) != msg.size()) {
throw std::runtime_error("Write failed");
}
}
};
这里lock_guard确保了互斥锁的释放，但文件状态可能不一致。我曾见过更复杂的版本，在写入失败后自动切换到备用文件，这需要：
- 记录当前写入位置
- 关闭原文件
- 打开备用文件
- 定位到相同偏移
关键技巧：所有可能改变状态的步骤前，先保存当前状态到临时变量
2.2 强保证（Strong Guarantee）实现艺术
强保证要求操作要么完全成功，要么保持原状。参考vector::push_back的实现，我们需要"复制-交换"惯用法：
cpp复制class ConfigManager {
std::map<std::string, std::string> configs;
public:
void update(const std::string& key, const std::string& value) {
auto temp = configs; // 1. 复制
temp[key] = value; // 2. 修改副本
configs.swap(temp); // 3. 原子交换
}
};
在数据库事务系统中，我采用类似的思路：先在内存中完成所有修改，最后通过单个SQL事务提交。
2.3 不抛掷保证（Nothrow Guarantee）的代价
内存分配器是典型的nothrow场景。我们团队曾因为new的异常处理不当导致服务崩溃，后来重写为：
cpp复制void* safe_allocate(size_t size) noexcept {
void* p = malloc(size); // malloc不会抛出异常
if (!p) {
log_error("Allocation failed");
return nullptr;
}
return p;
}
但要注意：noexcept修饰的函数如果抛出异常会直接terminate！去年我们一个核心服务因此宕机3小时。
3. RAII：C++资源管理的基石
3.1 智能指针的陷阱与技巧
unique_ptr看似简单，但我在代码审计时发现过这样的错误：
cpp复制auto getResource() {
auto res = std::make_unique<Resource>();
if (!res->init()) return nullptr; // 错误！返回nullptr导致资源泄漏
return res;
}
正确做法应该是：
cpp复制auto getResource() -> std::unique_ptr<Resource> {
auto res = std::make_unique<Resource>();
if (!res->init()) return res; // 返回已构造对象
return res;
}
shared_ptr的循环引用问题更常见。上周刚帮同事解决一个内存泄漏：
cpp复制class Node {
std::shared_ptr<Node> next;
std::shared_ptr<Node> prev; // 循环引用！
};
改用weak_ptr解决：
cpp复制class Node {
std::shared_ptr<Node> next;
std::weak_ptr<Node> prev; // 打破循环
};
3.2 自定义RAII包装器实战
为处理数据库连接，我设计了这样的RAII类：
cpp复制class DBConnection {
sqlite3* conn;
public:
DBConnection(const char* path) : conn(nullptr) {
if (sqlite3_open(path, &conn) != SQLITE_OK) {
throw std::runtime_error(sqlite3_errmsg(conn));
}
}
~DBConnection() {
if (conn) {
sqlite3_close(conn); // 确保关闭
}
}
// 禁用拷贝
DBConnection(const DBConnection&) = delete;
DBConnection& operator=(const DBConnection&) = delete;
// 允许移动
DBConnection(DBConnection&& other) noexcept : conn(other.conn) {
other.conn = nullptr;
}
};
关键点：
- 构造函数获取资源
- 析构函数释放资源
- 正确处理拷贝和移动语义
4. 异常安全进阶模式
4.1 写时复制（Copy-on-Write）优化
在配置管理系统里，我应用COW技术大幅提升性能：
cpp复制class Config {
struct Data {
std::map<std::string, std::string> params;
std::atomic<int> refcount = 1;
};
Data* data;
void detach() {
if (data->refcount > 1) {
Data* new_data = new Data{data->params};
--data->refcount;
data = new_data;
}
}
public:
void set(const std::string& key, const std::string& value) {
detach(); // 写时复制
data->params[key] = value;
}
};
这种模式在Qt等框架中广泛应用，但要注意线程安全问题。
4.2 事务处理模式
为支付系统设计的事务处理器：
cpp复制class Transaction {
std::vector<std::function<void()>> commits;
std::vector<std::function<void()>> rollbacks;
public:
template<typename Commit, typename Rollback>
void add(Commit&& commit, Rollback&& rollback) {
commits.emplace_back(std::forward<Commit>(commit));
rollbacks.emplace_back(std::forward<Rollback>(rollback));
}
bool execute() {
try {
for (auto& op : commits) op();
return true;
} catch (...) {
for (auto it = rollbacks.rbegin(); it != rollbacks.rend(); ++it) {
try { (*it)(); } catch (...) {} // 确保继续回滚
}
return false;
}
}
};
实际使用时要特别注意回滚操作的异常安全！
5. 异常安全测试方法论
5.1 注入式故障测试
我常使用这种测试模板：
cpp复制template<typename F>
void throw_after(int count, F&& func) {
static int counter = 0;
if (++counter >= count) {
counter = 0;
throw std::runtime_error("Injected fault");
}
func();
}
TEST(ExceptionSafety, VectorPushBack) {
std::vector<int> v;
try {
for (int i = 0; i < 100; ++i) {
throw_after(i, [&]{
v.push_back(i);
});
}
} catch (...) {}
ASSERT_TRUE(v.empty() || v.back() == v.size()-1);
}
5.2 资源泄漏检测技巧
在Linux下，我使用valgrind结合自定义检测：
cpp复制class ResourceTracker {
static std::atomic<int> count;
public:
ResourceTracker() { ++count; }
~ResourceTracker() { --count; }
static void check() {
if (count != 0) {
std::cerr << "Resource leak detected: " << count << "\n";
}
}
};
6. 现代C++中的新武器
6.1 std::optional的错误处理
替代传统的错误码方式：
cpp复制std::optional<Image> loadImage(const std::string& path) {
if (!fileExists(path)) return std::nullopt;
try {
return Image(path);
} catch (...) {
return std::nullopt;
}
}
void process() {
if (auto img = loadImage("test.png")) {
// 使用*img
} else {
// 处理错误
}
}
6.2 std::expected的进阶用法
C++23引入的更强大方案：
cpp复制std::expected<Data, Error> parse(const std::string& input) {
if (input.empty()) return std::unexpected(Error::EmptyInput);
try {
return Data::fromString(input);
} catch (...) {
return std::unexpected(Error::ParseError);
}
}
void process() {
auto result = parse(json);
if (!result) {
log_error(result.error());
return;
}
use(*result);
}
7. 性能与安全的平衡之道
在实时交易系统中，我们发现异常处理带来了约15%的性能开销。通过以下优化策略将开销降至3%以内：
- 将异常处理移出热路径
- 使用错误码处理预期内的错误
- 仅对不可恢复错误使用异常
- 预分配异常对象内存
关键指标对比：
| 策略 | 吞吐量 (ops/sec) | 内存开销 | 代码复杂度 |
|---|---|---|---|
| 纯异常 | 85,000 | 低 | 低 |
| 纯错误码 | 120,000 | 最低 | 高 |
| 混合策略 | 115,000 | 低 | 中 |
最终我们的选择是：核心路径用错误码，模块边界用异常。