17370845950

capacity() 返回 vector 底层已分配内存可容纳的元素个数，非已用数量；其值恒 ≥ size()，仅在 reserve、shrink_to_fit 或自动扩容时改变，删元素不缩容。

capacity 是 vector 底层已分配内存能存多少个元素

capacity() 返回的不是“用了多少”，而是“已经划好地、建好房、但还没住满的房间总数”。它代表 vector 当前持有的连续内存块，最多能容纳多少个 T 类型对象（不触发重新分配的前提下）。这个值和 size() 没有必然相等关系，但恒满足：capacity() >= size()。

常见错误现象：调用 pop_back() 或 clear() 后发现 capacity() 没变——这完全正常。vector 不会因删数据就自动缩容，因为频繁分配/释放内存比“多占点地方”代价更高。

• 扩容只发生在 push_back()、insert() 等插入操作导致 size() == capacity() 时
• 不同编译器策略不同：GCC 常按 1.5 倍增长，MSVC 常翻倍，都是为了摊薄扩容均摊成本
• capacity() 单位是“元素个数”，不是字节数；想知道实际内存占用，得算 capacity() * sizeof(T)

size 和 capacity 的行为差异在哪

size() 是你真正能遍历、访问、迭代的元素个数；capacity() 是底层 new T[N] 里那个 N。它们变化时机完全不同：

• size() 变：每次 push_back()、erase()、resize()、assign() 都会立即响应
• capacity() 变：仅在 reserve(n)（主动预留）、shrink_to_fit()（尝试收缩）、或自动扩容时改变
• clear() 后 size() 归零，capacity() 通常纹丝不动——这是有意为之的设计，方便复用容器

典型误用：用 for (int i = 0; i 遍历——结果是越界读未初始化内存，UB（未定义行为）。

什么时候该调用 reserve()，什么时候别乱 shrink_to_fit()

提前调用 reserve(n) 是性能优化中最简单有效的手段之一，尤其当你明确知道后续要塞入大量元素时（比如解析千行日志、加载图像像素、接收网络包）。

• 适用场景：vector 初始化后、循环 push_back() 前；或批量构造前预估总量
• 注意：reserve(n) 只影响 capacity()，不影响 size()，也不会初始化任何元素
• shrink_to_fi

  

  t() 是 C++11 引入的“请求”，不是命令——编译器可忽略；且它可能引发一次内存拷贝+释放，仅当确定后续长期不用大容量时才考虑
• 频繁调用 shrink_to_fit() 反而降低性能，就像反复搬家用纸箱装又拆

怎么一眼看出 capacity 是否成了瓶颈

最直接的办法是在关键路径前后打点看 capacity() 和 size() 的比值。如果 size() / capacity() 长期低于 0.3，说明内存浪费明显；如果在循环中观察到 capacity() 多次跳变（比如从 1→2→4→8），说明正在经历多次扩容。

一个轻量实操技巧：

std::vector v;
v.reserve(1000); // 先锁死容量
for (int i = 0; i < 1000; ++i) {
    v.push_back(i);
}
// 此时 capacity() == 1000，size() == 1000，零扩容开销

容易被忽略的一点：capacity 的“冗余”不是 bug，是 vector 为时间换空间做的权衡。强行消灭它，往往换来更差的局部性与更多 cache miss。