内存安全值多少钱：一个 Rust 拦下的线上事故

那 47 秒，公司亏了 230 万。 不是策略不行，不是行情判断错了。 是一行代码——一行早该被拦住、却没被拦住的代码。

01 凌晨 2:17，告警群炸了

那天凌晨，海外出了个超预期的宏观数据。全球市场瞬间剧烈波动，行情量在 30 秒内涨了 40 倍。

系统扛住了——至少前 15 秒扛住了。

然后，崩了。

不是 OOM，不是超时，是毫无征兆的进程消失。core dump 里是一堆看不懂的内存乱码，栈信息全断了。

告警群 47 条消息连着弹。等连上 VPN，一切已经结束了。

那 47 秒，我们本该下单的窗口，一分一秒都没了。

按当时的行情和策略信号，错过的交易利润，加上风控强行平仓的损耗——230 万。

02 根因：一个藏了两年的"幽灵"

排查了三天，找到了。

use-after-free。

一个共享的订单簿对象，在行情处理的 hot path 上被释放了，但另一个线程还在读它。平时行情平稳，时序上撞不上；行情暴增后，线程调度一变，正好踩中那个窗口。

这行代码两年前就在了。两年里，跑了几万次回测，上千个交易日，从来没出过事。

一个幽灵，藏在时序的缝隙里，等了两年。

03 为什么没拦住

你可能会问：C++ 不是有一堆工具吗？AddressSanitizer、Valgrind、静态分析……

都有。我们都用了。

• • AddressSanitizer：能检测，但有 2 倍以上性能开销，生产环境不敢全量开
• • Valgrind：慢 20 倍，只能测试环境跑，压测根本跑不动
• • 静态分析：对 use-after-free 这种运行时时序问题，覆盖极其有限
• • Code Review：两年前的代码，谁还记得那个对象的生命周期

每一道防线都有，每一道都漏了。

这不是工程师不负责。是 C/C++ 这门语言，在内存安全这件事上，设计层面就不设防。

你能靠工具，能靠规范，能靠经验——但你拦不住所有时序组合。只要概率不为零，跑得够久，迟早会踩。

C/C++ 的内存安全问题是概率问题。概率问题，时间会给你答案。

04 内存安全到底值多少钱

230 万，是我们这一次的账。

放到全行业，这个数字大得多。

微软安全响应中心（MSRC）公开过一组数据：他们每年修复的漏洞里，约 70% 是内存安全问题。Chrome 团队的数据类似——高危漏洞中约一半与内存安全相关。

再看一次事故的隐性成本，远不止表面数字：

加起来，这次事故的真实代价，逼近 300 万。

一行代码，300 万。

05 Rust 怎么拦的

后来，我们用 Rust 重写了行情处理和撮合的核心模块。

同一个场景——共享的订单簿对象，多线程访问——在 Rust 里根本编译不过。

Rust 的所有权系统定了三条铁律：

1. 1. 每个值只有一个所有者，所有者离开作用域，值自动释放
2. 2. 同一时间，要么多个不可变引用，要么一个可变引用，不能共存
3. 3. 引用的生命周期不能超过被引用者，编译器在编译期检查

那个 use-after-free，在 Rust 里长这样：

use std::sync::Arc;

let orderbook = Arc::new(OrderBook::new());
let reader = orderbook.clone();    // 引用计数 +1

// 想释放？得等所有引用都交出去
// 这行根本编译不过——reader 还持有引用
drop(orderbook);
reader.process(tick);              // 编译器：不，你不能这么做

想释放？行，但得等所有引用都交出去。想同时读写？不行，编译器不让。

这个检查发生在编译期，零运行时开销。

你不需要 AddressSanitizer，不需要 Valgrind，不需要祈祷编译过了，这类问题就不存在了。

C++ 的态度是"你小心点"。Rust 的态度是"我不让你犯错"。

06 更大的图

有人会说：C++ 跑了几十年了，不也好好的？

是好好的。因为每个搞崩过系统的人，都花了真金白银替行业交了学费。

2022 年，美国国家安全局（NSA）在软件安全指南里明确建议用内存安全语言重写关键系统。不是"可以考虑"，是"建议"。

然后你看看整个行业在做什么：

• • Linux 内核：6.1 起接受 Rust 代码，现在 Rust 驱动已经进主线
• • Android：新模块大量用 Rust，Google 公开说 Rust 引入后内存安全漏洞断崖式下降
• • Windows：部分核心驱动在迁移到 Rust
• • AWS：Firecracker 虚拟化、S3 部分组件，Rust 写的
• • Cloudflare：Nginx 的 Rust 替代 Pingora，每天处理万亿级请求

不是赶时髦。是被内存安全问题打疼了，疼够了。

07 当 AI 碰上内存安全

如果你觉得这跟 AI 无关，再想想。

2025 年开始，大量 AI 基础设施在用 Rust 重写——LLM 推理引擎（candle、burn）、向量数据库、RAG 检索后端、Agent 运行时。

为什么？因为 AI 系统的内存访问模式比传统服务更复杂：动态张量、零拷贝共享、多模型并发推理。C++ 在这里踩坑的概率更高，排查更难。

当你的系统在处理真金白银的交易信号，同时跑着大模型推理，内存安全就不是"锦上添花"，是"底线"。

我们的量化系统后来接入了 LLM 做投研分析。整个 AI 推理 pipeline，直接用 Rust 写。不是因为我爱 Rust，是因为我再也不想在凌晨 2 点被电话叫醒了。

08 写在最后

那 47 秒之后，我做了一个决定：能上 Rust 的地方，不再用 C++。

不是说 C++ 不行。是说，当你的系统在处理真金白银的时候，你不应该把"不出事"的希望寄托在人的经验和运气上。

工具应该替你拦住错误，而不是等你犯了再提醒你。

内存安全值多少钱？

对我们，是 230 万。

对你，希望永远不需要知道这个数字。