trimToSize 有效但不立即释放物理内存，仅缩容内部数组；仅在长期只读、大幅缩容后才值得调用，优先通过预估容量避免过度扩容。

ArrayList.trimToSize 为什么经常没效果

调用 trimToSize 后内存没明显下降，不是方法失效，而是 JVM 并不立即回收堆内存——它只是把内部数组（elementData）长度缩到当前 size，释放的是「数组对象自身占用的引用空间」，而非触发 GC。真正释放物理内存取决于垃圾收集器何时回收旧数组。

常见误判场景：用 Runtime.getRuntime().freeMemory() 对比前后值，但该值受 GC 状态、其他对象分配干扰极大，不能作为 trim 效果依据。

什么情况下 trimToSize 才值得调用

只有当 ArrayList 经历过大幅扩容又长期只保留少量元素（比如初始化容量为 1000，最终只存 5 个），且该列表生命周期较长、后续不再增删时，才适合 trim。否则频繁 add/remove 会反复触发扩容/缩容，反而增加开销。

• 批量构建后只读的缓存列表（如配置项加载、静态数据预处理）
• 从数据库查出大量记录后做筛选，最终结果远小于原始集合
• 明确知道后续不会再修改，且对象驻留时间长（如 Spring Bean 中的成员变量）

手动 trim 比自动更可靠，但要注意时机

trimToSize 是 public 方法，但 ArrayList 不会在任何内置操作（如 remove、clear）中自动调用它。你必须显式触发，且最好在确认「不会再增删」之后立刻执行。

示例：

List<string> data = new ArrayList(2048);
// ... 大量 add
data.retainAll(needList); // 筛选后只剩几十个
data.trimToSize(); // ✅ 此刻调用才有效
</string>

注意：clear() 只置空元素引用，不缩容；new ArrayList(oldList) 会创建最小容量新实例，但多一次拷贝，不如原地 trimToSize 轻量。

替代方案：初始化时就控制容量

比起事后 trim，更高效的做法是避免过度扩容。如果元素数量可预估，直接传入合理初始容量：

• 已知要存约 300 条日志 → 用 new ArrayList(384)（避开 256→512 的翻倍）
• 从 Collection 构造 → 优先用 new ArrayList(collection)，它会按 collection.size() 初始化容量
• 流式构建 → list = list.stream().filter(...).collect(Collectors.toCollection(() -> new ArrayList(estimatedSize)))

过度依赖 trimToSize 容易掩盖容量估算缺失的问题——它是个补救手段，不是内存管理主力。