C++使用placement new搭配realloc触发Invalid read与非法free问题

你的内存错误核心原因是错误使用C标准库realloc管理带非平凡构造/析构逻辑的C++类型对象，和placement new本身机制无关。

为什么会触发内存错误 #

• realloc的底层逻辑是纯内存操作：如果当前内存块后方没有足够连续空闲空间，它会申请一块新的足够大的内存块，把原内存块的内容按位拷贝（等价于memcpy）到新块，最后直接释放旧内存块。整个过程完全不感知C++对象的生命周期：既不会调用旧内存块上对象的析构函数，也不会在新内存块上调用对象的拷贝/移动构造函数。
• 你代码中存储的std::string属于典型的非平凡类型，主流实现都自带短字符串优化（SSO）：
  • 当字符串长度低于SSO阈值时，字符串内容直接存在对象内部预留空间，位拷贝暂时不会触发显性错误
  • 当字符串长度超过SSO阈值时，对象内部会持有一个指向堆上字符缓冲区的指针。realloc做位拷贝后，新旧内存位置上会同时存在多个持有同一个堆指针的string对象，直接触发未定义行为。
• 你代码中cap从1开始每次翻倍扩容，存储40个元素会经历1→2→4→8→16→32→64共6次扩容，每次扩容触发内存搬移时，之前已经构造好的string对象都会失效：旧内存块被直接释放、上面的对象没走析构流程，新内存块上的对象是直接位拷贝出来的，不是经过合法构造的C++对象。最后你调用std::destroy_n逐个析构对象时，同一块字符串堆内存会被重复释放，就会报出Invalid free()、Invalid read of size 1的错误。

为什么移除std::destroy_n后错误消失、也检测不到内存泄漏 #

这完全是运行时的巧合，不代表代码逻辑正确：

• 移除析构调用后，那些位拷贝产生的、持有重复堆指针的string对象根本不会执行析构逻辑，自然不会触发重复free的报错，不存在"string析构函数被自动调用"的情况。
• 所谓"无内存泄漏"是检测工具的假阳性：程序退出时操作系统会统一回收进程持有的所有内存，内存检测工具在这种场景下通常无法识别出未被析构对象持有的嵌套堆分配，会漏报泄漏。实际上那些长字符串持有的堆内存因为对象没有被析构，在程序运行期间是实打实的泄漏，只是程序退出时被OS一并回收了。

正确实现方式 #

不要用malloc/realloc/free这类C内存函数直接管理非平凡C++类型的动态数组，手动实现动态数组扩容需要严格遵守对象生命周期规则：

1. 扩容时先申请未初始化的原始内存，不要直接调用会触发对象默认构造的内存分配接口
2. 用placement new将旧内存上的元素逐个移动构造到新内存上
3. 逐个析构旧内存上的所有有效元素
4. 释放旧内存块

参考正确的扩容逻辑实现：

if(size == cap) {
    size_t new_cap = cap == 0 ? 1 : cap * 2;
    // 申请对齐的原始未初始化内存
    std::string* new_strs = static_cast<std::string*>(::operator new(new_cap * sizeof(std::string)));
    // 逐元素移动构造到新内存
    for(size_t i = 0; i < size; i++) {
        new (&new_strs[i]) std::string(std::move(strs[i]));
    }
    // 析构旧内存上的所有有效元素
    std::destroy_n(strs, size);
    // 释放旧原始内存块
    ::operator delete(strs);
    // 更新指针与容量
    strs = new_strs;
    cap = new_cap;
}

你原来代码末尾先调用std::destroy_n析构所有有效元素、再释放内存块的逻辑本身是正确的，错误点只在扩容阶段误用了realloc。

内容的提问来源于stack exchange，提问作者Denilson Martins