C++

深入学习 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>： ...

系列导航：入门篇 | 进阶篇 | 实战篇 前置知识 已阅读入门篇和进阶篇，掌握 io_uring 双环形缓冲区和 liburing API 了解 C++20 协程基础（co_await、coroutine_handle、promise_type） 建议先阅读 深入学习 Boost.Asio（三）：实战篇 中的协程部分作为对照 1. RAII 封装：安全管理 io_uring 资源 1.1 为什么需要 C++ 封装 直接使用 liburing 的 C API 有三个痛点： io_uring_queue_init / io_uring_queue_exit 手动配对，容易遗漏 user_data 是 void* 或 uint64_t，类型安全全靠人肉 提交→收割的事件循环代码高度模板化，每个项目重写一遍 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 封装层次： 应用代码（协程/回调） │ ▼ ┌──────────────────────┐ │ IoUringAwaitable │ ← 协程集成层（co_await 一个 I/O 操作） └──────────────────────┘ │ ▼ ┌──────────────────────┐ │ IoUringContext │ ← 事件循环层（submit / wait / dispatch） └──────────────────────┘ │ ▼ ┌──────────────────────┐ │ IoUring (RAII) │ ← 资源管理层（init / exit） └──────────────────────┘ │ ▼ liburing C API 1.2 IoUring：RAII 包装 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 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 // IoUring.hpp — RAII 封装 io_uring 实例 // 编译：g++ -std=c++20 -O2 xxx.cpp -luring -o xxx #pragma once #include <liburing.h> #include <stdexcept> #include <string> #include <cstring> class IoUring { public: // 构造时初始化 io_uring，指定 SQ 大小和可选标志 explicit IoUring(unsigned entries, unsigned flags = 0) { int ret = io_uring_queue_init(entries, &ring_, flags); if (ret < 0) { throw std::runtime_error( "io_uring_queue_init 失败: " + std::string(strerror(-ret))); } } // 禁止拷贝（io_uring 资源不可共享） IoUring(const IoUring&) = delete; IoUring& operator=(const IoUring&) = delete; // 允许移动 IoUring(IoUring&& other) noexcept : ring_(other.ring_) { other.moved_ = true; } // 析构时自动清理 ~IoUring() { if (!moved_) { io_uring_queue_exit(&ring_); } } // 获取 SQE（SQ 满时自动 submit 腾出空间） io_uring_sqe* getSqe() { io_uring_sqe* sqe = io_uring_get_sqe(&ring_); if (!sqe) { // SQ 满了，先提交当前积压的请求 io_uring_submit(&ring_); sqe = io_uring_get_sqe(&ring_); if (!sqe) { throw std::runtime_error("SQ 空间不足，即使 submit 后仍无法获取 SQE"); } } return sqe; } int submit() { return io_uring_submit(&ring_); } // 阻塞等待至少一个 CQE io_uring_cqe* waitCqe() { io_uring_cqe* cqe = nullptr; int ret = io_uring_wait_cqe(&ring_, &cqe); if (ret < 0) { throw std::runtime_error( "io_uring_wait_cqe 失败: " + std::string(strerror(-ret))); } return cqe; } // 非阻塞查看 CQE io_uring_cqe* peekCqe() { io_uring_cqe* cqe = nullptr; int ret = io_uring_peek_cqe(&ring_, &cqe); if (ret == -EAGAIN) return nullptr; // 无就绪 CQE if (ret < 0) { throw std::runtime_error( "io_uring_peek_cqe 失败: " + std::string(strerror(-ret))); } return cqe; } // 标记 CQE 已消费 void seenCqe(io_uring_cqe* cqe) { io_uring_cqe_seen(&ring_, cqe); } // 访问底层 io_uring（高级用法需要） io_uring* raw() { return &ring_; } private: io_uring ring_{}; bool moved_ = false; }; 设计原则：RAII 保证 io_uring_queue_exit 一定被调用，即使异常传播也不会泄漏内核资源。getSqe() 中自动 submit 是防御性编程——避免 SQ 满导致的隐性 bug。 ...

