日志分析中不能直接 new std::string，因日均5000万行、每行200字节会导致数千万次malloc，引发小内存碎片和锁竞争，实测CPU占用超40%；应预分配大块连续char*内存，用LogLine结构（ptr+len）零拷贝切片，配合生命周期管理避免悬空指针。
为什么日志分析中不能直接 new 一堆 string？
因为每条日志平均 200 字节、日均 5000 万行时，std::string 的堆分配会触发数千万次 malloc，伴随大量小内存碎片和锁竞争。实测某日志解析器在 32 核机器上，new std::string 占用 CPU 时间超 40%，远高于正则匹配本身。
指针本身不解决预分配——关键是用指针指向**预先申请的大块连续内存**，再手动管理偏移与生命周期。
- 别用
std::vector<:string></:string>存指针：这仍要为每个string单独分配元数据和缓冲区 - 真正有效的是：申请一块
char*大内存（如 2GB），用指针在其中“划格子”存原始日志字节 - 所有日志行必须以
\0结尾，否则strlen/printf会越界
如何用 char* + offset 实现零拷贝日志行切片？
假设你已用 mmap 或 operator new[] 分配好大块内存 char* arena，接下来不是复制字符串，而是记录每行起始地址和长度：
struct LogLine {
const char* ptr; // 指向 arena 中某处
size_t len;
};
std::vector<LogLine> lines; // 只存指针+长度，不存内容
解析时逐行扫描原始日志流，遇到 \n 就算一行结束，计算 ptr = arena + offset，len = current - offset，然后 offset = current + 1。全程无 memcpy，lines 容器只增长 16 字节/行（x64 下）。
立即学习“C++免费学习笔记（深入）”；
- 注意：
arena必须生命周期长于lines，否则指针悬空 - 若需修改某行内容（如脱敏），直接写
arena对应位置即可，但得确保不越界——建议在 arena 末尾预留 1% 空间作 guard page - 避免用
std::string_view替代LogLine：它没所有权语义，传参易误传临时 arena
释放时为什么不能 delete[] arena 直接了事？
因为 arena 里可能混着不同生命周期的数据：一部分是原始日志（可立即释放），另一部分是解析后提取的字段（如 IP 地址子串），它们只是 arena 中的子区间指针。直接 delete[] arena 会让所有子指针失效，但下游模块可能还在用。
- 正确做法：把
arena封装成LogArena类，内部用引用计数或 epoch-based reclamation 管理子切片生命周期 - 简单场景可用双阶段释放：先清空
lines，再调用arena->release()，由 arena 内部检查是否还有活跃切片 - 调试时加断言：
assert(ptr >= arena && ptr + len <= arena + capacity)，防止指针漂移
std::pmr::polymorphic_allocator 能替代手写 arena 吗？
可以，但容易踩坑。默认 std::pmr::monotonic_buffer_resource 是单向增长、不可回收的，适合“解析一次、读多次”的场景；但若日志分批加载（如滚动文件），它无法复用已释放的内存块，最终仍会不断扩容。
- 用前必须显式绑定到容器：
std::pmr::vector<LogLine> lines{&resource}，否则容器仍走全局堆 -
std::pmr::string不推荐：它仍为每个字符串单独分配缓冲区，只是分配器换了——没解决核心的小块分配问题 - 真正省心的组合是：
std::pmr::vector<char>做 arena + 手动 offset 切片，比纯pmr方案少 20% 内存占用
预分配不是银弹：当单条日志长度差异极大（从 10B 到 1MB），固定 arena 容易浪费或溢出，这时得切分成多级 arena（按长度桶分组），但那是另一个复杂度了。
