C++26 std::hive：破解频繁删除与缓存友好的两难困局

大概是从第三年写游戏服务端的时候开始，我被一段“每隔几帧就要从容器里删掉一批死亡实体”的代码折磨到换了好几种容器。最初用std::vector，每erase一个元素，后面所有元素都要往前搬；换成std::list，删除是O(1)了，但遍历时节点散落在堆上，缓存命中率肉眼可见地崩；有人建议用std::map做实体管理，性能更离谱。

后来我慢慢意识到，这不是我代码写得差，而是通用容器在“删除频繁、有序约束不强、又希望缓存友好”这个组合里，一直没有给出让人舒服的答案。直到 C++26 的新容器std::hive进入讨论视野，我才觉得这个痛点终于有人正面回应了。

如果只用一个判断来概括std::hive，我会这样说：它真正解决的，不是“某个容器比另一个容器快一点”的问题，而是把“删除时不搬动其他元素”和“存储尽量连续、遍历尽量缓存友好”这两个原本互相冲突的要求，在不需要维护顺序的场景里同时给了你。它不是要取代vector，也不是要取代list，它填补的是一条很具体、但在游戏引擎、事件系统、活跃对象管理里非常常见的需求缝隙。

1. 先搞清楚 std::hive 到底在回应什么痛点

只有当你亲手写过一段被erase支配的循环，你才会理解std::hive的每一个设计决策都是为了躲开哪个坑。

1.1 vector 删除为什么慢：移动不是免费的

很多人对std::vector::erase的性能认知，停留在“复杂度是 O(n)”这一句话上。但实际代码里的感受远比复杂度更直接：如果你在遍历一个 10 万元素的vector，每删一个中间元素，后续几万个元素的移动构造函数就会被触发一次。如果元素还是std::string、业务对象或者带锁的资源句柄，那一次删除的成本可能被放大到不可接受。

更隐蔽的问题是：即使你用了erase+remove_if这样的惯用法，把单次删除的复杂度摊成 O(n)，也仍然解决不了“删完之后，剩余元素的地址全变了”这个语义问题。你没有办法长期保存一个指向vector内部元素的指针，因为下一次删除或插入可能就把它搬到别处去了。

1.2 list、map 为什么治标不治本

std::list把删除成本降到了 O(1)，代价是每个元素独立分配一个节点。节点在堆上的分布完全不可控，遍历时每访问一个新元素都可能是一次 cache miss。元素数量到几十万以上时，遍历list的时间常常会让设计者怀疑人生。

std::map的情况更糟。它不仅节点独立分配，还多了红黑树的父子指针和颜色字段。如果你只是为了“删除时不搬动其他元素”而引入一棵树，那等于用极高的结构性开销换取一个你并不需要的排序能力。

这些容器都在同一个矛盾里打转：想保持元素内存连续，删除就必须搬动；想删除不搬动，内存就很难连续。

1.3 从 plf::colony 到 std::hive：一个被社区打磨多年的提案

std::hive并不是一夜之间出现在 C++26 草案里的。它的前身是 Matt Bentley 开源的plf::colony库，这个库在游戏开发和性能敏感型项目里已经被使用了很多年，相关提案编号是 P0447，后来委员会把它改名为hive，目标纳入 C++26。

我提到这段历史，是因为它决定了你该怎么看待这个容器：它不是委员会拍脑袋设计的新玩具，而是经过了大量真实场景验证、反复调整接口之后才走进标准流程的成熟设计。这同时也意味着，围绕它的讨论里已经沉淀了不少经验：哪些 API 是稳定的、哪些场景收益最大、哪些场景不该用它。

2. 它凭什么快：hive 的核心机制

不看底层机制，你很难理解为什么一个删除不搬动元素的容器，遍历还能保持不错的缓存表现。std::hive的秘密藏在它的存储结构里。

2.1 块状存储：连续性和随机性的平衡

std::hive内部不是一块连续的数组，也不是每个元素一个独立节点，而是分成多个固定大小的块。每个块内部是一段连续内存，块与块之间通过指针连接。

这个结构带来的直接结果有三个：

• 元素在块内紧密排列，遍历一个块时缓存表现接近数组。
• 删除元素后不需要把其他元素往前搬，元素地址保持稳定。
• 插入新元素时优先复用块里的空位，只有整个块都满了才需要申请新块。

你可以把它想象成一组停车场：一排一排的车位，单排内部空间连续；车走了，车位空着，但整体布局不变。新车来的时候，系统会先找空车位停进去，而不是把后面一排车都挪一下。

2.2 空槽与跳跃字段：删除和遍历的关键

如果删除只是把元素析构，然后留下一个洞，那遍历时会遇到大量空槽。std::hive的做法是在块内维护一组跳过标记，用来记录哪些槽位是空的。迭代器遍历时会直接跳过这些空槽，只经过仍然有效的元素。

