深入学习 Boost.Asio(三):协程进阶与实战项目

系列导航:入门篇 | 进阶篇 | 实战篇 前置知识 阅读本篇前,请确保已掌握: 入门篇:io_context、异步操作生命周期、定时器 进阶篇:协程 Echo Server、多线程模型、strand 1. 协程进阶技巧 1.1 co_spawn 的第三个参数 co_spawn 的第三个参数决定了协程完成后的行为: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 #include <boost/asio.hpp> #include <boost/asio/co_spawn.hpp> #include <boost/asio/detached.hpp> #include <boost/asio/use_awaitable.hpp> using boost::asio::awaitable; using boost::asio::use_awaitable; awaitable<int> compute() { co_return 42; } awaitable<void> mayFail() { throw std::runtime_error("oops"); co_return; } void examples(boost::asio::io_context& ioCtx) { // 方式1:detached —— 忽略返回值和异常 // 适用:独立运行的协程(如连接处理) boost::asio::co_spawn(ioCtx, compute(), boost::asio::detached); // 方式2:回调 —— 协程完成时执行回调 // 适用:需要捕获协程异常或获取返回值 boost::asio::co_spawn(ioCtx, mayFail(), [](std::exception_ptr e) { if (e) { try { std::rethrow_exception(e); } catch (const std::exception& ex) { std::cerr << "协程异常: " << ex.what() << "\n"; } } }); // 方式3:use_awaitable —— 在协程中等待另一个协程 // 适用:父子协程关系 // (需要在协程内使用) } // 方式3 完整示例 awaitable<void> parent(boost::asio::io_context& ioCtx) { // 等待子协程完成并获取返回值 int result = co_await boost::asio::co_spawn( ioCtx, compute(), boost::asio::use_awaitable); std::cout << "子协程返回: " << result << "\n"; // 42 } 1.2 超时控制 生产环境中,你不能无限等待一个操作完成。Asio 提供了 awaitable_operators 实现竞争式等待: ...

May 21, 2026 · 10 min · 1926 words

Hical 框架开发心得:七个深刻教训

Hical 框架开发心得:七个深刻教训 引言 Hical 是一个基于 Boost.Asio 的现代 C++20/26 高性能 Web 框架,采用原生 HTTP/WebSocket 网络栈(picohttpparser + 自研 WebSocket),从第一行代码到现在的 45+ 测试文件、3 层内存池、协程化数据库中间件、自研日志系统、OpenAPI 自动生成、WsHub 广播管理器、QPS 从 27K 到 159K 的优化历程,一路走来踩了不少坑,也收获了很多。 这篇文章不讲 API 用法,也不讲架构教程——那些在其他文章里都有。这篇只聊开发过程中的真实体会:哪些决策事后证明是对的,哪些看似优雅的方案差点把自己埋了,以及最终选择背后的取舍逻辑。 目录 Hical 框架开发心得:七个深刻教训 引言 目录 一、C++20 协程是双刃剑 1.1 协程让异步代码变清晰了……吗? 1.2 co_await 后 this 可能已经死了 1.3 io_context 析构时的协程帧:成员声明顺序陷阱 1.4 co_spawn(detached) 的悬空引用陷阱 1.5 异常传播:catch 里不能 co_await 1.6 收获:协程不是银弹 二、PMR 三层内存池——收益大但陷阱多 2.1 为什么要三层 2.2 踩坑:upstream 选错导致跨线程竞争 2.3 踩坑:allocator 忘了传播 2.4 收获:PMR 的收益在高并发场景才显现 三、模板 + Concepts 比虚函数继承更适合网络框架 3.1 GenericConnection 的零成本分流 3.2 NetworkBackend concept:可替换但不多态 3.3 收获:编译期分支 > 运行时分支 四、自研日志系统的价值 4.1 为什么不用 spdlog 4.2 六层架构的设计决策 4.3 两个关键的性能优化 4.4 收获:核心框架值得自研,应用项目直接用 spdlog 五、双轨反射——为未来留后路 5.1 问题:C++26 还没来,但 API 要现在设计 5.2 宏回退层的实现策略 5.3 收获:用宏模拟未来语言特性 六、移除 Boost.Beast——火焰图驱动的依赖清退 6.1 Beast 到底慢在哪 6.2 picohttpparser + 零拷贝请求 6.3 自研 WebSocket 栈的取舍 6.4 收获:数据驱动的依赖决策 七、WsHub 广播管理器——从"能用"到"好用"的 WebSocket 架构 7.1 问题:裸连接管理的困境 7.2 WsHub 的核心设计 7.3 写串行化:被忽视的并发陷阱 7.4 收获:框架应该管理连接生命周期 后记:ThreadSanitizer CI 揪出的隐藏竞态(v2.6) Boost.Asio 对象的跨线程操作 stop() 的并发调用:门卫模式 教训 总结:七条核心原则 一、C++20 协程是双刃剑 1.1 协程让异步代码变清晰了……吗? 在引入协程之前,一个 HTTP 请求的处理链是嵌套回调: ...