系列导航：入门篇 | 进阶篇 | 实战篇 前置知识 已阅读入门篇，理解 SQ/CQ 双环形缓冲区和 liburing 基本 API 熟悉 TCP socket 编程基础（socket、bind、listen、accept） 1. SQPOLL：零系统调用提交 1.1 常规模式的瓶颈 入门篇中每次 io_uring_submit() 底层都会调用 io_uring_enter() 系统调用： 1 2 3 4 5 6 7 8 9 10 常规模式： 用户态 内核态 │ │ │ SQE 写入共享内存 │ │ │ │ io_uring_enter(to_submit=N) │ ├────────系统调用──────────────→│ ← 仍有上下文切换 │ │ 读取 SQ，执行 I/O │ 返回 │ │←─────────────────────────────┤ 对于超高频提交场景（如高频交易、高吞吐数据库），连这一次系统调用都嫌多。 ...

系列导航：入门篇 | 进阶篇 | 实战篇 引言：epoll 之后，还能更快吗？ 假设你用 epoll 写了一个高并发 TCP 服务器，性能已经不错——C10K 问题解决了。但当你把连接数推到 C1M（百万级） 时： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 epoll 的瓶颈： 用户态 内核态 │ │ │ epoll_wait() │ ├───────系统调用─────────────→│ ← 每次至少一次上下文切换 │ │ │ 返回就绪的 fd 列表 │ │←───────────────────────────┤ │ │ │ recv(fd_1, buf, ...) │ ├───────系统调用─────────────→│ ← 每个 fd 又一次系统调用！ │ │ │ send(fd_1, resp, ...) │ ├───────系统调用─────────────→│ ← 再一次！ │ │ │ recv(fd_2, buf, ...) │ ├───────系统调用─────────────→│ ← N 个连接 = 2N+ 次系统调用 问题：epoll 只解决了"哪些 fd 就绪"的问题，每次 I/O 操作仍然需要独立的系统调用。百万连接下，系统调用的开销成为主要瓶颈——上下文切换、数据拷贝、内核锁竞争。 ...

深入学习 std::flat_map 头文件：<flat_map> 命名空间：std 编译器要求：C++23 起（GCC 15+ / Clang 18+ / MSVC 19.38+） 一、设计动机：std::map 的性能痛点 1.1 红黑树的缓存问题 std::map 底层是红黑树——每个节点独立分配在堆上： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 std::map 内存布局（红黑树）： ┌──────┐ │ Node │ ← 堆上随机位置 │ k=5 │ └──┬───┘ ┌───┴───┐ ┌────▼──┐ ┌─▼─────┐ │ Node │ │ Node │ ← 另一个堆上随机位置 │ k=3 │ │ k=8 │ └───────┘ └────────┘ 每次查找跳转 O(log n) 个节点，每个节点可能在不同的缓存行 → 大量 cache miss → 对于只读查找密集的场景，性能远不如连续内存 1.2 flat_map 的解法：排序 vector 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 std::flat_map 内存布局（两个排序 vector）： Keys vector（连续内存）： ┌───┬───┬───┬───┬───┬───┬───┐ │ 1 │ 3 │ 5 │ 7 │ 9 │ 12│ 15│ ← 有序排列 └───┴───┴───┴───┴───┴───┴───┘ Values vector（连续内存）： ┌───┬───┬───┬───┬───┬───┬───┐ │ A │ B │ C │ D │ E │ F │ G │ ← 与 keys 一一对应 └───┴───┴───┴───┴───┴───┴───┘ 查找 key=7： 二分查找 keys vector → 命中索引 3 → 返回 values[3] = D 二分查找在连续内存上进行 → CPU 预取高效 → 极少 cache miss 1.3 性能对比 操作 std::map std::flat_map 原因 查找 O(log n)，多次 cache miss O(log n)，极少 cache miss 连续内存二分 vs 树节点跳转 有序遍历 O(n)，频繁指针追逐 O(n)，顺序内存访问 vector 遍历 vs 树 in-order 遍历 插入/删除 O(log n) O(n)（需移动元素） vector 中间插入需后移所有元素 内存占用 每节点 ≥ 32 bytes 开销 几乎零开销 无节点指针/颜色位 迭代器稳定性 插入/删除不影响其他 全部失效 vector reallocation 一句话总结：flat_map 用插入性能换取查找和遍历性能——适合"少写多读"的场景。 ...

