std::vector内存重新分配是“搬家”过程：先按增长策略计算新容量，分配新内存，用移动或拷贝构造函数迁移元素，销毁旧元素并释放内存。因需连续内存，无法原地扩容。迁移时优先用移动构造避免深拷贝，否则调用拷贝构造可能引发深拷贝。指数扩容保证摊销常数时间，但可能浪费内存或引起抖动。可通过reserve预分配内存避免频繁重分配，提升性能。
当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
中存储的是大型对象或数量庞大的元素时。
立即学习“C++免费学习笔记（深入）”；
为什么
std::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 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扩容时内部是如何重新分配内存的的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1473887.html
微信扫一扫 
支付宝扫一扫 
