如何用 mmap + HUGETLB 映射大页做共享队列
直接用 mmap 分配大页内存是零拷贝队列的底层前提，但多数人卡在权限、配置和映射方式上。不是所有 mmap 调用都能成功拿到大页——必须显式指定 MAP_HUGETLB，且进程需有 CAP_IPC_LOCK 权限（或以 root 运行），否则会退化为普通页映射，errno 返回 ENOMEM。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先确认系统已预留大页：
cat /proc/meminfo | grep -i huge，确保HugePages_Free> 0 - 映射时必须同时传入
MAP_SHARED | MAP_ANONYMOUS | MAP_HUGETLB；漏掉MAP_SHARED会导致跨进程不可见 - 大小必须是大页粒度的整数倍（如 2MB 或 1GB）；传入 2049KB 会失败，哪怕只超 1 字节
- 不要依赖
sysconf(_SC_PAGESIZE)获取大页尺寸——它返回的是常规页大小；改用gethugepagesize()（glibc 扩展）或查/proc/sys/vm/hugetlb_shm_group
为什么环形队列结构体不能直接 new 或 malloc 在大页内存上
因为 C++ 的 operator new 和 malloc 无法控制分配器后端使用大页，它们只走 glibc 的 brk 或 mmap 常规路径。即使你把整个队列结构体 memcpy 进去，成员指针（比如 char* buffer）仍指向堆内存，不是大页——零拷贝就断了。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 整个队列（含头尾指针、缓冲区、padding）必须一次性映射进大页内存，用
placement new构造对象 - 缓冲区指针（如
data_）必须是相对于映射基址的偏移量（uint8_t*），而非裸指针；否则 fork 后子进程地址空间变化，指针失效 - 避免虚函数、RTTI、异常对象——它们隐式引入运行时数据结构，可能落在非大页区域
std::atomic 在大页共享内存中能直接用吗
可以，但仅限 lock-free 类型，且必须确保对齐。x86-64 上 std::atomic<uint64_t></uint64_t> 是 lock-free 的，但若它被编译器放到未对齐地址（比如偏移 3 字节），某些 CPU 会触发 #GP 异常或静默降级为锁实现——这就破坏了无锁语义和性能预期。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 所有原子变量声明时加
alignas(64)（至少 cache line 对齐），尤其在结构体起始/末尾 - 用
is_lock_free()运行时校验：static_assert(Queue::head_.is_lock_free(), "atomic head not lock-free"); - 别用
std::atomic<:shared_ptr></:shared_ptr>—— 它内部含指针+计数器，跨进程时引用计数无效，且非 lock-free
进程崩溃后大页队列里的数据怎么清理
大页内存不会随进程退出自动释放，munmap 失败或没调用，就会一直占用——HugePages_Free 持续减少，直到系统卡死。这不是“泄漏”，而是内核强制保留：大页不能拆分重用，必须整页回收。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 务必在主进程 exit 前调用
munmap；用atexit()注册清理函数不够可靠（信号终止时可能不执行） - 更稳妥的方式是用
shm_open+MAP_HUGETLB创建命名共享内存，由一个守护进程定期检查/dev/shm/下残留文件并shm_unlink - 生产环境建议加 watchdog：启动时写 pid 到
/var/run/queue.pid，crash 后由 systemd 或 supervisor 触发清理脚本
真正难的不是映射大页，而是让所有参与方（生产者、消费者、监控、重启逻辑）对同一块物理内存的生命周期达成一致——这里没标准库兜底，每个环节都得自己扛。