现代 CMake 课程学习：从「面向目录」到「面向目标」 现代 CMake 不是新语法，是新思维。 写在前面 这篇文章适合谁？ 用过 CMake 但只会 add_executable + target_link_libraries 的人 从 Makefile / Visual Studio 工程迁移过来，想系统学 CMake 的人 看别人 CMakeLists.txt 里一堆 PUBLIC、$<BUILD_INTERFACE:...> 一头雾水的人 什么是 CMake？（30 秒版本） CMake 不是编译器，它是一个构建系统生成器。你写一份 CMakeLists.txt，CMake 帮你生成对应平台的构建文件： Linux → Makefile 或 Ninja Windows → Visual Studio .sln 或 Ninja macOS → Xcode 或 Ninja 类比：CMake 就像一个"翻译官"，你用一种语言描述"我要编译什么"，它翻译成各平台编译器能理解的指令。 为什么要学"现代" CMake？ CMake 从 2000 年诞生至今，经历了巨大变化。2014 年的 CMake 3.0 是分水岭——引入了 target-based（面向目标）设计。此后的版本持续完善这套体系。 如果你还在用 include_directories()、link_libraries() 这套"传统写法"，那你用的是 2014 年之前的思路——就像 2025 年还在写 C++98 一样。 ...

系列导航：入门篇 | 进阶篇 | 实战篇 前置知识 阅读本篇前，请确保已掌握： 入门篇：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 实现竞争式等待： ...

系列导航：入门篇 | 进阶篇 | 实战篇 前置知识 阅读本篇前，请确保已理解 入门篇 中的以下概念： io_context 的作用和 run() 执行流程 异步操作的生命周期（发起 → 完成 → handler 执行） post/dispatch 的区别 1. TCP 编程：三步演进 我们通过构建一个 Echo Server（收到什么就回什么），从最简单的同步版本逐步演进到生产级协程版本。 1.1 第一步：同步阻塞版 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 43 44 45 46 47 48 49 // echo_server_sync.cpp // 编译: g++ -std=c++20 echo_server_sync.cpp -lboost_system -lpthread -o echo // 测试: 另开终端 nc localhost 9999，输入文字会回显 #include <boost/asio.hpp> #include <iostream> using boost::asio::ip::tcp; int main() { boost::asio::io_context ioCtx; // 创建 acceptor：监听 TCP 连接 // 参数：io_context, 绑定地址(IPv4, 端口9999) tcp::acceptor acceptor(ioCtx, tcp::endpoint(tcp::v4(), 9999)); std::cout << "同步 Echo Server 监听端口 9999\n"; while (true) { // accept() 阻塞，直到有客户端连接 tcp::socket socket(ioCtx); acceptor.accept(socket); std::cout << "客户端连接: " << socket.remote_endpoint().address().to_string() << ":" << socket.remote_endpoint().port() << "\n"; // 处理这个连接（阻塞：处理期间无法接受新连接！） boost::system::error_code ec; char buf[1024]; while (true) { // read_some：读取可用的数据（可能只有一部分） size_t n = socket.read_some(boost::asio::buffer(buf), ec); if (ec == boost::asio::error::eof) { std::cout << "客户端断开\n"; break; } if (ec) throw boost::system::system_error(ec); // 将收到的数据原样写回 boost::asio::write(socket, boost::asio::buffer(buf, n)); } } return 0; } 问题：同一时刻只能服务一个客户端。当客户端 A 连接后，客户端 B 必须等 A 断开才能被接受。 ...

系列导航：入门篇 | 进阶篇 | 实战篇 引言：为什么需要异步 I/O？ 假设你在写一个聊天服务器，同时连接 1000 个用户。如果用传统的"一个线程处理一个连接"模型： 1 2 3 4 线程1: read(socket_1) ← 阻塞等待用户1输入... 线程2: read(socket_2) ← 阻塞等待用户2输入... ... 线程1000: read(socket_1000) ← 阻塞等待用户1000输入... 问题：1000 个线程各自阻塞在 read() 上，每个线程占用 ~1MB 栈内存（合计 ~1GB），还有大量的上下文切换开销。这就是经典的 C10K 问题。 异步 I/O 的解决思路：用 1 个线程（或少量线程）管理所有连接，操作系统在数据就绪时通知我们： 1 2 3 4 5 6 单线程事件循环: ┌→ 等待事件（epoll/IOCP） │ ├─ socket_7 可读 → 处理用户7的消息 │ ├─ socket_42 可读 → 处理用户42的消息 │ └─ socket_100 可写 → 继续发送给用户100 └─ 回到等待 Boost.Asio 就是 C++ 中实现这一模型的工业级库。本篇将带你理解它的底层原理和核心组件。 ...