May 18, 2026 · 16 min · 3291 words

Hical VS2022 快速上手 Demo

Hical VS2022 快速上手 Demo 一个最小化的 Hical HTTP Server 示例,VS2022 编译即可运行,访问即返回含中文的 JSON 响应。 环境要求 项目 版本要求 Visual Studio 2022 17.6+ (需勾选"C++桌面开发"工作负载) vcpkg 最新版 CMake >= 3.20 (VS2022 自带即可) 第一步:安装依赖 (vcpkg) 1 2 3 4 5 6 7 # 如果还没装 vcpkg git clone https://github.com/microsoft/vcpkg.git C:\vcpkg cd C:\vcpkg .\bootstrap-vcpkg.bat # 安装 Hical 所需依赖(x64-windows 默认 triplet) .\vcpkg install boost-asio boost-system boost-json boost-beast openssl zlib --triplet=x64-windows 第二步:获取 Hical 源码 1 2 git clone https://github.com/user/hical.git cd hical 第三步:CMake 构建 1 2 3 4 5 # 配置(替换为你的 vcpkg 实际路径,-DHICAL_BUILD_TESTS=OFF 跳过测试编译,加快构建速度) cmake -B build -A x64 -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DHICAL_BUILD_TESTS=OFF # 编译 cmake --build build --config Release 编译成功后,可执行文件位于: ...

May 12, 2026 · 4 min · 802 words

火焰图对比分析:自研 HTTP 栈 vs Beast HTTP 栈

火焰图对比分析:自研 HTTP 栈 vs Beast HTTP 栈 Hical v2.6.0 完成了从 Beast HTTP 到自研零拷贝 HTTP 栈的迁移。本文通过两份火焰图的逐项对比,用数据量化"去 Beast"到底省了什么、省了多少,以及当前性能瓶颈到底在哪里。 目录 火焰图对比分析:自研 HTTP 栈 vs Beast HTTP 栈 目录 1. 测试环境与采集方式 2. 总体热度分布对比 flame.svg(自研路径)— 总计 ~299 亿 samples flame1.svg(Beast 路径)— 总计 ~411 亿 samples 3. HTTP 解析:picohttpparser vs Beast parser 4. Header 存储:栈数组 vs 链表堆分配 5. 响应序列化:FixedBuffer vs Beast serializer 自研路径 Beast 路径 6. 发送路径:sendto vs sendmsg 7. 协程与调度开销 8. 内核瓶颈:loopback softirq 的天花板 epoll_ctl 已不是瓶颈 9. strace 佐证:系统调用频率 10. 结论与下一步 量化收益:去 Beast 到底省了多少 当前性能分布总结 下一步优化方向 最终结论 1. 测试环境与采集方式 项目 配置 环境 Ubuntu VM (Docker 内),GCC 14,-O2 -g 压测工具 wrk,4 线程,keep-alive 采集 perf record -F 99 -g -p <pid> → FlameGraph 生成 SVG 辅助 strace -c -f -p <pid> 统计系统调用频率 对比目标 flame.svg(自研路径 v2.6.0)vs flame1.svg(Beast 路径) 两份火焰图采集条件一致,唯一区别是 HTTP 处理栈的实现路径。 ...

