PMR

[Hical] 你的协程内存去哪里了？三层 PMR 内存池设计 本专栏文章：拆开 Hical · 第 6 篇 前几篇我们都在聊"怎么做"，这篇聊"内存去哪了"。 HTTP 服务器处理一个请求时，至少有这些内存分配：读缓冲（8KB）、请求头解析、URL decode、body 字符串、JSON 对象、响应序列化缓冲、中间件属性注入。每秒 10 万请求 → 每秒数百万次的 malloc/free。 C++17 的 PMR（多态内存资源）给了我们一个机会——换掉默认的 new/delete，用分层的分配器策略。Hical 把这个机会用到了极致。 1. PMR 的最简入门 如果你没用过 PMR，这里 30 秒快速理解： 1 2 3 4 5 6 7 8 // 传统方式：全局 new/delete（不知道这内存在哪、持续多久） std::string s = "hello"; // malloc → free // PMR 方式：你指定分配器的"上游" char buf[1024]; // 栈上的一块内存 std::pmr::monotonic_buffer_resource pool(buf, sizeof(buf)); std::pmr::string s("hello", &pool); // 分配在栈上的 buf 里！ // pool 析构 → buf 回收 → 不需要 free！ PMR 的核心思想：分离"我要内存"和"从哪拿内存"。 不同的分配器适合不同的场景： ...

Heaptrack：找出 C++ 程序中的无效内存分配 你的火焰图上 malloc/free 占了 8% CPU。你知道分配太频繁了，但——是哪个函数在疯狂 new？每次 new 了多少字节？有没有更好的办法？ 故事：每秒 17000 次 malloc，但只有 41 次是浪费的 对我的 C++20/26 Web 框架（Hical）做 Heaptrack 分析时发现：136K QPS 下每秒 17457 次堆分配，但临时分配（分配后很快释放）只有 41 次/秒——说明 PMR 内存池策略生效了。 但第一版代码没有 PMR 时，临时分配高达 13 万次/秒。Heaptrack 精确告诉了我哪些 std::string 和 std::vector 是罪魁祸首，逐个消灭后内存分配开销从 8% 降到 < 0.1%。 这篇教你用 Heaptrack 做同样的事——精确定位哪个函数在做无效分配，然后干掉它。 一、Heaptrack 是什么 Heaptrack 是一个堆内存分配追踪器，记录程序运行期间的每一次 malloc/new/free/delete，告诉你： 总共分配了多少次？多少字节？ 哪个函数分配最多？（完整调用栈） 峰值内存使用在哪个时间点？ 有没有泄漏（分配了但从未释放）？ 临时分配有多少？（分配后很快释放——这是优化首要目标） 对比 Valgrind Massif Heaptrack Valgrind –tool=massif 性能开销 2~5x 减速 20~50x 减速 数据粒度 每次分配的完整调用栈 定期快照 GUI heaptrack_gui（丰富） ms_print（文本） 适用场景 日常分析（推荐） 极精确内存画像 一句话：Heaptrack 是 Valgrind Massif 的现代替代品，快 10 倍，信息更全。 ...

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 原地重建全局池——先析构旧池，再构造新池： ...

课程导航：学习路径 | Boost.System | Boost.Asio | Boost.Beast | Boost.JSON | Boost.MySQL 前置知识 课程 1: Boost.System（error_code 用于安全解析） C++ 基础：模板、if constexpr、可变参数模板 JSON 数据格式基础 学习目标 完成本课程后，你将能够： 掌握 Boost.JSON 的值类型体系（value/object/array） 安全解析和序列化 JSON 数据 理解 PMR 分配器如何加速 JSON 操作 读懂 Hical 的 MetaJson 反射层——自动 JSON 序列化的实现原理 目录 前置知识 学习目标 目录 1. 核心概念 1.1 Boost.JSON vs 其他 JSON 库 1.2 值类型体系 1.3 构造与访问 2. 基础用法 2.1 创建 JSON 值 2.2 解析 JSON 字符串 2.3 序列化为字符串 2.4 访问和修改 2.5 类型转换 3. 进阶主题 3.1 PMR 分配器集成 3.2 增量解析 3.3 tag_invoke 自定义序列化 3.4 错误处理 4. Hical 实战解读 4.1 HttpRequest::jsonBody() 4.2 HttpResponse::setJsonBody() 4.3 HttpResponse::json() 工厂 4.4 MetaJson.h：反射驱动的自动序列化 4.5 PMR 与 JSON 的协同 5. 练习题 练习 1：JSON 解析与提取 练习 2：HICAL_JSON 宏实战 练习 3：安全 JSON 验证器 练习 4：PMR 性能对比 练习 5（挑战）：扩展 valueToJson 参考答案 练习 1 参考答案：JSON 解析与提取 练习 2 参考答案：HICAL_JSON 宏实战 练习 3 参考答案：安全 JSON 验证器 练习 4 参考答案：PMR 性能对比 练习 5 参考答案：扩展 valueToJson 支持 optional 6. 总结与拓展阅读 C++ 类型 ↔ JSON 类型映射表 API 速查表 拓展阅读 课程回顾 1. 核心概念 1.1 Boost.JSON vs 其他 JSON 库 特性 Boost.JSON nlohmann::json RapidJSON simdjson 接口风格 Boost 风格 STL 风格 SAX/DOM 只读 PMR 支持 原生 无 自定义 Allocator 无 增量解析 stream_parser 无 SAX API 无 编译速度 快（header-only 可选） 慢 快 快 可变性 读写 读写 读写 只读 Boost 集成 天然 独立 独立 独立 Hical 选择 Boost.JSON 的原因： ...

