std::vector的push_back多线程并发调用必然崩溃，因其扩容导致迭代器/引用失效，向已释放内存写入触发SIGSEGV；必须加锁保护所有写操作，读多写少时可用shared_mutex或双缓冲优化。
直接结论：std::vector 的 push_back 在多线程下并发调用必然崩溃，不是概率问题，而是确定性未定义行为（UB）。它根本不支持无保护的并发写入。
为什么 push_back 多线程调用会崩溃
崩溃根源不在“线程抢着写同一个元素”，而在于 push_back 可能触发扩容——即重新分配内存、拷贝旧数据、释放旧内存。一旦发生扩容，所有原有指针、引用、迭代器全部失效。如果另一个线程正持有 goods_list.at(i) 返回的引用（比如 Goods& goods），此时对 goods.local_pic 赋值，就是在向已释放内存地址写入，触发 SIGSEGV。
常见错误现象包括：
- Release 模式下崩溃，Debug 下看似正常（优化掩盖了内存破坏）
- 崩溃位置飘忽，有时在
push_back，有时在后续任意使用引用/迭代器的地方 - 用
valgrind或AddressSanitizer会明确报heap-use-after-free
最简单有效的解决方式：加锁 + 预留容量
别信“只锁扩容”或“用 reserve 就安全”的说法——reserve 只是避免扩容，但无法解决并发读写冲突。真正安全的做法是：写操作必须串行化，读操作可并行，但需保证读时无人在写。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
- 用
std::mutex包裹所有可能修改vector的操作（push_back、clear、erase、resize） - 在初始化阶段调用
goods_list.reserve(30000)，减少锁争用时间（扩容本身不耗时，但拷贝和释放耗时且不可中断） - 避免在锁内做耗时操作（如网络请求、图片下载），把数据准备好再进锁写入
- 若读远多于写，考虑用
std::shared_mutex（C++17）实现读写锁，提升读并发度
替代方案：双缓冲队列（免锁但需权衡）
当写入频率低、读取频繁且允许短暂延迟时，可用双缓冲（double-buffering）规避锁开销。核心思路是：写线程往一个临时 vector 写，定期原子替换主容器指针。
关键点：
- 主容器必须是
std::shared_ptr<:vector>></:vector>，替换用std::atomic_store - 读线程每次访问前先
load当前指针，之后全程用该副本，不关心后续替换 - 写完后清空临时容器，而非直接复用——避免残留迭代器失效风险
- 不适用于需要实时强一致性的场景（如配置热更新要求毫秒级生效）
容易被忽略的坑：你以为只是读，其实也在写
很多崩溃源于误判线程行为。例如：
-
at()和operator[]看似只读，但at()在 debug 模式下会检查边界并抛异常——异常对象构造可能间接修改全局状态 - 用
const_iterator遍历，但另一线程调用clear()，导致迭代器立即失效（clear使所有迭代器失效） - STL 实现差异：libstdc++ 和 libc++ 对迭代器失效的检测严格度不同，Linux 下可能“侥幸”不崩，但不代表安全
最稳妥的做法，永远以“vector 是完全非线程安全的容器”为前提设计访问逻辑——写必须锁，读若跨线程且写线程活跃，也建议锁或换用线程安全容器（如 boost::lockfree::queue 用于生产者-消费者场景）。
