Java集合框架中常见性能陷阱及优化
Java集合框架在日常开发中使用频繁，但若不注意使用方式，很容易引发性能问题。很多看似简单的操作背后可能隐藏着较高的时间或空间开销。了解这些常见陷阱并采取相应优化措施，能显著提升程序效率。
1. ArrayList 频繁扩容导致性能下降
ArrayList 内部基于数组实现，当元素数量超过当前容量时会触发自动扩容，扩容过程涉及创建新数组并复制原有数据，开销较大。
常见于未指定初始容量、持续添加大量元素的场景。例如循环中不断 add 元素，可能导致多次扩容。
优化建议：- 预估元素数量，构造时指定初始容量，如 new ArrayList(expectedSize)
- 若元素数量变化大且无法预估，考虑使用 LinkedList（但注意其随机访问性能较差）
2. HashMap 频繁哈希冲突与扩容
HashMap 在 put 操作时若发生哈希冲突，会以链表或红黑树形式存储，查找效率从 O(1) 下降到 O(n) 或 O(log n)。同时，负载因子触发扩容也会带来 rehash 开销。
默认初始容量为 16，负载因子 0.75，即超过 12 个元素就会扩容。
优化建议：- 根据数据量设置合理初始容量，避免频繁扩容，公式：expectedSize / 0.75 + 1
- 自定义对象作 key 时，正确重写 hashCode 和 equals 方法，减少哈希冲突
- 高并发场景下考虑使用 ConcurrentHashMap 替代 synchronizedMap
3. 使用 contains、remove 等方法遍历大集合
在 ArrayList 或 LinkedList 上调用 contains、remove(Object) 会进行线性扫描，时间复杂度为 O(n)，对大数据集影响明显。
例如判断某元素是否存在，使用 List 逐个比较效率低下。
优化建议：- 需要频繁查询存在性时，优先使用 HashSet 或 LinkedHashSet，时间复杂度接近 O(1)
- 若需保持插入顺序，可结合 LinkedHashSet 使用
- 已
排序列表可改用 Collections.binarySearch，前提是必须有序且支持随机访问
排序列表可改用 Collections.binarySearch，前提是必须有序且支持随机访问4. 迭代过程中修改集合引发异常或低效
直接在 foreach 循环中调用集合的 remove 或 add 方法，会抛出 ConcurrentModificationException。
常见修复方式是使用 Iterator.remove()，但若逻辑复杂，仍可能因意外修改导致问题。
优化建议：- 遍历时删除元素，使用 Iterator 显式迭代并调用其 remove 方法
- 可先将待删除元素放入临时集合，遍历结束后再批量删除
- 高并发环境下使用 CopyOnWriteArrayList，适合读多写少场景
