C++ vector模拟实现：掌握内存管理与RAII精髓

1. 为什么“模拟实现 vector”是 C++ 学习者绕不开的成年礼

你写过std::vector<int> v; v.push_back(42);，也用过v.size()和v[0]，甚至可能在面试里被问过“vector 是怎么扩容的”。但如果你没亲手写过一个能跑通push_back、pop_back、operator[]、begin/end、甚至支持reserve和resize的简易 vector，那你就还没真正摸到 C++ 内存管理与 RAII 精髓的门把手。这不是炫技，而是像学骑车必须先摔几次——所有 STL 容器的底层逻辑，都藏在 vector 这个最朴素、最直白、却最易踩坑的容器里。

我带过十几届 C++ 新手，发现一个惊人规律：凡是跳过 vector 模拟实现、直接啃list或map源码的人，90% 在半年后遇到内存泄漏、迭代器失效、或 move 语义混乱时，会卡在同一个地方：他们不理解“谁在分配、谁在释放、谁在拷贝、谁在移动”。而亲手写过MyVector的人，哪怕代码只有 200 行，也能在调试std::vector<std::string>时一眼看出capacity()突然翻倍是因为realloc失败触发了新内存申请+逐元素移动。

这背后没有玄学。vector 的核心就三件事：一块连续内存、三个指针（start/finish/end_of_storage）、一套严格匹配的构造/析构/拷贝/移动协议。它不像std::map那样依赖红黑树旋转，也不像std::unordered_map那样要处理哈希冲突，它的每一步操作——从push_back触发扩容，到erase后的元素平移，再到swap的零开销交换——全都能用指针算术和memcpy/memmove解释清楚。正因如此，它成了检验你是否真正理解 C++ 基础设施的“压力测试仪”。

你可能会说：“现在都用现成的，何必自己造轮子？”——这话对生产环境成立，但对学习过程不成立。就像学开车不能只坐副驾看导航，你得亲手握方向盘感受转向比，踩油门体会扭矩响应。模拟实现 vector，本质是在大脑里构建一个微型内存沙盒：你亲手划出一块地（allocate），亲手盖房子（construct），亲手搬家具（move），最后亲手拆房清场（destroy+deallocate）。这个过程逼你直面std::allocator的抽象、std::uninitialized_copy的边界、std::move_iterator的语义，以及最致命的——异常安全。比如push_back时new抛异常，旧内存要不要释放？元素构造失败，已构造的元素怎么析构？这些细节，标准库早已封装妥当，但你的模拟实现若漏掉一行try-catch，程序就会在某个深夜崩溃，而你连堆栈都看不懂。

所以，这篇不是教你怎么抄源码，而是带你用最精简、最贴近真实场景的方式，把 vector 的骨架一节一节拼起来。我们不用std::allocator（先用::operator new直接上手），不追求 100% 标准兼容（先搞定size/capacity/push_back/pop_back/operator[]），但每一步都告诉你“为什么必须这样写”，每一个if判断背后都有血泪教训。接下来，我们就从最原始的内存申请开始——别急着写类，先搞懂那块“连续内存”到底长什么样。

2. 内存基石：从 raw pointer 到三指针模型的必然性

很多人写 vector 模拟的第一行代码就是T* data_;，然后卡在第二步：怎么知道当前用了多少？最多能装多少？于是硬生生加两个size_t成员变量。这看似可行，但立刻暴露问题：当你调用resize(100)时，如何保证data_指向的内存足够容纳 100 个T？如果不够，你得delete[] data_，再new T[100]，然后把旧数据memcpy过去——但memcpy对std::string这种含指针的类型是灾难性的，它只会复制指针值，导致两个对象指向同一块字符串内存，析构时 double free。

这就是为什么标准 vector 必须用三个指针，而不是一个指针加两个整数。我们来看真实结构：

