大量小型集合影响GC：迭代器、流与循环的对比优化

两种循环移除方案的内存开销对比 #

• 带索引修正的普通for循环：直接在原集合上操作，不需要额外创建任何临时集合存储待移除元素，完全没有额外对象实例化，内存开销是这几个方案里最低的，GC压力也最小。唯一需要注意的是移除元素后要把索引减1，避免跳过下一个元素，逻辑没问题的话，这个方案最贴合你降低内存的需求。
• 暂存待移除元素再批量删除：不管是在finally还是其他逻辑块存储待删元素，本质都要新建一个集合（比如ArrayList）来装载要删除的内容，这会额外产生对象实例，增加内存占用，反而加重GC负担，对比索引循环方案有明显劣势。

Stream/Spliterator方案的适用性 #

Stream API哪怕是串行模式，内部也会生成不少迭代辅助对象，并行模式还会增加线程调度的额外开销，完全不符合你降低实例化、减少GC的需求。Spliterator自定义开发成本高，而且同样会有内部对象创建，对于你提到的小型集合来说，效率和内存表现都不如普通索引循环，不建议优先考虑。

你可能遗漏的额外优化点 #

• 复用集合实例：如果这些小型集合是频繁创建销毁的，可以搞个简单的对象池复用集合，避免重复创建带来的GC。
• 换用primitive集合：如果集合里存的是基本类型（比如int、long），别用默认的ArrayList，换成Eclipse Collections或者Guava里的原始类型集合，避免自动装箱产生的包装对象，能大幅降低内存占用。
• 源头过滤：如果能在元素加入集合之前就过滤掉后续要移除的内容，从根源减少集合大小，省掉后面的迭代移除操作，这才是最彻底的优化。

内容的提问来源于stack exchange，提问作者Justin Pihony