C++ vector扩容机制原理 _ capacity与reserve函数优化【详解】

C++ vector 扩容机制：capacity 与 reserve 的正确打开方式

先直接说结论：capacity 是 vector 当前“能装多少”的容量上限，reserve 则是你主动告诉它“我要装这么多，现在就分配好内存”。两者配合得当，能避免 90% 的隐式扩容开销。下面这张图能帮你快速建立直观印象：

capacity() 返回的是什么，为什么它不等于 size()

capacity() 返回的是当前已分配但尚未使用的内存空间能容纳的元素个数；size() 才是实际有多少个元素。二者之间这个差值，就是“空着但已付费的房间”——vector 为了后续扩容提前预留的余量。

常见的一些让人困惑的现象：

• 打印 vec.size() 是 100，vec.capacity() 却是 128 —— 这不是 bug，是几何扩容留下的缓冲空间
• 调用 clear() 后 size() 变 0，但 capacity() 不变 —— 内存没还，只是清空了内容
• 用 resize(50) 缩小容器，capacity() 可能不变甚至变大（具体取决于实现）

reserve(n) 什么时候真正起作用

reserve(n) 只在 n > capacity() 时触发内存重分配；否则什么也不做。它不构造对象、不改变 size()，纯粹是“提前租好整层楼”。

典型的使用场景：

• 已知要 push_back 10 万条日志，提前 vec.reserve(100000)
• 从文件读取 N 行，且 N 可通过 std::filesystem::file_size() 预估
• 函数返回 vector 但内部需多次拼接，入口处统一 reserve

容易踩的坑：

• reserve(0) 或 reserve(vec.size()) 没效果，别白调
• 对空 vector 调用 reserve(1)，capacity 变成 1；但再 push_back 第二个元素仍会扩容（因为 capacity=1，size=1，push_back 触发扩容）
• MSVC 和 GCC 的扩容因子不同（1.5 vs 2），跨平台项目别硬编码“刚好够用”的 reserve 值

扩容时到底发生了什么，为什么慢

当 size() == capacity() 且调用 push_back 时，vector 必须执行三步原子操作：

• 调用 allocator 分配一块新内存（大小 = max(new_size, current_capacity * growth_factor)）
• 逐个移动或拷贝旧元素到新地址（C++11 后优先 move，但要求 move 构造 noexcept）
• 析构旧元素并释放原内存块

性能影响：

• 元素类型越复杂（比如含 std::string 成员的类），拷贝/移动成本越高
• 频繁扩容会导致内存碎片，尤其在长期运行的服务中
• 所有指向旧内存的迭代器、指针、引用全部失效 —— 比如 auto it = vec.begin(); vec.reserve(1000); *it 就是未定义行为

reserve 和 resize 的关键区别不能混用

reserve(n) 改变的是 capacity()，不影响 size()；resize(n) 改变的是 size()，可能顺带改 capacity()（如果 n > 当前 capacity）。

典型误用：

• 想初始化 1000 个默认构造对象，却写了 vec.reserve(1000) —— 错，size() 还是 0，访问 vec[0] 直接崩溃
• 正确做法是 vec.resize(1000)，或 vec.reserve(1000); vec.assign(1000, T{})
• 想清空并释放内存？vec.clear(); vec.shrink_to_fit(); —— 注意 shrink_to_fit 是请求，不保证成功

最易被忽略的一点：reserve 对 vector 无效 —— 它是特化模板，底层用位存储，capacity() 和内存布局都不遵循通用规则。