背景 C++ 协程常见 bug 之一是对象在挂起后已经销毁，但恢复时仍被访问。 典型风险 捕获局部引用并跨 suspend 使用 返回协程句柄后调用方提前释放上下文 Task<void> foo() { std::string buf = "hello"; co_await suspend_point(); use(buf); // 若生命周期判断错，这里会出问题 } 总结 协程代码要像异步状态机一样审生命周期，别按同步函数直觉来读。 控制流变了，生命周期审计方式也必须跟着变。
背景 很多 allocator 优化在 micro benchmark 里很好看，上线却收益一般。原因是评测维度不完整。 建议指标 p50/p95/p99 分配耗时 长时间运行碎片率 多线程争用下吞吐波动 auto begin = std::chrono::steady_clock::now(); void* p = alloc.allocate(256); alloc.deallocate(p, 256); auto end = std::chrono::steady_clock::now(); 总结 评测方法比结果数值更重要，先保证实验可信，再比较方案优劣。 性能数据要能解释真实场景，才有决策价值。
背景 Rust 接入存量 C++ 代码是很多团队都会走的一步。 难点通常不在 extern "C"，而在这些边界问题： 谁创建谁释放 错误如何跨边界传递 线程模型是否一致 基本原则 FFI 边界尽量窄 数据结构扁平、可序列化 所有权规则在接口文档里写死 #[no_mangle] pub extern "C" fn sum(a: i32, b: i32) -> i32 { a + b } extern "C" int32_t sum(int32_t a, int32_t b); 总结 FFI 能带来渐进迁移收益，但边界规范必须比普通模块更严格。 跨语言最怕“默认约定”，最好全部显式化。 边界是系统最脆弱的地方，跨语言边界更是。
为什么“打开 O3”还不够 大型 C++ 服务的热点跨模块分散，单文件优化难以奏效。LTO 能打通跨 TU 优化，PGO 能把优化预算聚焦在真实热路径。 推荐流程 基线版本：记录 p50/p99、CPU、指令数、缓存 miss。 LTO 版本：先验证链接时间与二进制体积变化。 PGO 训练：必须使用“接近线上”的请求分布。 组合验证：LTO + PGO 与基线做 A/B。 CMake 关键配置示例 # LTO set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON) # PGO 两阶段 # 1) -fprofile-generate # 2) -fprofile-use -fprofile-correction 最常见的误区 用单一压测脚本训练 PGO，导致优化偏科。 只看吞吐，不看长尾延迟和抖动。 忽略符号变化对排障工具链（perf、addr2line）的影响。 回归防线 增加“训练集漂移”检测：训练流量和线上流量偏差超阈值就拒绝发布。 将“优化收益”拆解到函数级，防止偶然抖动误判。 为 PGO 单独维护回退开关和构建产物。 小结 LTO/PGO 是生产力工具，不是玄学加速按钮。只有接入真实流量画像和回归防线，优化收益才可持续。
背景 不是所有性能优化都要上自研内存池。很多时候，std::pmr 已经能解决不少问题。 一个实用场景 请求处理阶段会构建很多临时字符串和容器，生命周期一致，适合放在同一块内存资源里。 #include <memory_resource> #include <string> #include <vector> void handleRequest() { std::byte buffer[4096]; std::pmr::monotonic_buffer_resource pool(buffer, sizeof(buffer)); std::pmr::vector<std::pmr::string> fields{&pool}; fields.emplace_back("user", &pool); fields.emplace_back("email", &pool); } 总结 pmr 的价值在于“低侵入地控制分配策略”。 在临时对象密集场景里，收益通常比预想更明显。 能用标准库解决的问题，优先别把复杂度推到自研。
背景 高并发网络服务里，Reactor 和 Proactor 是两个绕不开的模型。 很多争论其实都在混淆一个问题： 你是在等“就绪事件” 还是在等“异步操作完成事件” 核心差异 Reactor 内核告诉你哪个 fd 就绪 业务线程自己 read/write Proactor 业务先发起异步 IO 内核完成后通知你结果 在 Linux 常规栈里，很多框架本质上还是 Reactor；在 io_uring 这类能力更强的接口下，Proactor 风格更容易落地。 简化示意 // Reactor 风格：事件到达后主动读 void onReadable(int fd) { char buf[4096]; ssize_t n = ::read(fd, buf, sizeof(buf)); if (n > 0) { handleRequest(buf, n); } } // Proactor 风格：提交后等待完成回调 void submitRead(Connection* c) { io_uring_prep_read(c->sqe, c->fd, c->buf, c->cap, 0); } void onReadComplete(Connection* c, int res) { if (res > 0) { handleRequest(c->buf, res); } } 选择建议 现有生态以 epoll 为主：优先 Reactor 追求极致吞吐且能接受复杂度：考虑 Proactor/io_uring 团队经验不足时，别为“更先进”盲目迁移 总结 模型没有绝对优劣，只有场景匹配。 ...
为什么协程不是魔法 C++20 协程让异步代码写起来像同步，但它只解决语法组织，不自动提供高性能调度。 真正决定上限的是： 任务队列策略 IO 事件分发 唤醒与线程绑定方式 一个简化示意 task<int> fetch_and_parse(socket& s) { auto buf = co_await async_read(s); co_return parse(buf); } 这段很优雅，但背后必须有 executor 驱动 co_await 的挂起与恢复。 调度层常见坑 所有任务丢进一个全局队列，热点锁竞争严重 IO 线程和计算线程混跑，尾延迟放大 协程对象生命周期管理混乱 实践建议 IO 与 CPU 密集任务分池 减少跨线程恢复，尽量本地唤醒 在高频路径避免动态分配 结语 协程把异步写法变自然，但高性能系统仍然遵循老规律：调度、内存、锁竞争。语法升级不能替代架构设计。
先问一个问题 同样是 O(n)，为什么有的循环快很多？ 答案常常不在算法复杂度，而在 CPU cache 命中率。现代 CPU 的瓶颈常常是内存访问，不是算术指令。 AoS 与 SoA 常见结构： struct Particle { float x, y, z; float vx, vy, vz; int alive; }; std::vector<Particle> particles; 如果你只更新位置，实际上每次还会把速度和状态也加载进缓存。更好的方式是 SoA： struct Particles { std::vector<float> x, y, z; std::vector<float> vx, vy, vz; std::vector<int> alive; }; 这样 CPU 读取的数据更“纯”，预取更有效。 减少伪共享 多线程里，两个线程写不同变量也可能互相拖慢，因为它们落在同一 cache line。 struct alignas(64) Counter { std::atomic<uint64_t> value; }; 用对齐把热点写入隔离开，通常能明显降低抖动。 少做指针追逐 链表、树这类结构在理论上优雅，但在缓存层面很吃亏。工程上更常见的折中是： 用连续数组表示节点池 索引代替裸指针 批量遍历而不是随机跳转 实践建议 先用 profiler 看 cache miss，再改代码 热路径优先考虑连续内存 把“数据怎么放”当成接口设计的一部分 小结 性能优化不是玄学。对于 C++，缓存友好的数据布局往往比微观语法技巧更值回票价。
场景 很多团队不是从零重写，而是把热点模块逐步迁到 Rust。最现实的路径是： C++ 主程序继续跑 Rust 提供一个动态库 双方通过 C ABI 通信 核心原则很简单：跨语言只传 C 兼容类型。 先定义稳定接口 #[repr(C)] pub struct CalcResult { pub code: i32, pub value: i64, } #[no_mangle] pub extern "C" fn calc_sum(a: i64, b: i64) -> CalcResult { CalcResult { code: 0, value: a + b } } #[repr(C)] 保证结构体布局可预测 extern "C" 保证调用约定一致 #[no_mangle] 让符号名可被 C++ 链接 字符串内存谁分配谁释放 跨边界最容易出问题的是字符串： Rust 分配、C++ 释放，或者反过来 不同分配器混用导致崩溃 推荐做法：统一由一侧分配和释放，并显式提供 free 函数。 错误处理不要 panic 穿透 FFI 层应该“防炸”： #[no_mangle] pub extern "C" fn safe_div(a: i64, b: i64, out: *mut i64) -> i32 { if out.is_null() { return -2; } if b == 0 { return -1; } unsafe { *out = a / b; } 0 } 返回错误码是最朴素、也最稳的方式。 ...
背景 写 C++ 服务或者引擎代码时，经常会碰到一种情况：CPU 看着不高，但延迟就是压不下去。 最后一 profile，热点不在算法，也不在锁，而是在 operator new 和 operator delete。 这类问题在下面几种场景里尤其常见： 网络服务里大量创建短生命周期请求对象 游戏引擎里频繁分配小型组件 消息队列消费者持续构造临时 buffer 如果对象大小固定，或者分布相对集中，内存池通常是很直接的一刀。 为什么默认分配器会成为瓶颈 通用分配器要解决的问题很多： 不同尺寸的内存申请 跨线程竞争 碎片整理 对齐要求 这些能力都很重要，但它们也意味着额外开销。 如果你的场景很单一，比如“每次都申请一个 256 字节的请求对象”，那继续走通用分配器其实是在为用不到的能力买单。 一个简单的固定块内存池 先看一个足够说明问题的版本。 #include <cstddef> #include <new> #include <vector> class MemoryPool { public: MemoryPool(std::size_t blockSize, std::size_t blockCount) : block_size_(blockSize) { data_.resize(blockSize * blockCount); for (std::size_t i = 0; i < blockCount; ++i) { void* ptr = data_.data() + i * blockSize; free_list_.push_back(ptr); } } void* allocate() { if (free_list_.empty()) { throw std::bad_alloc(); } void* ptr = free_list_.back(); free_list_.pop_back(); return ptr; } void deallocate(void* ptr) { free_list_.push_back(ptr); } private: std::size_t block_size_; std::vector<char> data_; std::vector<void*> free_list_; }; 思路很直接： ...