java大数据量集合调优核心是预分配容量、避免冗余复制、匹配数据规模：arraylist需预设容量防扩容；hashmap按公式计算初始容量并重写hashcode/equals；linkedlist因内存开销大、随机访问慢，大数据量下通常不推荐。
Java 基础集合类在大数据量场景下性能调优，核心是减少对象创建、避免冗余复制、匹配真实数据规模，并与 JVM 内存模型协同。不是堆得越大越好，而是让每次分配都“刚刚好”。
ArrayList：预设容量比默认构造更关键
它底层是数组，扩容时要新建数组 + 全量复制旧数据，这会生成大量短期对象，加重年轻代压力。默认构造（容量10）在插入百万级元素时可能触发十几次扩容。
- 已知元素数量 n，直接用 new ArrayList(n) —— 内部数组长度就是 n，零扩容
- 不确定精确值但有上限，创建后立刻调用 ensureCapacity(n)，强制一次到位
- 避免在循环中反复 add 后再 trimToSize()，那只是“事后打扫”，不如事前规划
HashMap：按公式算初始容量，别信默认16
默认初始容量 16、负载因子 0.75，意味着只放 12 个键值对就扩容。处理 100 万条记录时，若不干预，会经历多次 rehash，每次都要重建哈希桶、重散列全部 Entry。
- 用公式计算：(int) Math.ceil(expectedSize / 0.75)，再向上取最接近的 2 的幂（如 1333334 → 2097152）
- 构造时传入该值：new HashMap(2097152)
- 如果 key 是自定义对象，务必重写 hashCode() 和 equals()，否则哈希分布不均，链表过长，退化为 O(n) 查找
LinkedList：大数据量下通常不推荐
它没有数组扩容问题，但每个元素都是独立 Node 对象（含前后指针），内存开销是 ArrayList 的 3 倍以上；随机访问需遍历，get(i) 在百万级数据中可能耗时数十毫秒。
- 仅在频繁首尾增删、且完全不依赖索引访问时才考虑
- 替代方案：用 ArrayList + 批量 addAll，或用 ArrayDeque 做栈/队列操作
- 不要因为“听说它不扩容”就误用——扩容代价 ≠ 总体代价
Set 和 Queue 类型：按语义选，不盲目替换
HashSet 底层是 HashMap，优化方式同上；TreeSet 基于红黑树，插入/查找是 O(log n)，大数据量下明显慢于 HashSet，仅当需要自动排序或范围查询时选用。
- 去重优先用 HashSet，别用 List.contains() 模拟，后者是 O(n²)
- 需要先进先出且高吞吐，ArrayDeque 比 LinkedList 快得多（连续内存 + 无同步开销）
- 并发场景慎用 Collections.synchronizedList，优先考虑 CopyOnWriteArrayList（读多写少）或 ConcurrentHashMap
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
