trimtosize未立即减少内存是因为它仅重置elementdata引用而不触发gc，旧数组若被其他变量持有则无法回收；真正生效需确保列表构建完成且不再增长。
trimToSize 为什么没让内存立刻减少？
调用 trimToSize 后发现堆内存没明显下降，不是方法失效，而是它只修改了内部数组引用——把 elementData 指向一个刚好容纳当前元素的新数组，但原大数组若仍被其他变量间接持有（比如你之前用 toArray() 返回过、或传给了某个缓存结构），JVM 就不会回收它。
- 该方法不触发 GC，只是“释放引用”，真正回收取决于垃圾收集器何时扫描到旧数组已不可达
- 如果你在
ArrayList被长期持有（如静态缓存、单例容器）后才调用trimToSize，效果最明显；短生命周期对象几乎没必要调 - 注意：调用后
size()不变，capacity变为size，后续 add 会再次扩容（触发新数组分配）
什么场景下 trimToSize 真正值得调用？
不是所有缩减都划算，关键看「冗余是否持续存在且可观」。典型有效场景是批量构建后不再增删的只读集合。
- 从数据库查出 10 万条记录，用
new ArrayList(100000)预分配，但实际只加了 6 万——此时调用trimToSize可节省约 4 万个Object引用空间（约 32MB 堆内存，64 位 JVM） - 解析 JSON 或 XML 得到临时列表，之后转成 DTO 或写入文件，过程中不再修改——这时 trim 是低成本高收益操作
- 避免在循环里反复调用：比如一边 add 一边 trim，每次都会新建数组，性能反降
和 ensureCapacity + shrink 的区别在哪？
trimToSize 是唯一公开的「收缩」方法，但它的行为固定：只缩到 size。如果你需要缩到某个中间值（比如保留 2 倍冗余），就得手动处理。
-
ensureCapacity(minCapacity)只负责扩容，对已有容量无影响；它不能缩小 - 没有公开的
shrinkTo(int capacity)，想缩到非size值，只能反射访问elementData并赋值新数组（不推荐，破坏封装且 JDK 版本敏感） - JDK 21+ 的
SequencedCollection接口仍未提供收缩能力，所以trimToSize仍是标准路径
容易被忽略的线程安全与迭代器问题
调用 trimToSize 本身是线程安全的（只是改引用），但它和并发修改完全无关——如果其他线程正在遍历或修改这个 ArrayList，结果不可预测。
- 它不加锁，也不检查
modCount，所以和Iterator无协同；若在 foreach 中调用，很可能触发ConcurrentModificationException - 如果列表被多个模块共享，且某处缓存了
elementData（比如通过反射或 Unsafe 获取），trim 后那些缓存就指向了旧数组，数据不一致 - 序列化不受影响：
writeObject只序列化实际元素，不保存 capacity，所以 trim 前后反序列化结果一致
真正起作用的前提，是你清楚这个 ArrayList 的生命周期边界——它得是「构建完成、稳定使用、不再增长」的状态。否则，省下的那点内存，可能被频繁扩容的 CPU 开销和 GC 压力抵消掉。