May 12, 2026 · 5 min · 918 words

C++ Web 框架性能实测:Hical vs Drogon vs Crow vs Oat++ vs cpp-httplib vs Cinatra(2026)

C++ Web 框架性能实测:Hical vs Drogon vs Crow vs Oat++ vs cpp-httplib vs Cinatra(2026) 上一篇横评我们从架构设计、功能完整度和开发体验角度对比了四个 C++ Web 框架。结论是"各有适合的场景"——但没回答一个关键问题:到底差多少。本文用硬数据补上这个缺口:相同硬件、相同容器、相同压测工具,12 个场景全量对比,包括别人不太敢贴的对自己不利的数据。 目录 1. 引言 2. 测试环境与方法论 3. 基础吞吐量对比 4. 中间件链开销对比 5. 高并发扩展性 6. 资源效率 7. 延迟分析 8. 综合分析与选型建议 9. 结论 10. 复现指南 1. 引言 C++ Web 框架的选型讨论中,最常听到三句话: “Drogon 在 TechEmpower 上排名很高” “Crow 极简,几行代码就能跑” “Oat++ 零依赖,开箱即用” “cpp-httplib 零依赖单头文件,几行就能搭 HTTP 服务” “Cinatra 是国产 C++20 协程框架,性能号称顶尖” 这些都是事实,但缺少在统一条件下的定量对比。框架官网的 benchmark 通常只跑 Hello World,且各自用不同的硬件、不同的压测工具、不同的并发参数——数据之间几乎没有可比性。 本文的定位: 补充 07 号文章 的定性对比,用数据量化各框架的性能差异 与 11 号文章 的跨语言对比形成互补——那篇回答"C++ 和 Go/Rust 差多少",本篇回答"C++ 框架之间差多少" 所有数据可复现——Docker 一键启动,run_bench.sh 跑一遍就能拿到结果 2. 测试环境与方法论 2.1 硬件 & 容器环境 项目 规格 宿主机 Windows 10 Enterprise LTSC 2021,Intel Core i7-11700K @ 3.60GHz(8 核 16 线程),32GB 内存 虚拟机 Oracle VirtualBox 7.1,Ubuntu 24.04.3 LTS Server,8 CPU / 16GB 内存 / 102GB SSD Docker Docker Engine 29.4.3(VM 内原生运行,非 Docker Desktop) 容器资源 每容器限制 4 CPU + 512MB 内存 网络 Docker 内部 bridge 网桥,wrk 独立容器通过服务名访问各框架 网络拓扑说明:所有容器运行在 VirtualBox Linux VM 内的 Docker Engine 上,wrk 与六个框架容器处于同一 Docker bridge 网络,网络条件完全一致。 ...

May 11, 2026 · 9 min · 1868 words

Hical v2.6.0 性能优化心得:从 27K 到 159K QPS 的完整旅程