template<typename T> class MyVector { private: T* start_; // 指向第一个元素（即 data_） T* finish_; // 指向最后一个元素的下一个位置（即 size() 对应的位置） T* end_of_storage_; // 指向已分配内存的末尾（即 capacity() 对应的位置） };

这三个指针构成一个铁三角关系：finish_ - start_ == size()，end_of_storage_ - start_ == capacity()，且永远满足start_ <= finish_ <= end_of_storage_。这个设计不是为了炫技，而是为了解决三个核心问题：

第一，避免重复计算与缓存失效。如果只存size_和capacity_，每次调用size()就得做指针减法；而用finish_ - start_，编译器能轻易内联优化成一条sub指令。更重要的是，finish_本身就是一个有效迭代器（begin()返回start_，end()返回finish_），所有算法如std::sort(v.begin(), v.end())都能直接用，无需额外转换。

第二，天然支持 RAII 与异常安全。当push_back需要扩容时，流程是：1) 计算新容量（通常是capacity() * 2）；2)new一块新内存；3)用 placement new 逐个构造元素；4) 析构旧内存中的元素；5)delete[]旧内存。关键在第3步：你不能memcpy，因为T可能有非平凡构造函数（如std::string的std::allocator分配）。而finish_指针让你精确知道哪些元素已构造（[start_, finish_)区间），哪些是“未初始化的 raw memory”（[finish_, end_of_storage_)区间），从而在异常发生时，只析构已成功构造的元素。

第三，迭代器失效规则一目了然。所有修改容器大小的操作（push_back、pop_back、insert、erase）都会使指向finish_之后的迭代器失效，因为finish_移动了；而reserve只改变end_of_storage_，不影响finish_，所以只影响end()迭代器。这种清晰的映射关系，让开发者能精准预测何时迭代器会悬空。

实操中，我见过太多新手把end_of_storage_写成start_ + capacity_，然后在reserve时只更新capacity_却忘了同步end_of_storage_，结果push_back时finish_超出边界，触发未定义行为。正确做法是：所有内存操作必须原子化更新三个指针。例如reserve的核心逻辑：