trantor 网络库学习总结 学习周期：一个多月 覆盖范围：trantor 全部核心模块，共 18 课 一、整体架构鸟瞰 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 ┌─────────────────────────────────────────────────────────┐ │ 用户代码 / Drogon 框架 │ ├─────────────────────────────────────────────────────────┤ │ TcpServer / TcpClient │ │ • 连接管理（connSet_） • Round-Robin 分配 │ │ • TimingWheel 超时 • promise/future 优雅停止 │ ├────────────────┬────────────────────────────────────────┤ │ TcpConnection │ TaskQueue（Serial / Concurrent） │ │ • 状态机 │ • 卸载阻塞操作 │ │ • 发送队列 │ • SerialTaskQueue = EventLoopThread │ │ • TLS透明层 │ • ConcurrentTaskQueue = 线程池 │ ├────────────────┴────────────────────────────────────────┤ │ EventLoopThread / EventLoopThreadPool │ │ • 3阶段 promise/future 启动协议 │ │ • atomic round-robin 无锁分配 │ ├──────────┬──────────────┬──────────────────────────────┤ │ Acceptor │ Connector │ Resolver（DNS 异步解析） │ │ idleFd_ │ EINPROGRESS │ • NormalResolver（线程池） │ │ EMFILE │ 指数退避 │ • AresResolver（c-ares） │ ├──────────┴──────────────┴──────────────────────────────┤ │ EventLoop（Reactor 核心） │ │ loop() ← Channel ← Poller（epoll/kqueue/IOCP） │ │ runInLoop / queueInLoop / runAfter / runEvery │ │ MpscQueue<Func>：无锁任务投递 │ ├──────────────────────────┬──────────────────────────────┤ │ 定时器系统 │ 工具层 │ │ TimerQueue（最小堆） │ MsgBuffer / Logger │ │ TimingWheel（O(1) 超时） │ ObjectPool / MpscQueue │ │ timerfd / wakeupFd 驱动 │ Hash / secureRandomBytes │ └──────────────────────────┴──────────────────────────────┘ ↓ OS：epoll / kqueue / IOCP / wepoll 二、18 课核心知识点速查 阶段一：基础工具层（第 1-4 课） 第 1 课 — 日志系统 LOG_INFO << "msg" 展开为 Logger(__FILE__, __LINE__).stream()，析构时刷出 FixedBuffer<N>：栈上固定缓冲，避免日志路径的堆分配 AsyncFileLogger：前台线程写入内存队列，后台线程批量刷盘（异步、不阻塞 I/O） 自定义输出：Logger::setOutputFunction()，可对接 ELK、syslog 等 第 2 课 — 消息缓冲区 MsgBuffer 双指针设计：_readIndex / _writeIndex，中间是可读数据，右侧是可写空间 prepend 区域（8字节）：预留报头空间，避免插入时移动数据 readFd()：readv + 栈上 65536 字节备用缓冲，单次 syscall 读取大量数据 BufferNode 4种子类：MemBufferNode、FileBufferNodeUnix、FileBufferNodeWin、AsyncStreamBufferNode 第 3 课 — 日期时间与工具函数 Date：微秒精度时间点（int64_t microSecondsSinceEpoch_），可作定时器 key Date::now() → gettimeofday / GetSystemTimeAsFileTime NonCopyable：= delete 拷贝构造和赋值，所有核心类的基类 第 4 课 — 回调类型定义 ConnectionCallback：连接建立/断开 RecvMessageCallback：收到数据（TcpConnectionPtr + MsgBuffer*） WriteCompleteCallback：发送缓冲区清空 TimerCallback：定时器触发 阶段二：Reactor 核心（第 5-8 课） 第 5 课 — EventLoop 核心循环：epoll_wait → 分发 Channel 事件 → 执行 pendingFunctors_ wakeupFd_（eventfd/pipe）：跨线程唤醒阻塞的 epoll_wait runInLoop(f)：当前线程直接执行；其他线程 → queueInLoop → 唤醒 → 下轮执行 MpscQueue<Func> funcs_：任务队列用无锁 MPSC 队列，多线程投递无锁 关键不变量：EventLoop 是单线程的，所有网络操作必须在其线程执行。 ...