Hical v2.6.0 性能优化心得:从 27K 到 159K QPS 的完整旅程 这篇文章记录了 Hical 从 v2.5.2 到 v2.6.0 的完整性能优化历程。不是罗列"我做了什么改动",而是分享怎么发现问题、怎么思考方案、怎么验证效果——以及那些"看起来应该有用但实际没用"的弯路。希望对做 C++ 高性能服务器开发的同学有参考价值。 目录 Hical v2.6.0 性能优化心得:从 27K 到 159K QPS 的完整旅程 目录 1. 起点:27K QPS,差距 6 倍 2. 第一个教训:不要猜,要量 3. 找对方向:火焰图告诉你真相 4. 三阶段优化路线 5. 阶段一:调度模型重构(27K → 132K) 5.1 SO_REUSEPORT:消除跨线程调度 5.2 连接级 Timer + atomic 时间戳 5.3 结果 6. 阶段二:去 Beast,自研 HTTP/WS 栈(132K → 140K) 6.1 四个 Phase 6.2 零拷贝请求解析 6.3 结果 7. 阶段三:热路径微优化(140K → 159K) 7.1 修复 readBuf 残留数据丢弃(功能 BUG + 性能) 7.2 scatter-gather I/O 替代单 buffer 合并 7.3 其他微优化(含后续延迟分配优化) 7.4 结果 8. 最终火焰图:确认优化到位 9. 走过的弯路 弯路 1:优化不是瓶颈的代码 弯路 2:FixedBuffer 栈缓冲区太大 弯路 3:过早放弃 10. 总结:性能优化的方法论 原则一:Profiling 驱动,不靠直觉 原则二:按占比排序,从大到小 原则三:每步验证,不要积累 原则四:知道何时停手 最终成绩单 1. 起点:27K QPS,差距 6 倍 v2.5.1 的 Hical 在 Docker 环境(Ubuntu 24.04, GCC 14, 4 线程)下跑 Hello World benchmark,wrk 报出 ~27K QPS。 ...

May 11, 2026 · 6 min · 1235 words

Hical v2.6.0:移除 Boost.Beast,自研 HTTP/WebSocket 栈全记录

Hical v2.6.0:移除 Boost.Beast,自研 HTTP/WebSocket 栈全记录 Hical v2.6.0 完成了一次关键架构升级——彻底移除 Boost.Beast 依赖,HTTP 解析/序列化和 WebSocket 全部替换为自研实现。本文从动机、架构设计、关键技术细节、性能数据四个维度,完整记录这次"去 Beast"的工程实践。 目录 Hical v2.6.0:移除 Boost.Beast,自研 HTTP/WebSocket 栈全记录 目录 1. 为什么移除 Boost.Beast 2. 新架构总览 3. 自研 HTTP 解析栈 3.1 picohttpparser:极致轻量的 C 解析器 3.2 零拷贝 NativeRequest 3.3 HeaderMap:L1 友好的头部容器 4. 自研 HTTP 响应序列化 4.1 栈缓冲 + Scatter-Gather I/O 4.2 状态行预计算 5. 自研 WebSocket 栈(RFC 6455) 5.1 帧解析器:WsFrame 5.2 握手协议:WsHandshake 5.3 Permessage-Deflate 压缩 5.4 消息分片重组 5.5 协议安全校验 6. 编译防火墙与工程化 7. 性能对比数据 火焰图逐项对比 QPS 端到端对比 与同类框架对比 8. 迁移影响与 Breaking Changes 对框架使用者 对框架使用者透明的改动 9. 新增依赖 picohttpparser zlib 10. 总结 1. 为什么移除 Boost.Beast Beast 是一个优秀的 HTTP/WebSocket 库,但在 Hical 的高性能场景中,它成了主要瓶颈: ...

May 11, 2026 · 9 min · 1738 words

Hical 踩坑实录五部曲(五):Boost.MySQL 协程集成的 5 个坑

Hical 踩坑实录五部曲(五):Boost.MySQL 协程集成的 5 个坑 引言 Hical 的数据库模块(src/db/)是一个基于协程的连接池 + 中间件系统,后端使用 Boost.MySQL 的 any_connection。从 “能跑” 到 “能在生产环境跑”,中间踩了不少坑。 这篇文章记录了 Boost.MySQL 协程集成过程中遇到的 5 个真实问题,每个都附带完整的解决方案代码。 目录 Hical 踩坑实录五部曲(五):Boost.MySQL 协程集成的 5 个坑 引言 目录 坑 1:any_connection vs 强类型连接的取舍 坑 2:PreparedStatement 失效与自动重试 坑 3:SET NAMES 注入风险——validateCharset 白名单 坑 4:连接池 acquire 超时的竞争窗口 坑 5:事务忘记 commit/rollback 的自动回滚设计 第一道防线:DbMiddleware 洋葱模型 第二道防线:连接池 release 兜底回滚 附:StmtCache LRU 缓存设计 总结:Boost.MySQL 集成检查清单 坑 1:any_connection vs 强类型连接的取舍 现象:第一版连接池用 Boost.MySQL 的强类型连接(tcp_ssl_connection),结果泛型代码全部被迫模板化——编译时间爆炸,且无法在运行时根据配置切换 TCP/SSL。 强类型方式的问题: 1 2 3 4 5 6 7 8 9 10 11 // ❌ 强类型——泛型代码必须模板化 template <typename Connection> class DbPool { std::vector<std::unique_ptr<Connection>> idle_; // Connection 是 tcp_connection 还是 tcp_ssl_connection? // 中间件也要模板化、查询日志也要模板化... }; // 编译时决定,运行时无法切换 using Pool = DbPool<boost::mysql::tcp_ssl_connection>; 解决方案:any_connection——类型擦除,运行时决定传输层: ...