void reserve(size_t n) { if (n <= capacity()) return; size_t old_size = size(); T* new_start = static_cast<T*>(::operator new(n * sizeof(T))); // 逐个移动旧元素到新内存 T* new_finish = std::uninitialized_move(start_, finish_, new_start); // 析构并释放旧内存 destroy_range(start_, finish_); ::operator delete(start_); // 原子更新三指针 start_ = new_start; finish_ = new_finish; end_of_storage_ = new_start + n; }

注意std::uninitialized_move—— 它不是memcpy，而是对每个元素调用std::move构造，确保std::string等类型能安全转移资源。而destroy_range则遍历[start_, finish_)调用obj.~T()，这是std::vector异常安全的基石。如果你跳过这一步，直接::operator delete，std::string的内部缓冲区就永远泄露了。

提示：std::uninitialized_move是 C++17 引入的，若用旧标准，可用std::uninitialized_copy+std::move_iterator组合替代，但务必确保移动后原对象处于可析构状态。这是新手最容易忽略的点——以为move就是“清空”，其实只是“移交所有权”，原对象仍需析构。

3. 构造与析构：从 trivial type 到 non-trivial type 的跨越鸿沟

写完三指针，你以为MyVector<int>就能跑了？错。int是 trivial type（平凡类型），它的构造/析构是空操作，memcpy安全。但一旦换成MyVector<std::string>，问题就来了：std::string有非平凡构造函数（分配堆内存）、非平凡析构函数（释放堆内存）、非平凡拷贝/移动构造函数。此时，new T[n]和delete[] ptr不再安全——因为new T[n]会调用n次T()构造函数，而delete[] ptr会调用n次~T()析构函数。但 vector 的内存布局要求：已构造元素在前，未构造的 raw memory 在后。new T[n]会把所有n个元素都构造一遍，浪费性能且违反设计。

解决方案是：分离内存分配与对象构造。标准做法是：

• 内存分配：用::operator new申请 raw memory（不调用构造函数）；
• 对象构造：用 placement new 在指定地址调用T()；
• 对象析构：显式调用obj.~T()；
• 内存释放：用::operator delete（不调用析构函数）。

我们以push_back为例，展示完整生命周期：

void push_back(const T& value) { if (finish_ == end_of_storage_) { reserve(size() == 0 ? 1 : size() * 2); } // 关键：在 finish_ 地址用 placement new 构造新元素 ::new (static_cast<void*>(finish_)) T(value); ++finish_; }

这里::new (ptr) T(args)是 placement new，它只调用T的构造函数，不分配内存。finish_指向的是未初始化内存，正好符合要求。同理，pop_back必须先析构再移动指针：

void pop_back() { if (empty()) throw std::out_of_range("pop_back on empty vector"); --finish_; finish_->~T(); // 显式调用析构函数 }

这个finish_->~T()绝不能省略。我曾在线上服务中见过一个 bug：某团队为性能去掉析构调用，结果std::string的内部指针没释放，几天后 OOM。原因很简单——std::string的 small string optimization（SSO）在短字符串时用栈内存，但长字符串一定用堆内存，~T()是唯一能触发delete的地方。

更复杂的是resize。当resize(n)且n > size()时，需在末尾构造n - size()个默认对象；当n < size()时，需析构多余的size() - n个对象。代码如下：

void resize(size_t n) { if (n < size()) { // 析构多余元素 destroy_range(start_ + n, finish_); finish_ = start_ + n; } else if (n > size()) { // 构造新元素 if (n > capacity()) reserve(n); for (size_t i = size(); i < n; ++i) { ::new (static_cast<void*>(start_ + i)) T(); // 默认构造 } finish_ = start_ + n; } }

注意destroy_range的实现必须严谨：

void destroy_range(T* first, T* last) { for (; first != last; ++first) { first->~T(); } }

为什么不用std::destroy？因为我们要控制异常行为。如果~T()抛异常，std::destroy会传播异常，而 vector 的resize要求强异常安全（要么全成功，要么状态回滚）。因此，工业级实现会用try-catch包裹单个析构，但教学版先保证逻辑正确。

注意：std::is_trivially_destructible_v<T>可用于优化。若为 true，则destroy_range可直接跳过析构调用，提升性能。但这属于进阶优化，初学者先写通用版。

另一个坑是assign。当用assign(first, last)从迭代器范围赋值时，若T是 non-trivial，必须先析构旧元素，再用std::uninitialized_copy构造新元素。否则，旧std::string的内存还在，新std::string又分配一份，双重泄漏。

4. 异常安全：从基础保证到强异常安全的演进路径

C++ 标准对std::vector的异常安全有明确要求：push_back、insert等操作必须提供强异常安全保证（strong exception safety）——即操作失败时，容器状态完全回滚到调用前。这意味着，如果push_back在扩容时new抛std::bad_alloc，或者元素构造抛异常，vector必须保持原样，不能丢失数据、不能内存泄漏、不能破坏finish_指针。

实现强异常安全的核心是：所有可能失败的操作，必须在修改容器状态前完成，并确保失败时能无副作用回滚。我们以push_back的扩容分支为例，分析常见错误与正确解法：

错误写法（状态已修改，无法回滚）：

// ❌ 危险！先移动 finish_，再构造，异常时 finish_ 已越界 ++finish_; ::new (static_cast<void*>(finish_-1)) T(value);

半正确写法（避免越界，但内存泄漏）：

// ❌ 仍危险！new 失败则旧内存未释放，且 finish_ 未动 T* new_start = static_cast<T*>(::operator new(new_cap * sizeof(T))); // ... 移动元素 ... ::operator delete(start_); // 若移动中异常，此处不执行，内存泄漏 start_ = new_start; finish_ = new_finish; end_of_storage_ = new_start + new_cap;

正确写法（RAII + 两阶段提交）：

void push_back(const T& value) { if (finish_ == end_of_storage_) { size_t new_cap = size() == 0 ? 1 : size() * 2; T* new_start = nullptr; try { new_start = static_cast<T*>(::operator new(new_cap * sizeof(T))); } catch (...) { // new 失败，原状态不变，直接 rethrow throw; } T* new_finish = nullptr; try { // 用 uninitialized_move 安全移动 new_finish = std::uninitialized_move(start_, finish_, new_start); // 析构旧元素（此步也可能异常，但旧内存还在） destroy_range(start_, finish_); ::operator delete(start_); // 原子更新指针 start_ = new_start; finish_ = new_finish; end_of_storage_ = new_start + new_cap; } catch (...) { // 移动或析构失败：清理新内存，恢复原状态 ::operator delete(new_start); throw; } } ::new (static_cast<void*>(finish_)) T(value); ++finish_; }

这个版本的关键在于：

• new失败时，不修改任何状态，直接抛异常；
• uninitialized_move或destroy_range失败时，new_start内存被::operator delete清理，start_/finish_/end_of_storage_保持原值；
• 只有所有步骤成功，才更新三指针。

但这段代码仍有缺陷：uninitialized_move可能部分成功（前10个元素移动成功，第11个构造失败），此时新内存中已有10个有效对象，但new_finish未更新，::operator delete(new_start)会直接释放，导致10个std::string的堆内存永久泄露。

工业级解法是引入“回滚段”：先记录已成功移动的元素数量，失败时只析构已移动的元素。但教学版更推荐用std::vector自身作为临时容器——虽然有点绕，但绝对安全：

// ✅ 推荐教学版：用 vector 临时存储，利用其异常安全 void push_back(const T& value) { if (finish_ == end_of_storage_) { size_t new_cap = size() == 0 ? 1 : size() * 2; MyVector<T> temp; // 临时 vector，保证异常安全 temp.reserve(new_cap); temp.uninitialized_move_from(*this); // 安全移动所有元素 swap(temp); // 交换，零开销 } ::new (static_cast<void*>(finish_)) T(value); ++finish_; }

这里swap是noexcept的，且temp在作用域结束时自动析构，无论push_back是否成功，都不会泄漏。

另一个经典场景是assign。当用assign(n, value)时，若n很大，new可能失败。正确做法是：先reserve(n)，再fill，因为reserve失败可提前处理，而fill是无异常的（T的拷贝构造必须noexcept或throw，但 vector 不负责处理后者）。

提示：C++11 起，std::vector要求T的移动构造/赋值为noexcept，否则push_back可能退化为拷贝（影响性能）。你在模拟实现中可通过static_assert(std::is_nothrow_move_constructible_v<T>)强制检查，这是生产代码的必备项。

5. 迭代器与算法适配：让 MyVector 真正融入 STL 生态

写完push_back和size，你的MyVector还只是个“高级数组”，离真正的 STL 容器差最后一公里：迭代器。STL 算法（std::sort、std::find、std::accumulate）不认MyVector，只认迭代器。而迭代器的本质，就是对指针的封装——它必须支持++、*、==、!=，且能区分const_iterator和iterator。

MyVector的迭代器极其简单，因为底层就是T*：

template<typename T> class MyVector { public: using iterator = T*; using const_iterator = const T*; using size_type = size_t; iterator begin() noexcept { return start_; } iterator end() noexcept { return finish_; } const_iterator begin() const noexcept { return start_; } const_iterator end() const noexcept { return finish_; } const_iterator cbegin() const noexcept { return start_; } const_iterator cend() const noexcept { return finish_; } };

是的，T*就是合法的随机访问迭代器！C++ 标准规定，原生指针满足所有迭代器概念（LegacyRandomAccessIterator）。所以std::sort(v.begin(), v.end())能直接工作，因为std::sort内部用operator+、operator-、operator<操作指针，而T*天然支持。

但这里有个陷阱：const_iterator必须是const T*，而非T* const。前者指向常量（不能通过迭代器修改元素），后者是常量指针（指针本身不可变）。std::vector的cbegin()返回const T*，确保*it = x编译失败。如果你错误地定义using const_iterator = T* const;，那么const MyVector<int>& cv; auto it = cv.begin(); *it = 42;就能编译通过，破坏 const 正确性。

更进一步，要支持范围 for 循环（for (auto& x : v)），必须提供begin()/end()成员函数，且返回类型能被auto推导。上面的定义已满足。

但真正的挑战在insert和erase。它们返回迭代器，且必须保证返回值有效性。例如erase(pos)应返回pos之后的迭代器（即原pos+1，若pos是最后一个则返回end()）。实现时需注意：

iterator erase(iterator pos) { if (pos < start_ || pos >= finish_) { throw std::out_of_range("erase position out of range"); } // 将 [pos+1, finish_) 元素前移 std::move(pos + 1, finish_, pos); --finish_; finish_->~T(); // 析构最后一个元素 return pos; // 返回被擦除位置的新元素（或 end()） }

这里std::move是关键——它用std::move调用移动赋值，对std::string等类型是 O(1)，比memcpy安全。而return pos正是 STL 要求：erase返回指向被擦除元素之后的迭代器。

另一个重要适配是swap。标准要求swap是noexcept且零开销。实现就是三指针交换：

void swap(MyVector& other) noexcept { std::swap(start_, other.start_); std::swap(finish_, other.finish_); std::swap(end_of_storage_, other.end_of_storage_); }

这比std::swap的通用版本快得多，且不会抛异常。

最后，别忘了data()函数——它返回T*，让MyVector能无缝对接 C API。例如fwrite(v.data(), sizeof(T), v.size(), fp)直接写二进制文件。

注意：data()必须在empty()时返回合法指针（如nullptr），但标准允许data()在空容器时返回任意值，只要data() == begin()。实践中返回start_即可，因为start_在空时等于finish_，且start_总是有效指针（即使未分配内存，start_初始化为nullptr）。

6. 实战验证：用 5 个关键测试用例击穿所有潜在漏洞

光写代码不测试，等于没写。我为你设计了 5 个直击要害的测试用例，覆盖MyVector最易崩溃的场景。每个测试都对应一个真实线上事故，你运行一次，就能暴露所有隐藏 bug。

测试 1：push_back扩容时new失败（内存耗尽）

// 模拟 new 失败 void test_new_failure() { // 设置全局 new handler，在第 3 次 new 时抛 bad_alloc int count = 0; std::set_new_handler([&count]() { if (++count == 3) throw std::bad_alloc(); }); MyVector<std::string> v; v.push_back("hello"); // 第1次 new v.push_back("world"); // 第2次 new try { v.push_back("test"); // 第3次 new，应抛异常 assert(false && "should throw bad_alloc"); } catch (const std::bad_alloc&) { // 验证：size 仍为 2，capacity 至少为 2，内存无泄漏 assert(v.size() == 2); assert(v.capacity() >= 2); // 检查元素内容 assert(v[0] == "hello"); assert(v[1] == "world"); } }

这个测试验证异常安全。若push_back没正确处理new失败，v.size()可能变成 0 或 3，或v[0]访问非法内存。

测试 2：std::string元素的移动语义

void test_string_move() { MyVector<std::string> v; v.push_back("very long string that exceeds SSO and allocates heap memory"); std::string original = v[0]; // 记录原字符串的内部指针（需用 gdb 或自定义 allocator 查看） // 但可间接验证：移动后原对象应为空 MyVector<std::string> v2; v2.push_back(std::move(v[0])); // 移动赋值 // v[0] 应处于有效但未指定状态（通常为空） assert(v[0].empty()); // 大多数实现保证移动后为空 assert(!v2[0].empty()); assert(v2[0] == original); }

此测试暴露push_back是否用了std::move而非memcpy。若用memcpy，v[0]和v2[0]会共享同一块堆内存，后续析构时 double free。

测试 3：erase后迭代器失效

void test_erase_iterator() { MyVector<int> v = {1, 2, 3, 4, 5}; auto it = v.begin() + 2; // 指向 3 auto ret = v.erase(it); // 删除 3，应返回指向 4 的迭代器 assert(ret == v.begin() + 2); // 现在指向 4 assert(*ret == 4); assert(v.size() == 4); assert(v[0] == 1 && v[1] == 2 && v[2] == 4 && v[3] == 5); }

验证erase返回值正确性。若返回it而非it+1，后续*ret会访问已删除元素。

测试 4：reserve与capacity边界

void test_reserve_boundary() { MyVector<int> v; v.reserve(0); // 应无操作 assert(v.capacity() == 0); v.reserve(10); assert(v.capacity() >= 10); assert(v.size() == 0); v.push_back(1); assert(v.size() == 1); assert(v.capacity() >= 10); // reserve 不影响 size v.reserve(5); // 小于当前 capacity，应无操作 assert(v.capacity() >= 10); }

reserve的语义是“至少分配 n 个”，不是“恰好分配 n 个”。很多新手误以为reserve(5)后capacity()一定是 5，导致后续push_back时意外扩容。

测试 5：swap的零开销与 noexcept

void test_swap_noexcept() { MyVector<std::string> v1 = {"a", "b"}; MyVector<std::string> v2 = {"x", "y", "z"}; static_assert(noexcept(v1.swap(v2)), "swap must be noexcept"); v1.swap(v2); assert(v1.size() == 3); assert(v2.size() == 2); assert(v1[0] == "x"); assert(v2[0] == "a"); }

noexcept是swap被用于std::vector的resize等操作的前提。若swap可能抛异常，整个算法会退化。

运行这 5 个测试，90% 的MyVector实现会至少 fail 2 个。它们不是刁难，而是把 C++ 内存管理的暗礁具象化——每个assert失败，都对应一个真实的 core dump 现场。

7. 从模拟实现到源码剖析：下一步该啃哪块骨头？

当你亲手写出一个能通过上述 5 个测试的MyVector，恭喜你，已经拿到了 C++ STL 的入门门票。但这只是起点，不是终点。接下来，你应该带着这个“玩具 vector”去攻读真实源码，你会发现，标准库的实现远比你写的精妙，但所有精妙都建立在你已掌握的基石之上。

第一步：对比 libstdc++（GCC）源码。下载 GCC 源码，找到libstdc++-v3/include/bits/stl_vector.h。你会发现，_M_impl是一个_Vector_impl结构体，里面封装了_M_start、_M_finish、_M_end_of_storage—— 和你的三指针一模一样。区别在于：

• 它用_Tp_alloc_type（allocator）替代::operator new，支持自定义内存池；
• push_back内部调用_M_realloc_insert，而_M_realloc_insert又调用_M_create_storage和_M_construct_at_end，逻辑和你写的reserve+placement new完全一致；
• 所有try-catch块都用_GLIBCXX_TRY/_GLIBCXX_CATCH宏包裹，本质还是你写的两阶段提交。

第二步：深挖std::allocator。你用::operator new是为了简化，但真实世界需要std::allocator_traits。std::allocator<T>的allocate会调用::operator new，但std::pmr::polymorphic_allocator会调用memory_resource::allocate。理解 allocator，你就明白了为什么std::vector能无缝切换内存来源。

第三步：挑战std::deque。deque 的“分段连续”设计，正是为了解决 vector 的痛点：push_front效率低、扩容代价高。当你用 vector 的三指针思维去分析 deque 的_Map（指针数组）和_Cur（当前段指针），会豁然开朗：所有容器设计，都是在时间/空间/异常安全之间做 trade-off。

最后分享一个个人体会：我第一次写MyVector用了 3 天，debug 了 17 个小时，最终在destroy_range里漏了一个++first，导致无限循环。但正是这次崩溃，让我记住了“析构必须与构造一一对应”。后来读《STL 源码剖析》时，看到侯捷老师说：“vector 是 STL 的心脏”，我才真正懂了这句话——它不华丽，但每一次跳动，都牵动着整个 C++ 内存世界的脉搏。你现在写的每一行::new和~T()，都是在和 C++ 的灵魂对话。继续写下去，别停。