std::vector因连续存储变长元素导致缓存行利用率低和跨行访问，而std::deque分段连续缓解该问题；alignas对齐使实际占用空间大于sizeof，致capacity计算错误；java arraylist扩容后gc需扫描全部引用槽；python list预分配策略造成内存冗余。
集合元素大小不一致时，std::vector 为啥比 std::deque 更容易触发缓存未命中
因为 std::vector 要求连续内存，当元素是变长结构（比如含 std::string 或指针的 struct）时，实际存储的是对象本体，而非统一尺寸的占位符。CPU 缓存行（通常是 64 字节）加载进来后，可能只用到其中几个字节，其余浪费；更糟的是，相邻元素跨缓存行边界，一次访问触发两次缓存加载。
- 实操建议：若集合中元素平均尺寸波动大（如
struct { int id; std::string name; }），优先考虑std::vector存指针 + 单独堆分配，或改用std::deque（分段连续，局部性稍差但避免单一大块内存的对齐拉扯） - 验证方法：用
perf stat -e cache-misses,cache-references对比两种容器遍历操作的缓存失效率 - 注意：
std::deque迭代器解引用不是 O(1) 指针偏移，而是两次间接寻址，小数据量时反而更慢
alignas 强制对齐后，std::vector<mystruct></mystruct> 的容量计算为何出错
编译器按 alignas(32) 对齐每个元素，但 std::vector 内部用 sizeof(MyStruct) 算偏移和容量，而实际占用空间是「对齐后尺寸」——即向上补齐到 32 的倍数。结果就是：分配了 N 个元素的空间，却因填充导致有效可用元素数少于 N。
- 常见错误现象：
v.capacity()返回 100，但v.data() + 100指向的位置已越界，因为每个元素占 32 字节，而sizeof(MyStruct)只有 28 - 使用场景：SIMD 向量化结构（如
struct alignas(32) Vec4f { float x,y,z,w; }）必须意识到对齐会吃掉额外空间 - 检查方式：打印
sizeof(MyStruct)和alignof(MyStruct)，二者不等时就要警惕填充膨胀
Java 的 ArrayList 和 Object[] 数组在 GC 压力下表现差异极大
Java 中 ArrayList 底层是 Object[]，但问题不在容器本身，而在元素类型。如果存的是 Integer、String 等对象引用，每次扩容都要复制整个引用数组；而引用本身虽小（8 字节），但 GC 需扫描每个槽位是否可达——大量空槽（null）或短命对象会让 G1/CMS 更频繁触发年轻代收集。
- 性能影响：100 万个
Integer的ArrayList，即使只用了 10 万个，扩容到 128 万容量后，GC 仍要扫描全部 128 万个引用槽 - 实操建议：明确知道元素数量上限时，用
new ArrayList(exactSize)避免多次扩容；极端场景可考虑int[]+ 自己封装逻辑，绕过装箱和引用扫描 - 容易踩的坑：用
Arrays.asList(new Integer[]{...})创建的列表底层是固定大小数组，add()会抛UnsupportedOperationException，但错误信息里不提内存布局问题
Python 的 list 在 append 大量小对象时，为什么 RSS 增长远超对象本身体积
CPython 的 list 预分配策略（over-allocation）是核心原因：每次扩容不是 +1，而是按公式 new_allocated = (size >> 3) + (size 增加额外槽位。这些空槽本身不存数据，但占着虚拟内存页（通常 4KB），且一旦被写入（哪怕只写一个元素），就计入 RSS（常驻集大小）。
- 常见错误现象：追加 100 万个
int，sys.getsizeof(list)显示约 8MB，但ps aux看 RSS 可能涨了 20MB+，因为背后映射了多个未完全使用的内存页 - 参数差异：该增长系数在 CPython 源码
Objects/listobject.c里硬编码，不可配置；PyPy 或其他实现策略不同 - 缓解办法：若已知最终大小，先
[None] * n预分配，再逐个赋值；或用array.array('i')存纯数值，内存紧凑且无指针开销
对齐和填充不是编译器“多此一举”，而是 CPU 访问硬件内存的硬约束。一旦结构体尺寸、容器策略、语言运行时三者没对齐（pun intended），性能损耗就藏在缓存行分裂、GC 扫描范围、RSS 虚高这些地方——它们不会报错，只会悄悄拖慢你最热的那条路径。
