动态数组缩容需设低水位线（如0.25）、目标容量取size×1.5～2.0并设最小值、一次拷贝到位且清空旧引用，辅以冷却期或标记延迟防抖动。
动态数组（如 java 中的 arraylist）的核心在于“按需扩容”，但很多人忽略缩容——其实合理缩容能显著降低内存占用，尤其在频繁增删、数据量波动大的场景中。关键不是“要不要缩容”，而是“何时缩容、缩多少、如何避免反复缩容抖动”。
缩容触发时机：负载率阈值是核心
缩容不能等数组空了才做，也不能一删就缩。主流做法是设定一个**低水位线（low watermark）**，通常取加载因子的一半。例如扩容阈值是 0.75（即 size / capacity ≥ 0.75 时扩容），那么缩容阈值常设为 0.25 或 0.3 —— 当 size / capacity ≤ 0.25 时触发缩容。
- 太激进（如设 0.1）：容易刚缩完又因一次 add 就立刻扩容，形成“缩-扩-缩-扩”抖动
- 太保守（如设 0.5）：内存浪费明显，失去缩容意义
- 推荐实践：JDK 的
ArrayList实际不自动缩容；但自研或优化场景下，0.25 是平衡稳定性与内存效率的常用起点
缩容目标容量：宁可多留一点，拒绝频繁重分配
缩容不是简单减半（如 capacity = capacity / 2），而是要避开“临界抖动区”。假设当前 capacity=16，size=4（负载率 0.25），若直接缩到 8，下次 add 第 5 个元素时又触发扩容回 12 或 16，极易抖动。
- 安全策略：新容量 = max(默认初始容量, size × growthFactor)，growthFactor 建议取 1.5～2.0
- 示例：size=4，取 factor=2 → 新 capacity = max(10, 8) = 10；即使后续加到 9、10，也不立即扩容
- 补充：必须限制最小容量（如 10 或 16），防止过度收缩导致频繁新建小数组
缩容执行要点：一次到位 + 避免冗余复制
缩容本质是数组拷贝，开销不可忽视。务必确保只在真正必要时执行，并一步到位。
- 检查条件严格：仅当
size > 0 && size * 4 （即负载 ≤ 0.25）且 <code>capacity > MIN_CAPACITY才进入缩容流程 - 用
Arrays.copyOf(elementData, newCapacity)一次性完成，不要先 new 再循环 copy - 缩容后清空原数组引用（
elementData = null或新数组），协助 GC 回收旧空间（尤其大数组）
防抖动实战技巧：添加“缩容冷却期”或延迟策略
对于高频写入+随机删除的业务（如实时消息队列缓冲区），可引入轻量级防抖机制：
- 记录上次缩容时间戳，100ms 内不再缩容（适合事件驱动型系统）
- 改为“标记缩容”：只设置
pendingShrink = true，等到下次非增删操作（如遍历、get）时再真正执行 - 更彻底方案：改用分段式结构（如多个子数组），局部缩容不影响全局，但复杂度上升，按需选择
缩容不是锦上添花，而是内存敏感型服务的刚需。把握好阈值、目标容量和执行节奏，就能在节省内存的同时，稳住性能底线。