这也是它名字里 “hive” 的感觉来源：很多小格子，有的住着成员，有的空着，遍历时像在蜂窝里穿梭，遇到空巢就跳过去。

这套机制决定了std::hive的无序特性：你不能期望遍历顺序等于插入顺序，也不能期望删除后的元素地址被后续新元素立刻复用。它能保证的是：删除一个元素后，其他元素的指针和引用仍然可靠。

2.3 引用稳定性：快之外的另一个隐藏收益

很多人只看性能，忽略了std::hive在语义层面的价值：它很可能规定，erase不会使其他元素的迭代器和引用失效。这在实体系统里非常重要。

在实体管理场景中，一个实体经常持有另一个实体的指针。用vector时，这种指针很容易因扩容或删除而悬空；用list时，指针稳定了，但缓存代价太高。hive允许你在不使用图结构的情况下，天然获得“删除一个元素不影响其他元素地址”的能力，这让很多代码可以写得更直接。

2.4 为什么它不能替代 vector 和 map

说了这么多优势，也必须立刻补上边界：std::hive没有operator[]，没有随机访问，不维护任何排序关系。你没法对hive直接做二分查找，也没法保证遍历顺序有业务意义。需要排序和随机访问时，vector很难被替代；需要按键查找时，unordered_map和map仍然是正确选择。

所以，hive的“快”只适用于它自己的能力范围内。离开这个范围谈性能，就会得出错误的选型结论。

3. 性能到底怎么看：别被“快”字带偏

“C++26 的 std::hive 快不快”这个问题，如果只看社区里流传的基准测试片段，很容易被带偏。因为不同测试里，元素大小、删除比例、遍历频率、分配器都不一样，结论可能完全相反。

3.1 快在哪里，慢在哪里

从机制上可以做一个不会错的拆解：

• 插入：hive的插入通常是摊销 O(1)，但如果只在尾部连续追加，vector::push_back仍然是很难被击败的，因为它的连续内存和reserve机制太适合批量追加了。
• 删除：hive的erase是 O(1)，而且不移动其他元素。这是它对比vector的核心优势。删除越多，优势越明显。
• 遍历：hive遍历会跨块、跳空槽，通常比vector慢一点，但会明显好于list和map。具体差距取决于块大小和空槽比例。
• 内存：删除后留下的空槽会占用空间，直到被后续插入复用。如果长期高频删除但很少插入，hive的内存占用可能高于压缩后的vector。

还有一种更常见的误解是“hive 一定比 vector 快”。实际上，如果你的代码里几乎不删除元素，vector几乎总是更优。hive的优势不在“省时间”本身，而在“删除时间不再随元素数量增长而增长”。

3.2 常见基准测试的正确读法

看到一篇对比hive和vector的基准文章，我建议你先检查这几个变量：

• 元素类型是不是真实对象，而不是一个int。对象越大，vector的移动成本越高，hive收益越明显。
• 是否分别测了“只插入”“只遍历”“删除 10% / 50% / 90%”等不同操作组合。
• 删除是随机位置删除还是顺序遍历时删除，两者的成本结构不同。
• 是否使用了真实项目的分配器。默认new/delete和 arena 分配器的表现差异很大。
• 是否跑了多次并取中位数，而不是只看单次最优结果。

如果这些变量没有写清楚，那基准结论只能当作参考，不能直接迁移到你的项目里。

3.3 删除数量、插入模式和遍历频率如何影响收益

从工程经验看，std::hive的优势通常会在以下条件同时满足时被放大：

• 元素数量足够大，删除不再是零星一两次，而是频繁发生。
• 删除发生后，你仍然需要遍历大量剩余元素，而不是删完就结束。
• 元素对象比较大，移动和拷贝的成本高。
• 你需要稳定引用，否则可能用一个自定义 freelist 就够了。

反过来，如果元素只有几个字节，删除也不频繁，那hive的收益可能很小，甚至因为空槽标记和块管理的开销而变慢。这时候坚持用vector反而是更理性的选择。

3.4 需要警惕的隐藏成本

hive不是银弹，它也有一些很容易被忽略的成本：

• 如果块容量设置不合理，空槽比例升高，内存浪费会被放大。
• erase仍然会调用元素的析构函数。如果析构本身昂贵，例如要释放资源、写日志、通知远端，那这个成本不会因为容器而消失。
• 调试构建下，迭代器有效性检查和块遍历逻辑可能比vector慢不少。
• 标准库实现不同，块大小的默认策略和分配器交互方式可能不同。跨平台对比性能时，不能只测一个编译器。

4. 上手实践：从最小示例到正确姿势

如果你想现在就体验hive的能力，可以先从plf::colony入手，或者在你的编译器已经提供实验性支持时直接使用提案接口。但要注意，标准版 API 目前还没有完全定稿，落地前要确认版本。

