trimToSize() 仅在 elementData 容量显著大于 size 时才有效释放内存，它通过缩容数组长度至 size 来减少堆占用，但不触发 GC；clear() 后需手动调用才释放冗余空间。
trimToSize() 什么时候真正释放内存
trimToSize() 不会立即触发 GC，它只做一件事：把 ArrayList 内部的 elementData 数组长度从当前容量（capacity）缩到实际元素个数（size）。只有当原数组明显大于 size（比如 add 了 1000 个元素后又 removeAll），调用它才可能让 JVM 回收那块多余数组内存。
常见误判是以为“只要调用了就省内存”——其实如果 size 和 capacity 差距很小（例如 capacity=16、size=15），缩容后数组只少一个元素，基本没意义。
- 只在明确知道后续不会再添加大量新元素时才值得调用
- 适合用在“一次性构建+只读遍历”的场景，比如解析配置后生成固定列表
- 频繁增删的列表上反复调用反而增加开销（每次都要新建数组并复制）
为什么 clear() 后不自动 trim，必须手动调用
clear() 只把所有元素设为 null 并重置 size = 0，但 elementData 数组本身引用没变，容量 remain unchanged。JVM 无法判断你是否打算复用这个大数组，所以不会主动缩容。
典型错误写法：
立即学习“Java免费学习笔记（深入）”；
list.clear(); // size=0，但 elementData.length 还是原来的 1000 // 此时 list 占用的堆内存几乎没变
正确做法：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
list.clear(); list.trimToSize(); // elementData 被替换为 new Object[0]
- 如果之后要复用该列表，别 trim——否则下次 add 又要扩容，徒增复制成本
- 如果确定不再使用，且希望尽快释放内存，clear + trimToSize 是必要组合
- 注意：trimToSize() 对空列表（size=0）会把数组缩成长度为 0 的数组，不是 null
和 ensureCapacity() / ensureCapacityExact() 的关系
trimToSize() 是“收缩”，而 ensureCapacity() 系列是“预留”。它们作用方向相反，但共享同一底层机制：都通过 Arrays.copyOf() 创建新数组并复制元素。
容易踩的坑：
- 先调
ensureCapacity(1000)预分配，再 add 10 个元素，最后trimToSize()—— 这是合理操作 - 但在循环里每 add 一次就 trim 一次，等于每次都在新建数组，性能暴跌
-
ensureCapacityExact()（Java 22+）严格按需分配，不向上取整；老版本ensureCapacity()会按增长策略（如 1.5 倍）扩容，导致 capacity > 请求值
所以 trim 的收益，取决于你之前是否过度预分配过。
替代方案：用 LinkedList 或不可变集合更省心？
如果目标只是避免冗余数组空间，LinkedList 确实没有“容量”概念，每个元素独立对象，但代价是：指针开销翻倍、缓存不友好、随机访问 O(n)。除非你只做头尾增删，否则通常不如 ArrayList + 合理 trim。
更现代的选择是用 List.copyOf()（Java 10+）或 ImmutableList.of()（Guava）构造不可变列表：
List<String> fixed = List.copyOf(originalList); // 底层数组长度 == size
- 天然无冗余容量，且线程安全
- 适合配置项、枚举集合等静态数据
- 但一旦创建就不能修改——不能替代需要动态增删的 ArrayList
trimToSize() 的价值不在“绝对最优”，而在对可变列表做轻量级内存整形：不改接口、不换结构、只削掉一眼可见的浪费。
