设置无限最大负载因子的std::unordered_map单写多读是否线程安全？

核心推理漏洞：混淆单线程有效性与多线程数据竞争安全 #

你的思路里最大的问题是把单线程下迭代器不失效的保证直接套用到了多线程场景，这完全是两回事：

• C++标准明确规定，std::unordered_map的线程安全仅局限于：不同元素的const操作可以并发执行；写操作（插入、删除、修改）不能和任何其他操作（包括读）并发执行。
• 即使没有重哈希，插入操作本质是修改桶内的链表结构（比如修改链表头指针、节点的next指针）。当读操作在遍历某个桶的链表时，写操作可能正在修改同一个桶的链表指针——这属于典型的数据竞争，直接触发未定义行为。实验中看似没问题只是运气好，未定义行为可能在高并发、特定编译器/CPU架构下才会暴露（比如指针半修改导致的遍历崩溃、读取到不完整的节点数据）。

另外，关于“最大负载因子设为无限”：虽然理论上这能避免重哈希，但部分标准库实现可能对max_load_factor的取值有隐性限制，而且就算完全避免了重哈希，也解决不了插入时修改共享链表结构带来的并发风险。

桶的底层数据结构相关问题 #

• 能否获知底层结构？：C标准没有强制规定std::unordered_map的桶必须用什么结构，绝大多数主流实现（比如GCC的libstdc、Clang的libc++）都用单链表作为桶的存储结构，但这属于实现细节，不同编译器、版本可能有差异，你只能通过对应标准库的文档去确认，不能依赖标准保证。
• 能否设置底层结构？：不行，C++标准没有提供任何接口让你自定义桶的底层数据结构，这完全由标准库实现决定。

正确的单写多读替代方案 #

如果要实现安全的单写多读哈希表，推荐两种方式：

• 使用std::shared_mutex（C++17及以上）：写操作加排他锁，读操作加共享锁，这是最稳妥的方案，完全符合标准的线程安全要求。
• 改用专门的无锁哈希表实现（但这类不在标准库内，需要第三方库支持）。

内容的提问来源于stack exchange，提问作者Aviv Goll