4.1 编译环境和依赖确认

截至 C++26 的标准制定流程，std::hive仍处于提案和实现验证阶段，主流编译器的稳定版本通常还没有提供<hive>头文件。所以在动手之前：

• 先确认你的编译器是否已经提供std::hive，以及它对应的 feature-test 宏。
• 如果编译器不支持，可以用plf::colony作为行为参考，它的核心机制与hive高度一致。
• 不要假设它有和vector相同的 API，例如reserve、operator[]、data()这些方法在hive语义下并不合理。

建议：先在一个独立小项目里验证，不要把提案阶段接口直接大量引入生产代码的核心路径；等到标准版接口稳定后再迁移。

4.2 最小示例：插入、遍历、删除

下面是一个基于提案接口的示意写法。实际编译时，请以你所用编译器和实现提供的头文件与 API 为准。

#include <hive> // C++26 提案接口，最终以标准规范为准 #include <cstdint> struct Task { uint64_t id; uint32_t priority; bool finished = false; }; int main() { std::hive<Task> tasks; for (int i = 0; i < 1024; ++i) { tasks.insert({static_cast<uint64_t>(i), 0}); } // 遍历并删除已经完成的任务 for (auto it = tasks.begin(); it != tasks.end();) { if (it->finished) { it = tasks.erase(it); // erase 返回下一个有效元素的迭代器 } else { ++it; } } return 0; }

这段代码的核心是删除循环。不要写成先++it再erase的前一个迭代器，那样容易漏掉元素或触达无效迭代器。更安全的写法是把erase的返回值赋回it。

4.3 关键 API 的行为边界

在提案实现里，几个常见 API 的行为需要特别注意：

• insert(value)：通常返回指向新插入元素的迭代器。元素一旦构造完成，它的地址在插入、删除其他元素时不会变化。
• erase(iterator)：O(1)，会使被删除位置的迭代器失效，但其他元素的迭代器和引用仍然有效。
• erase(iterator)的返回值：通常是下一个有效元素。这也是我推荐在删除循环里使用返回值的原因。
• begin()/end()：遍历顺序与插入顺序无关，与元素的构造顺序也可能不同。
• 没有operator[]和at()，没有按索引访问的能力。

这里最反直觉的一点是：hive允许你长期保存元素指针，但这种稳定性只适用于“元素仍然存活在容器里”的情况。如果那个元素已经被erase了，你保存的指针就悬空了，容器不会帮你兜底。

4.4 新手最容易犯的三个错误

结合社区和实际项目里的反馈，我总结了三个最常见的使用错误：

1. 把 hive 当 vector 用：试图拿std::advance(it, n)做随机访问，或者期望元素地址可以按块推算。hive的迭代器不是随机访问迭代器，不要按数组思维使用。
2. 删除时维护了错误的迭代器副本：虽然erase不使其他迭代器失效，但如果你在同一轮遍历里erase了某个迭代器对应的元素，之后又使用这个旧迭代器，仍然是未定义行为。
3. 在元素内部保存自己的“索引”：vector时代很多人会在对象里存一个int index来快速定位自己。hive没有随机访问，这种字段没有意义，正确做法是使用迭代器或稳定指针，并配合容器生命周期管理。

5. 真实场景里什么时候该换、什么时候不该换

选型不能只看容器名称，要看你的访问模式。下面是我认为比较可靠的经验划分。

5.1 适合 hive 的典型场景

• 游戏 ECS 的组件存储：实体不断生成和销毁，每帧需要遍历所有存活组件做更新。
• 事件系统：回调任务注册后被执行，执行完就需要删除，同时下一个事件往往需要遍历剩余回调。
• 粒子系统：粒子不断产生和消亡，每帧需要更新所有存活粒子。
• 网络会话管理：连接数量大，断开时频繁移除，又要周期遍历全部连接做心跳或广播。

这些场景有三个共同点：删除频繁、遍历所有有效元素是主循环、不要求顺序。

5.2 不适合 hive 的典型场景

• 需要按索引随机访问，例如实现堆、双端队列、矩阵运算。
• 需要有序遍历，例如按插入顺序输出、按优先级输出。
• 几乎不删除元素，但会大量追加，vector + reserve的连续追加几乎没有对手。
• 元素数量非常少，几十个以内时，任何容器的性能差异都不值得引入新结构。
• 需要排序和二分查找，vector加sort/binary_search仍然是标准解法。

5.3 一个可复用的选型判断框架

我一般会这样快速判断：

如果还是不确定，就走四步：

1. 列出你的访问模式：插入、删除、遍历、查找、排序，各自占比是多少。
2. 问自己顺序约束强不强：是否必须按某种业务顺序遍历。
3. 问自己引用稳定性是否重要：元素之间是否会长期保存指针。
4. 最后，用真实的数据规模和真实分配器跑一个小型基准，不要凭理论下结论。