May 11, 2026 · 8 min · 1605 words

Hical v2.5.2 性能优化实战:SO_REUSEPORT + 连接级 Timer 实现 3 倍 QPS 提升

Hical v2.5.2 性能优化实战:SO_REUSEPORT + 连接级 Timer 实现 3 倍 QPS 提升 在 火焰图分析中,我们定位到 Hical 的 QPS 瓶颈在 Boost.Asio 的 epoll 交互模型——跨线程调度(14.5%)和 timer 相关 epoll_ctl(12.5%)合计吃掉了 27% 的 CPU。[P1 优化](Router 同步快速路径)无实质提升后,本文记录 P2/P3 两项优化的设计思路、实现细节和实测结果。 目录 1. 背景回顾 2. 优化方案 A:SO_REUSEPORT 多 Acceptor 3. 优化方案 B:连接级 Timer + Atomic 时间戳 4. 实测结果 5. 剩余差距与后续方向 6. 复现指南 1. 背景回顾 1.1 P1 优化无效的原因 v2.5.2 实现了 Router::dispatchSync() 同步快速路径,在无中间件场景下跳过协程帧分配。三轮 Docker 压测结果: 轮次 QPS 变化 v2.5.1(基线) 27,493 — v2.5.1(静态链接) 19,381 系统波动 v2.5.2(dispatchSync) 20,940 无实质提升 原因:Router::dispatch 在火焰图中仅占 0.24% CPU,同步快速路径省掉的协程帧(~40-130ns)被 Asio 调度层(27%)完全淹没。 ...

May 10, 2026 · 6 min · 1271 words

Hical 踩坑实录五部曲(四):PMR 三层内存池——从理论完美到实战翻车

Hical 踩坑实录五部曲(四):PMR 三层内存池——从理论完美到实战翻车 引言 Hical 的内存管理采用 C++20 PMR(Polymorphic Memory Resource)三层池架构:全局同步池 → 线程本地无锁池 → 请求级单调缓冲。理论上完美——每一层解决一个特定的性能瓶颈。 但理论和实战之间,隔着一堆坑。 这篇记录了三层 PMR 池在开发和压测过程中遇到的 7 个真实问题——从跨线程 UAF 到 GC 永远不触发、从 CAS 自旋到缓冲区膨胀,每个都是排查半天以上的教训。 目录 Hical 踩坑实录五部曲(四):PMR 三层内存池——从理论完美到实战翻车 引言 目录 坑 1:configure() 原地重建的 use-after-free 坑 2:generation 缓存失效的竞争窗口 坑 3:GC 标记了但永远不回收——死线程的内存泄漏 坑 4:CAS 峰值更新的缓存行风暴 坑 5:请求级单调池的 upstream 选错 坑 6:PmrBuffer 缩容不及时导致内存膨胀 坑 7:allocator 传播链断裂——PMR 白忙一场 总结:PMR 三层池的使用清单 坑 1:configure() 原地重建的 use-after-free 现象:在服务启动流程中调用 MemoryPool::configure() 后,偶发崩溃,堆栈指向 synchronized_pool_resource 的内部结构。 根因:configure() 使用 placement new 原地重建全局池——先析构旧池,再构造新池: ...

May 10, 2026 · 7 min · 1379 words