当C++的
std::vector需要更多内存来存储新元素，而当前分配的连续内存块已满时，它并不能简单地原地扩展。相反，它会执行一个复杂但高效的“重新分配”操作。这个过程通常包括在内存中找到一块更大的新区域，将所有现有元素“搬迁”过去，然后才能安全地释放掉旧的内存区域。 解决方案
std::vector的内存重新分配过程，说白了，就是一次“搬家”行动。这个过程不是在后台悄无声息地进行，它有着明确的步骤和显著的性能开销，理解它对于写出高效且健壮的C++代码至关重要。
具体来说，当
vector的
push_back或
emplace_back操作发现当前容量不足以容纳新元素时，它会：
-
计算新容量：
vector
会根据其内部的增长策略（通常是当前容量的1.5倍或2倍）来计算一个更大的新容量。这个策略是实现定义的，但其核心思想是为了保证push_back
操作的“摊销常数时间复杂度”。 -
分配新内存：
vector
会向操作系统（或更准确地说，通过其内部的分配器）请求一块大小足够容纳新容量元素的新连续内存块。这块内存与旧内存块通常是完全不相关的。 -
元素迁移： 这是最关键也最耗时的一步。
vector
会遍历旧内存块中的所有现有元素，并使用它们的移动构造函数（如果可用）或拷贝构造函数（如果移动构造函数不可用）将它们逐一构造到新内存块中。如果元素是基本类型（如int
，double
），这相当于一次简单的内存拷贝。但对于自定义类，这可能涉及复杂的资源转移或深拷贝操作。 -
销毁旧元素： 在所有元素都成功迁移到新内存块后，
vector
会调用旧内存块中所有元素的析构函数，以释放它们可能持有的资源。 - 释放旧内存： 旧的内存块会被归还给系统。
-
更新内部状态：
vector
会更新其内部指向内存块的指针、当前容量和元素数量等状态变量。
这个过程听起来有些繁琐，但它是
vector能够提供随机访问和动态大小调整的关键所在。不过，也正因为如此，频繁的重新分配会带来显著的性能冲击，特别是当
vector中存储的是大型对象或数量庞大的元素时。 为什么
std::vector不能原地扩容？它不是动态数组吗？
是的，
std::vector本质上是一个动态数组，但“动态”并非意味着它能随意在原地变大。它之所以不能原地扩容，核心原因在于C++标准对
std::vector内存布局的严格要求：所有元素必须存储在一段连续的内存区域中。
想象一下你在图书馆借了一排书架来放书。如果书架满了，而你后面又没有空地，你就不能直接把书架往后挪一格。你必须找一个新的、更大的空地，把所有的书都搬过去，然后才能把旧书架腾出来。
内存也是如此。当
vector最初向操作系统申请一块内存时，它得到的是一个指定大小的连续内存块。如果这块内存满了，而紧接着它后面的内存已经被其他程序或数据占用了，那么
vector就无法简单地“延长”这个内存块。它别无选择，只能去内存中寻找一块全新的、足够大的连续区域，然后把所有数据都搬过去。这种连续性是
vector实现高效的随机访问（通过指针算术，例如
vec.begin() + i）和缓存局部性（连续访问内存通常更快）的基础。如果允许不连续，那么
vector的很多优点就荡然无存了。 重新分配时，元素是如何被移动的？深拷贝还是浅拷贝？
这是一个非常关键的问题，因为它直接关系到性能和潜在的资源泄露。坦白讲，重新分配时，元素的“移动”过程既不是简单的浅拷贝，也不是强制的深拷贝，它取决于元素的类型是否支持移动语义。
优先使用移动构造函数（Move Constructor）： 如果
vector
中存储的元素类型定义了移动构造函数（Type(Type&&)
），那么在重新分配时，vector
会优先使用它。移动构造函数的核心思想是“窃取”源对象的资源（例如，指针、文件句柄等），而不是复制它们。源对象在资源被窃取后会处于一个有效但未指定的状态，通常是将其内部指针设为nullptr
，以防止在析构时双重释放。 这种方式效率极高，因为它避免了昂贵的资源复制操作，只是简单地转移了所有权。对于那些管理动态内存或文件句柄的类来说，移动语义是性能优化的利器。退而求其次，使用拷贝构造函数（Copy Constructor）： 如果元素类型没有定义移动构造函数，或者移动操作被显式标记为
noexcept(false)
（即可能抛出异常），那么vector
就会退而求其次，使用元素的拷贝构造函数（Type(const Type&)
）来将旧元素复制到新内存区域。 拷贝构造函数通常会执行“深拷贝”，这意味着它会为所有动态分配的资源创建新的副本。这无疑会增加内存分配和复制的开销，尤其是在元素本身包含大量数据或复杂结构时。平凡类型（Trivial Types）的特殊情况： 对于像
int
、double
、char
数组或不包含任何用户定义构造/析构函数、虚函数、基类等的简单结构体，它们被称为“平凡类型”。对于这类类型，C++编译器通常会优化，直接执行位拷贝（memcpy
），这效率最高，因为它不需要调用任何构造函数。从某种意义上说，这可以看作是一种特殊的“浅拷贝”，但由于这些类型不管理外部资源，所以不会有资源泄露的问题。
总结来说，
vector在重新分配时会尽可能地利用最高效的机制来迁移元素。作为开发者，如果你自定义了类，并希望它在
vector中表现良好，那么提供一个高效的移动构造函数是至关重要的。 扩容策略对性能有什么影响？我们能控制它吗？
扩容策略对
std::vector的性能影响是深远的，它直接关系到你的程序在添加元素时会遇到多少次性能“尖峰”。我们当然可以，也应该，在一定程度上控制它。
最常见的扩容策略是指数增长，比如每次容量不足时就翻倍（
new_capacity = old_capacity * 2）或者增长1.5倍。这种策略的妙处在于，它保证了
push_back操作的摊销常数时间复杂度。这意味着，虽然偶尔会有一次昂贵的重新分配，但在一个足够长的序列中，每次
push_back的平均成本是常数级别的。这是因为，每次重新分配后，我们能容纳的元素数量会显著增加，使得下一次重新分配的间隔更长。
然而，这种策略也有其弊端：
-
内存浪费： 尤其是在容量刚翻倍之后，
vector
可能只使用了新容量的一小部分，导致大量内存处于空闲状态。对于内存敏感的应用，这可能是一个问题。 - 性能抖动： 尽管摊销复杂度是常数，但当重新分配真正发生时，它依然是一个O(N)操作（N为当前元素数量），可能会导致程序的响应时间出现明显的卡顿，这在实时系统或交互式应用中是不可接受的。
那么，我们能控制它吗？答案是肯定的，通过以下两种主要方式：
-
reserve(capacity)
： 这是最直接也最推荐的控制方式。如果你预先知道vector
大致会存储多少个元素，或者至少知道一个上限，那么在向vector
添加元素之前，调用vector.reserve(N)
可以一次性分配足够的内存。这样，在添加前N个元素时，就不会发生任何重新分配，从而避免了所有相关的性能开销和迭代器失效问题。这对于性能关键的代码段，或者在循环中频繁push_back
的场景，是极大的优化。std::vector<int> my_vec; my_vec.reserve(1000); // 预先分配1000个int的空间 for (int i = 0; i < 1000; ++i) { my_vec.push_back(i); // 在此循环中不会发生重新分配 } shrink_to_fit()
： 如果vector
在完成所有元素添加后，其容量远大于实际元素数量（例如，先reserve
了很大一块，但只用了很小一部分），你可以调用vector.shrink_to_fit()
。这个函数会尝试减少vector
的容量，使其与当前元素数量尽可能匹配。但这只是一个“请求”，标准库实现不保证一定会成功，因为它可能涉及另一次内存重新分配（将元素移动到更小的内存块）。通常，它在释放多余内存方面很有用，但可能会带来一次性的性能开销。
虽然我们无法直接修改
std::vector内部的增长因子（这是标准库实现决定的），但通过
reserve()，我们能够有效地管理其内存分配行为，避免不必要的重新分配，从而显著提升程序的性能稳定性和效率。在实际开发中，养成预估并
reserve的好习惯，能省去不少性能调试的麻烦。
以上就是C++中std::vector扩容时内部是如何重新分配内存的的详细内容，更多请关注知识资源分享宝库其它相关文章！
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。