6. 如果性能还是不理想，问题可能出在哪

换到hive之后，性能不一定立刻如预期。这时候不要急着换回vector，而是按顺序排查。

6.1 先确认瓶颈确实在容器

我见过很多换容器后依然卡顿的案例，最后定位到的瓶颈根本不是容器操作，而是对象拷贝、网络等待、日志输出或虚拟函数调用。先用 profiler 看一下热点在哪。如果容器操作在热点里占比并不高，换容器并不会带来明显收益。

6.2 按“数据规模-操作组合-分配器-缓存”顺序排查

建议按下面的顺序逐层检查：

1. 数据规模：100 个元素和 100 万个元素的结论可能完全相反。先确认你的规模是否真的到了需要优化的量级。
2. 操作组合：遍历次数 vs 删除次数。如果遍历是绝对主体，vector的连续内存优势可能比hive的删除优势更值钱。
3. 对象大小：sizeof(T)越大，移动成本越高，hive相对vector的优势越明显；如果元素只有 8 字节，两者的差距会被压缩。
4. 分配器：默认new/delete每次块分配成本不低。换成 arena 或 monotonic 分配器后，hive的块分配开销会被显著摊薄。
5. 块容量和空槽比例：如果空槽太多，遍历时跳过标记本身也有成本。某些实现允许调整块容量，可以针对对象大小做试验。
6. 析构成本：如果元素析构函数很贵，比如要释放数据库连接、写文件、通知外部系统，那这个成本不会因为容器而消失。

建议：一次只改一个变量。先把数据规模、操作组合、对象大小固定下来，再对比不同容器；否则你很难判断收益到底来自容器，还是来自测试条件。

6.3 回到 vector 或自定义结构的信号

如果出现下面这些信号，说明hive可能不适合当前项目：

• 基准显示hive只比vector快 5% 左右，而项目已经有大量基于vector的代码和心智模型。
• 业务核心突然变成“需要按某个字段排序后遍历”，hive的迭代器无法直接进入排序函数。
• 空槽比例长期偏高，内存占用成为主要矛盾，而删除频率又在下降。

这时候，可以考虑保留vector作为排序和检索的副本，hive只作为活跃集合，通过定时重建来压缩空槽。这是一种常见的混合用法，不必在单个容器上走极端。

7. 工程视角：std::hive 改变的不是单点速度，而是设计取舍

最后一个值得讨论的问题，是std::hive会怎样改变你的工程方式。

7.1 它是把缓存友好和稳定引用同时给你的选择

vector给缓存，但不给稳定引用；list给稳定引用，但不给缓存。hive在无序场景里同时给了两者，代价是牺牲顺序和随机访问。这本质上不是一种“更快”的容器，而是一种“不同取舍”的容器。

工程上的收益在于：你不再需要为了实现“删除不搬动”而把内存打散，也不必为了缓存而引入复杂的标记删除和延迟压缩。你可以直接表达“这个集合会频繁增删，但我仍然希望遍历时尽量高效”这样的需求。

7.2 对项目和团队的影响

引入hive后，代码里可以更自然地持有实体指针。因为当一个元素被删除时，其他元素不会移动，指针和引用保持有效。

但也要约定好容器生命周期：

• 谁拥有这个容器。
• 谁负责删除元素。
• 谁负责在元素死亡时通知所有持有它指针的代码。

hive只保证容器内部行为正确，不解决语义上的悬空指针。你仍然需要像使用任何非所有权容器一样，小心处理“指向已删除元素”的引用。

7.3 在 C++26 正式落地前可以做什么

如果你被std::hive解决了痛点，但又不想在标准接口没定稿时冒险，可以考虑：

1. 先把plf::colony引入到原型或非关键模块，积累真实性能数据。
2. 在现有代码里，把“删除频繁 + 引用需要稳定 + 无序”的容器位置标记出来，等待标准接口稳定后切换。
3. 不要在生产核心路径里大面积使用提案阶段的 API，因为接口细节可能调整。
4. 关注编译器的 feature-test 宏和标准修订记录，通过条件编译平滑过渡，避免未来换标准版本时大量改代码。

如果你现在正被一段“每帧删掉大量元素后还要继续遍历全部剩余元素”的代码折磨，std::hive值得认真了解。但我的建议是：先不要为了“快”而换容器，先用第五节的判断框架确认你的场景真的满足“无序、删除密集、引用稳定、需要整体遍历”几个条件，再在真实数据上跑一个小型基准。到那时候你会发现，hive带来的并不是某一次操作的性能神话，而是一种新的取舍方式：在不需要顺序的领域，你终于不必因为删除而牺牲缓存，也不必因为缓存而放弃删除，更不必为了稳定引用，把一个本来可以很简单的集合改写成一张复杂的图。