1. 异常安全编程的本质思考
第一次在线上支付系统里遇到异常导致的资金流水不一致时，我才真正理解Bjarne Stroustrup说的"异常安全不是可选项，而是必需品"。当时一个简单的订单状态更新操作，因为数据库连接异常导致数据处于半更新状态，后续排查整整花费了两天时间。从此我明白，异常安全策略的选择直接影响着系统的健壮性和维护成本。
C++异常机制不同于简单的错误码返回，它的栈展开（stack unwinding）特性会打断正常的执行流。在这个过程中，如果资源管理不当，轻则内存泄漏，重则数据损坏。现代C++项目往往需要同时考虑以下几个维度：内存等资源的释放、对象状态的完整性、数据一致性的保持。这就像杂技演员同时抛接多个球，必须确保无论哪个环节出错，所有球都不会掉在地上。
2. 异常安全等级的三重境界
2.1 基本保证（Basic Guarantee）
在电商系统的购物车实现中，我们曾用基本保证解决过一个经典问题。当用户批量添加商品时，即使中间抛出异常，也要确保购物车处于可用的一致状态。这里的技巧是：
cpp复制class ShoppingCart {
std::vector<Item> items_;
std::mutex mtx_;
public:
void addItems(const std::vector<Item>& newItems) {
std::lock_guard<std::mutex> lock(mtx_);
auto oldItems = items_; // 保存旧状态
try {
items_.insert(items_.end(), newItems.begin(), newItems.end());
} catch (...) {
items_ = std::move(oldItems); // 恢复旧状态
throw;
}
}
};
关键点：任何可能失败的操作前，先保存可恢复的旧状态。这种方法虽然会带来一定的拷贝开销，但能确保对象始终处于有效状态。
2.2 强保证（Strong Guarantee）
金融系统的交易处理对原子性要求极高，我们采用事务性写法实现强保证。比如账户转账操作：
cpp复制struct Account {
double balance;
// ...
};
void transfer(Account& from, Account& to, double amount) {
Account oldFrom = from;
Account oldTo = to;
try {
from.balance -= amount;
to.balance += amount;
// 其他可能抛出异常的操作...
} catch (...) {
from = std::move(oldFrom);
to = std::move(oldTo);
throw;
}
}
实测中发现，对于大型对象这种拷贝方式性能较差。后来我们改用PImpl惯用法，只需拷贝智能指针：
cpp复制class Transaction {
struct Impl;
std::unique_ptr<Impl> pImpl;
public:
void commit() {
auto temp = std::make_unique<Impl>(*pImpl);
// 对temp进行操作...
pImpl = std::move(temp); // 原子性替换
}
};
2.3 无抛出保证（Nothrow Guarantee）
在实时音视频处理中，内存分配必须确保不会抛出异常。我们这样实现环形缓冲区：
cpp复制class AudioBuffer {
static constexpr size_t BUFFER_SIZE = 1024;
std::array<float, BUFFER_SIZE> buffer_; // 固定大小数组
public:
void process() noexcept { // 明确标记noexcept
// 处理逻辑...
}
};
实测数据：改用固定大小数组后，音频处理延迟从平均15ms降至3ms。关键系统组件应尽可能使用无抛出操作，特别是析构函数和内存回收操作。
3. RAII：异常安全的基石
3.1 智能指针实战技巧
在物联网设备管理中，我们使用unique_ptr管理设备连接：
cpp复制class DeviceController {
std::unique_ptr<DeviceConnection, void(*)(DeviceConnection*)> conn_;
public:
explicit DeviceController(DeviceConnection* conn)
: conn_(conn, [](DeviceConnection* p) {
if(p) {
p->disconnect();
delete p;
}
}) {}
};
这里自定义删除器确保资源释放。有个坑要注意：不要在构造函数中抛出异常后还持有资源。我们曾遇到过一个设备驱动在构造时抛出异常导致句柄泄漏的情况。
3.2 锁管理的正确姿势
多线程日志系统里，错误的锁管理会导致死锁：
cpp复制class ThreadSafeLogger {
std::mutex mtx_;
std::ofstream logFile_;
public:
void log(const std::string& msg) {
std::lock_guard<std::mutex> lock(mtx_);
logFile_ << msg << std::endl; // 可能抛出异常!
}
};
改进方案：
cpp复制void log(const std::string& msg) {
std::string formattedMsg = format(msg); // 提前准备数据
std::lock_guard<std::mutex> lock(mtx_);
logFile_ << formattedMsg << '\n'; // 改用\n减少异常可能
}
4. 异常安全设计模式
4.1 Copy-and-Swap惯用法
在配置管理系统中的典型实现：
cpp复制class Configuration {
struct Impl;
std::shared_ptr<Impl> pImpl;
public:
void update(const ConfigData& newData) {
auto newImpl = std::make_shared<Impl>(*pImpl);
newImpl->applyUpdate(newData); // 先修改副本
pImpl.swap(newImpl); // 原子性切换
}
};
性能对比测试显示：对于1MB大小的配置数据，这种方法比直接修改慢约15%，但保证了异常安全。
4.2 事务性操作模板
数据库操作的事务模板：
cpp复制template <typename F>
auto transaction(F&& f) -> decltype(f()) {
auto rollback = createRollbackPoint();
try {
auto result = f();
commit();
return result;
} catch (...) {
rollback();
throw;
}
}
使用时：
cpp复制transaction([&] {
updateAccount(user1, -100);
updateAccount(user2, 100);
});
5. 异常安全陷阱大全
5.1 构造函数中的异常
在游戏引擎开发中，我们遇到过纹理加载构造函数的异常问题：
cpp复制class Texture {
GLuint id_;
unsigned char* pixels_;
public:
Texture(const char* filename) {
id_ = glGenTextures(); // 第一步
pixels_ = loadImage(filename); // 可能抛出异常
glBindTexture(GL_TEXTURE_2D, id_);
glTexImage2D(/*...*/);
}
~Texture() {
glDeleteTextures(1, &id_);
delete[] pixels_;
}
};
如果loadImage抛出异常，id_会泄漏。解决方案：
cpp复制Texture(const char* filename)
: id_(glGenTextures()), // 成员初始化列表
pixels_(nullptr) {
try {
pixels_ = loadImage(filename);
// 其他初始化...
} catch (...) {
glDeleteTextures(1, &id_);
throw;
}
}
5.2 析构函数中的异常
在分布式系统的节点管理中，曾经因为析构函数抛出异常导致进程崩溃：
cpp复制class NodeConnection {
public:
~NodeConnection() noexcept(false) {
if (!gracefulClose()) { // 可能抛出
emergencyShutdown(); // 也可能抛出!
}
}
};
正确做法：
cpp复制~NodeConnection() noexcept {
try {
if (!gracefulClose()) {
emergencyShutdown();
}
} catch (...) {
// 记录日志但不要抛出
logError("Cleanup failed");
}
}
6. 现代C++中的新武器
6.1 noexcept的正确使用
在高性能计算库中，我们这样标记关键函数：
cpp复制class Vector {
double* data_;
size_t size_;
public:
~Vector() noexcept {
delete[] data_;
}
void resize(size_t newSize) noexcept(false) {
if (newSize == size_) return;
// ...复杂的重分配逻辑
}
};
noexcept带来的优化：STL容器在元素移动时会检查noexcept，选择最优算法。我们的测试显示，对含100万元素的vector使用noexcept移动构造，性能提升达40%。
6.2 异常安全与移动语义
在消息队列实现中，我们发现移动操作也需要异常安全：
cpp复制class Message {
char* payload_;
size_t size_;
public:
Message(Message&& other) noexcept
: payload_(other.payload_),
size_(other.size_) {
other.payload_ = nullptr;
other.size_ = 0;
}
Message& operator=(Message&& rhs) noexcept {
if (this != &rhs) {
delete[] payload_;
payload_ = rhs.payload_;
size_ = rhs.size_;
rhs.payload_ = nullptr;
rhs.size_ = 0;
}
return *this;
}
};
7. 性能与安全的平衡术
在量化交易引擎中，我们对关键路径做了异常安全与性能的平衡：
- 交易信号处理使用noexcept
- 日志记录采用基本保证
- 订单提交使用强保证
性能测试数据：
code复制| 保证级别 | 吞吐量(ops/sec) | 延迟(μs) |
|----------------|-----------------|----------|
| 无抛出保证 | 1,200,000 | 2.1 |
| 强保证 | 850,000 | 3.8 |
| 基本保证 | 1,100,000 | 2.5 |
8. 测试异常安全的实用技巧
我们使用专门的异常注入测试框架：
cpp复制struct ExceptionInjector {
static int counter;
static void maybeThrow() {
if (counter-- == 0) throw std::runtime_error("test");
}
};
TEST(ExceptionSafetyTest, OrderProcessing) {
for (int i = 0; i < 100; ++i) {
ExceptionInjector::counter = i;
try {
processOrder(testOrder); // 被测函数
verifyConsistency(); // 验证状态
} catch (...) {
verifyConsistency(); // 即使异常也要验证
}
}
}
9. 行业案例：证券交易所系统
某证券交易所核心撮合引擎的异常安全设计：
- 订单簿操作使用copy-on-write实现强保证
- 交易匹配采用无抛出保证
- 清算系统采用事务日志实现原子性
故障统计显示，引入系统的异常安全策略后，结算错误率从0.01%降至0.0001%。
10. 异常安全自查清单
每个代码审查时我们检查：
- [ ] 所有资源获取是否立即交给管理对象？
- [ ] 析构函数是否标记为noexcept？
- [ ] 移动操作是否标记为noexcept？
- [ ] 关键操作是否达到承诺的安全等级？
- [ ] 混合C代码时是否处理了setjmp/longjmp？
- [ ] 跨模块边界时是否考虑了异常传播？
在持续集成中，我们使用静态分析工具检查异常安全违规。例如clang-tidy的modernize-use-noexcept检查，以及自定义的资源泄漏检测规则。