为 C++ Web 框架设计三层 PMR 内存池：从原理到实战 本文以 Hical 框架为例，深入讲解如何利用 C++17 PMR（Polymorphic Memory Resource）为高并发 Web 服务器构建三层内存池架构。 为什么 Web 服务器需要自定义内存管理？ 一个 HTTP 请求的生命周期中，框架需要分配大量临时对象：解析缓冲区、路径字符串、JSON 值、响应体。在高并发场景下（如 50K QPS），new/delete 的全局锁竞争会成为显著瓶颈： 1 2 3 50,000 请求/秒 × 每请求 ~20 次分配 = 1,000,000 次/秒 new/delete ↓ 全局堆锁竞争 → CPU 空转 传统方案是自研内存池，但 C++17 提供了标准化的解决方案 —— PMR。 PMR 速览 PMR 的核心思想：把内存分配策略从容器类型中解耦。 1 2 3 4 5 // 传统方式：分配器绑定在类型中 std::vector<int> vec; // 永远用 std::allocator // PMR 方式：运行时切换分配策略 std::pmr::vector<int> vec(&myPool); // 用自定义内存池 标准库提供了三种现成的内存资源： ...

从零构建现代C++ Web服务器（二）：协程异步与 PMR 内存池 系列导航：第一篇：设计理念 | 第二篇：协程与内存池（本文） | 第三篇：路由、中间件与SSL | 第四篇：实战与性能 | 第五篇：Cookie、Session与文件服务 | 第六篇：数据库中间件 前置知识 了解协程关键字（co_await、co_return、co_yield）的基本含义 理解智能指针和 RAII 模式 了解 std::pmr（Polymorphic Memory Resource）的基本概念 目录 从零构建现代C++ Web服务器（二）：协程异步与 PMR 内存池 前置知识 目录 1. 从回调地狱到 co_await 1.1 传统回调方式 1.2 协程方式 1.3 协程的工作原理（简化） 2. Awaitable：hical 的协程基石 工具函数 3. 协程在框架中的实际应用 3.1 Accept 循环 3.2 HTTP 会话处理 3.3 协程执行全景 4. PMR 内存池：为什么默认 allocator 不够好 4.1 问题分析 4.2 Benchmark 对比 5. 三层内存架构深度剖析 5.1 教学代码：从零实现简化版三层 PMR 5.2 教学代码：三层管理器 5.3 generation 计数器的妙用 6. PmrBuffer：零拷贝缓冲区 6.1 设计思路 6.2 教学代码：简化版 PmrBuffer 6.3 makeSpace 策略图解 7. 协程 + PMR 协同 8. 总结 核心要点 下篇预告 1. 从回调地狱到 co_await 1.1 传统回调方式 假设我们要写一个 TCP Echo Server。传统的异步回调方式是这样的： ...

深入学习 C++17 PMR（Polymorphic Memory Resource） 头文件：<memory_resource> 命名空间：std::pmr 编译器要求：GCC 9+ / Clang 9+ / MSVC 19.13+（均需 -std=c++17 或以上） 一、为什么需要 PMR？ 1.1 传统 Allocator 模型的痛点 C++98 引入的 Allocator 是模板参数，这意味着： 1 2 3 4 std::vector<int, MyAlloc<int>> vec1; std::vector<int, std::allocator<int>> vec2; // vec1 和 vec2 是不同类型！无法互相赋值、放进同一个容器 核心问题： 痛点 说明 类型传染 Allocator 是模板参数，换一个 Allocator 就变了类型，所有接口签名都要跟着改 无法运行时切换 编译期绑定，测试时想换成 debug allocator？重新编译 难以组合 想让 vector 内部的 string 也用同一个 arena？极其繁琐 状态传播困难 有状态 allocator（如持有内存池指针）在容器拷贝/移动时语义复杂 1.2 PMR 的解法：运行时多态 PMR 用一个虚基类 std::pmr::memory_resource 取代模板参数，容器统一使用 std::pmr::polymorphic_allocator<T>： ...