前几天同事来找我看一个线上接口的耗时问题逻辑明明不复杂可数据量一上来响应时间就从几十毫秒直接跳到几秒。我把代码翻了一遍发现他在循环里用 LinkedList 频繁 get 索引、HashMap 没给初始容量、还顺手在遍历的时候用集合的 remove 删元素——三个典型的集合框架用法问题叠在一起性能自然被压垮。改完之后同样的压测数据下耗时直接降了一个数量级。这类问题在 Java 项目里太常见了而且几乎全跟集合框架、工具类和性能优化这三个词绑定在一起。很多人能写出能跑的代码但离快而稳还有距离。这篇博文不讲虚的直接围绕容器选型、Collections 与 Arrays 工具类的正确姿势以及容量、哈希、并发等性能优化关键点展开最后再拆一个从线上告警到根因定位的完整案例。不管你是刚接触 Java 集合框架不久的新人还是写了两三年业务代码想系统梳理一遍的开发者这都可以当作一份实战笔记来参考。1. 集合选型决定性能上限ArrayList、LinkedList、HashMap 的真实差异1.1 List 家族数组与链表的本质区别很多人纠结 ArrayList 和 LinkedList 该选哪个。从数据结构层面看ArrayList 底层就是 Object[] 数组数组在内存里是一段连续空间所以按索引访问是 O(1)而 LinkedList 每个节点还要额外存前驱和后继指针头尾操作很快但中间插入需要先寻址到目标位置反而是 O(n)。这里有个反直觉的点现实中 LinkedList 往往并不比 ArrayList 快。现代 CPU 对连续内存的缓存非常友好ArrayList 在遍历和批量操作上占尽优势LinkedList 的节点在堆里分散每次访问都可能触发缓存未命中。加上每个节点多存两个引用在 8GB 内存的机器上放 100 万个 Integer 对象LinkedList 的额外开销可能就有几百 MB。Java 里 LinkedList 的实际地位挺尴尬的除了特定场景下的双端队列需求可以用 ArrayDeque 替代大多数情况下直接用 ArrayList 更省心。我在项目里踩过不少坑之后总结出一个选型判断方式如果操作以尾插 随机读为主选 ArrayList如果确实需要频繁在头尾插入且中间操作极少用 ArrayDeque中间插入真的很多才考虑链表结构而且最好结合分块、分段的数据结构思路重新设计而不是直接套 LinkedList。记住一个原则数据结构选错了后面的工具类用得再顺也弥补不了算法层面的差距。1.2 HashMap 的两层世界哈希与树化HashMap 是集合框架里最常被问到的容器。JDK 8 以后的实现是数组 链表 红黑树key 经过 hash 后定位到一个桶如果多个 key 撞到同一个桶就用链表串起来当某个桶的链表长度达到 8 且总容量大于 64 时链表会升级成红黑树把冲突时的查找从 O(n) 压缩到 O(log n)。这个细节直接关系到你的性能当 key 的 hashCode 设计得稀烂时HashMap 会退化成一个超长链表插入和查询统统变成线性扫描。还有一点很多人忽略HashMap 判断两个 key 是否相同先比 hashCode再比 equals。所以自定义对象作为 key 时这两个方法必须同时重写而且不要用可变字段参与 hashCode 计算。我有一次排查数据丢失问题最终定位就是有人把 ArrayList 当 key随后又修改了 list 里的元素导致 hashCode 变了已存入的条目再也 get 不到。这种问题隐蔽性很高因为不报错只是数据消失。1.3 动手之前的选型对照实战中我会把选择做成一张对照表每次写容器之前先在心里过一遍业务场景推荐容器原因一句话按索引读取、尾插为主ArrayList连续内存、缓存友好随机访问 O(1)双向队列、头尾操作频繁ArrayDeque无节点指针开销性能稳定根据 key 快速查 valueHashMap平均 O(1)JDK 8 后有树化兜底需要记录插入顺序LinkedHashMap额外维护双向链表可做 LRU 缓存需要 key 有序遍历TreeMap红黑树O(log n)高并发读多写少CopyOnWriteArrayList / ConcurrentHashMap读写分离或分段思想全程只读的常量配置List.of / Map.of / unmodifiableXxx不可变天然线程安全表里的内容看着简单但真的决定性能上限。因为选错容器导致的性能问题往往不是靠调参能救回来的只能重构。这也是我把选型放在最前面的原因。2. Collections 工具类排序、不可变与线程安全的正确用法2.1 排序不只是 sort 那么简单java.util.Collections 是我觉得最被低估的工具类。先说排序。Collections.sort 在 JDK 8 以后内部就是调用 list.sort底层是 TimSort一种稳定、适应性强的混合排序算法。稳定意味着相同元素的相对顺序不会被打破当你需要先按时间排再按优先级排这种多级排序时稳定性非常重要。自定义排序时要注意 Comparator 的传递性。我见过很多人写list.sort((a, b) - a.getScore() b.getScore() ? 1 : a.getScore() b.getScore() ? -1 : 0);这种写法在大部分数据下没问题但如果比较规则里出现自相矛盾JVM 在检测到比较契约违反时会直接抛 IllegalArgumentException: Comparison method violates its general contract!。正确的做法是用 Integer.compare 或 Comparator.comparing 这类标准方法让比较器逻辑线性化list.sort(Comparator.comparing(User::getScore).reversed().thenComparing(User::getAge));这里的重点不是背 API而是理解为什么TimSort 依赖比较器的传递性来保证归并时能正确合并你一旦破坏了契约算法行为就变成未定义严重时直接报错。这是工具类里最常见的隐形坑之一。2.2 线程安全包装与真正的不可变另一个高频用法是 Collections.synchronizedList。它返回的对象做所有方法时都会加锁但这里有一个很大的误区它只保证单个方法原子不保证复合操作安全。比如经典的先判断再添加if (!list.contains(item)) { list.add(item); }在 synchronizedList 上依然不是线程安全的因为 contains 和 add 是两个独立加锁步骤中间可能被其他线程插入。正确做法是自己在外面包裹一个 synchronized 块。同理迭代也需要手动加锁因为 hasNext / next 是逐个调用的。相比之下不可变集合更值得推荐。Collections.unmodifiableList 或者 Java 9 以后的 List.of一旦创建就不能再修改天然线程安全也不用担心别人在你不知情的情况下改了集合内容。我处理系统配置、路由表、白名单这类只读数据时一律用不可变集合。要注意的是unmodifiableList 是视图级不可变如果里面装的是可变对象对象本身仍可被修改而 List.of 则更进一步连 null 都不允许存放。对依赖集合内容做判空校验的代码来说这一点要认真测试。2.3 空集合、单元素集合与批量填充Collections.emptyList()、emptyMap()、singletonList() 这些看着不起眼的 API 有独特价值。emptyList 复用了同一个不可变实例不会每次 new 一个新对象在返回值为空的场景里返回 emptyList 而不是 null能省掉调用方一大堆判空代码。singletonList 则适合传参给只读接口的场景比如一个方法签名要求 List 但实际上只有一个 id 时。批量填充推荐 Collections.addAll(collection, elements...)它内部对 ArrayList 等做了预扩容优化比循环里逐个 add 要快。还有 Collections.fill 可以把整个列表填充为同一个对象适合批量初始化的场景。平时我用 Collections.sort 和 addAll 多一些但有一些接口在特定场景下非常有用Collections.reverse原地逆置列表做倒序展示时一行解决。Collections.rotate(list, distance)把列表整体循环右移我做过一次轮播卡片数据的循环展示用它实现很优雅。Collections.frequency统计指定元素出现次数排查重复数据时很方便。Collections.max / min按自然顺序或自定义比较器取最大最小值省去手写流式归约。这些 API 的共性就是把最常见的集合操作封装成一个调用用对之后代码量会明显减少而且不容易出错。3. Arrays 工具类数组与集合互转时的坑与妙用3.1 asList 的真相它不是 ArrayListArrays.asList 是数组转集合最常用的方法但它返回的对象的 class 是 java.util.Arrays$ArrayList而不是 java.util.ArrayList。两者的关键区别在于Arrays$ArrayList 直接以原数组作为存储结构定死不能增删元素而且修改集合元素原数组会跟着变反过来也一样。这个现象的本质是视图而不是拷贝。所以这样写一定报错ListString list Arrays.asList(a, b, c); list.add(d); // UnsupportedOperationException如果你只是想把数组当成只读集合来遍历、查找那直接用 asList 没问题但如果后面还要 add/remove、或者不希望影响原数组就做一个真正的副本ListString list new ArrayList(Arrays.asList(arr));这里还有个相关坑用 List.of 创建的集合也是不可变且不能有 null行为跟 asList 不完全一样。很多人从 asList 转到 List.of 时为了少写代码结果忘了 List.of 不接受 null参数里混入 null 会抛 NullPointerException。工具类之间的细微差异恰恰是最容易出 bug 的地方。3.2 二分查找与数组拷贝的边界Arrays.binarySearch 要求数组必须有序这一点是常识但很多人不知道未找到时返回值的含义返回的是 -(插入点) - 1。插入点被定义为第一个大于目标值的元素下标如果所有元素都小于目标插入点就是数组长度。利用这个规律你可以轻松算出元素应该插在哪int idx Arrays.binarySearch(arr, target); if (idx 0) { int insertPos -idx - 1; }这个负值返回设计很巧妙既表示没找到又给出了下一步插入的位置。搜索超大数组时也可以用 Arrays.binarySearch 的泛型重载配合自定义比较器。数组拷贝方面Arrays.copyOf / copyOfRange 比手写 System.arraycopy 安全得多。copyOf 会自动处理扩容和越界如果新长度大于原长度多出来的位置填充默认值copyOfRange 当 from to 时会抛 IllegalArgumentException当 to 超过原数组末尾时同样补默认值。在实现自定义动态数组、或者做快照拷贝时可以省心不少。3.3 容易被忽略的高价值方法有几个 Arrays 的成员很冷门但实际价值极高Arrays.parallelPrefix并行前缀计算。给定二元运算把数组变成累计序列。比如 {1,2,3,4,5} 配合 Integer::sum 会得到 {1,3,6,10,15}。在做累计统计、前缀和场景比如连续 N 个窗口的销售额累计时会非常方便数据量大时并行计算优势明显。Arrays.deepEquals / deepToString用于多维数组。普通的 equals/toString 在一维数组内部元素也是数组时只会比较引用、打印地址deep 版本才会逐层展开。我在给报表数据做断言比对时deepEquals 一个方法能省掉几行手写递归。Arrays.setAll / parallelSetAll根据下标或随机规则批量赋值比在循环里挨个赋值更声明式。例如int[] arr new int[100]; Arrays.setAll(arr, i - i * i);一条语句完成初始化。这些都是知道就能省时间、不知道就会重新造轮子的方法。工具类的价值就在这它不只是帮你写更少代码关键在于踩坑概率也随之降低了。4. 性能优化实战容量、哈希与并发场景的逐项调优4.1 初始容量与负载因子大集合必须提前规划HashMap 默认初始容量 16负载因子 0.75。当元素数量超过容量 × 负载因子时触发扩容而扩容的代价是把所有节点重新算 hash、重新分布桶。这个成本在数据量大时很可观。所以要提前预估数据量int expectedSize 100_000; MapString, Integer map new HashMap(expectedSize);严格来说想避免扩容需要 capacity expectedSize / loadFactor所以很多人用 expectedSize / 0.75 1 来算初始容量。HashMap 还会把传入容量调整成 2 的幂所以实际传入的数值会向上取整。这个公式不需要死记只要记住new HashMap(n) 并不是装 n 个就够预留 25% 以上的余量效果最好。ArrayList 同理。默认容量 10扩容时按 1.5 倍复制数组到新数组。如果知道大概的数据量构造时就给足容量能显著减少复制数组的次数。我在往内存缓存里灌几百万行配置时通常是这样写ListConfig configs new ArrayList(expectedSize);这里的关键是预估不是精确。就算预估值偏差 20%也比默认容量反复扩容好得多。尤其是在高频调用路径上创建集合时初始容量往往是性价比最高的优化。4.2 并发集合怎么选三个常用方案的取舍并发场景永远绕不开集合。先说最容易被滥用的 Collections.synchronizedList它是把所有方法用 synchronized 包起来任何操作都要抢同一把锁并发一高就是典型的锁竞争瓶颈。它的适用场景其实是低冲突下的简单线程安全并发读写都频繁时不推荐。ConcurrentHashMap 是 HashMap 的并发增强版。JDK 8 后摒弃了分段锁改用 CAS 配合 synchronized 锁桶。它的 get 完全无锁put 时只会锁住对应桶的链表头或树根天然支持并发读与并发写。默认情况下 size()、isEmpty() 这类聚合操作是近似值这一点官方文档也说明过所以不要依赖精确结果。做计数器、缓存、会话表时这个类是首选。CopyOnWriteArrayList 的核心思想是写时复制每次 add/set 都会创建一个新数组然后整体替换引用读操作不加锁永远读到旧数组或新数组。这个机制决定了它是读多写极少场景的王者比如一个每小时才更新一次的规则列表但每秒有几千次查询。如果写入频繁频繁复制整个数组反而会成为性能杀手。选型建议一句话总结并发读多且写少、内容偏只读用 CopyOnWriteArrayList读写都密集的快查数据结构用 ConcurrentHashMap对并发要求不高但偶尔需要简单保护才用 synchronizedCollection 系。4.3 自动装箱与流式操作隐藏在语法糖下的开销遍历细节也要留意。for-each 循环在底层会创建 iteratorArrayList 还好LinkedList 的迭代器在每次 next 时也要移动指针。更普遍的问题是自动装箱当 ListInteger 与 int 值互相转换时JVM 会不停创建 Integer 对象。这种开销在几万次的循环里不明显一旦到了千万级数据规模GC 压力就上来了。Stream 也有类似问题但 Stream 真正要警惕的是把整个数据管道改成 parallelStream 后共享了可变状态比如ListInteger result new ArrayList(); list.parallelStream().forEach(item - result.add(item));这是在并发修改一个 ArrayList轻则数据缺失重则直接 ConcurrentModificationException。并行流适合纯函数式、无共享可变状态的计算如果非要用并行流产出结果请老老实实 collect 返回值ListInteger result list.parallelStream() .map(Item::getValue) .collect(Collectors.toList());一句话语法糖只是让代码好看底层该有的并发意识和对象成本一点都不能少。4.4 实测对比一组我自己跑过的数据理论说再多容易显得空。我简单做过一个对比实验往两个 List 尾部插入 50 万个随机数再随机提取 10 万次索引访问。同一台机器上ArrayList 插入约 12ms索引访问约 3msLinkedList 插入约 18ms索引访问约 1200ms。头部插入的话 LinkedList 会快一些但日常业务里随机读 尾插的组合太常见了这个数量级差异足以证明选型的重要性。HashMap 我分别用默认容量和 64 万初始容量各插入 50 万条记录前者多次扩容后耗时约 650ms后者约 280ms差距同样可观。注意这种手写计时并不严谨缺少 JIT 预热和多次取均值看数量级就够了。真要严格对比用 JMH 做基准测试把 warmup 和 iteration 次数配好结果才有说服力。5. 集合框架的隐形地雷一次从线上告警到根因的完整排查5.1 地雷之一subList 的视图陷阱List.subList 返回的是视图不是副本。对 subList 的修改会直接反映到原列表上反过来也一样。更隐蔽的是一旦原列表的结构发生变化比如 add 或 remove之前拿到的 subList 就会失效再次操作时抛 ConcurrentModificationException。我见过一个很典型的错误用 subList 做分页截取后随手往截出来的那部分里加数据结果业务上数据全污染到了原列表。修复其实就一行ListString page new ArrayList(list.subList(from, to));记住subList 适合做只读切片和区间操作不适合截断了再独立使用。5.2 地雷之二遍历时修改集合的根因与三个解法ConcurrentModificationException 的根源是 modCount。集合每次结构变化都会递增这个计数器迭代器在创建时记录 expectedModCount每次 next 都检查两者是否一致不一致就抛异常。所以一边 for-each 一边 remove必炸for (String item : list) { if (item.startsWith(temp)) { list.remove(item); // 触发 ConcurrentModificationException } }三个标准解法用 Iterator 的 remove它会同步更新 expectedModCount。用 Java 8 的 removeIf语义清晰list.removeIf(item - item.startsWith(temp))。先收集要删的元素遍历结束后统一 removeAll。这三种我都实测过removeIf 的代码量最少而且内部用了 fast-fail 机制是最推荐的做法。但要提醒如果集合本身是并发容器比如 CopyOnWriteArrayList虽然迭代时不会抛异常但也要注意迭代器不反映新加的元素这是另一个语义陷阱。5.3 完整排查链路一个真实案例的拆解最后复盘一个我实际遇到的线上问题。现象某个接口在高峰期偶尔返回 500日志里出现 ConcurrentModificationException每天触发两三次单独复现时又一切正常。排查第一步看堆栈。报错指向一个定时任务里的 for-each 循环循环内部调用了 list.remove。第二步翻代码发现这个 list 是全局缓存对象定时任务每天凌晨会更新一次而白天有多个请求线程在同一份缓存里做条件删除。第三步确认为什么偶发——remove 恰好发生在迭代器活动期间才抛出大多数时候迭代很快结束所以概率低但线上请求量大小概率事件每天也能被撞击出来。修复方案其实有两层。第一层是应急的把循环内的 remove 改成 removeIf让删除动作和迭代器的安全检查兼容。第二层是根因的把缓存类型从 ArrayList 换成 CopyOnWriteArrayList。因为这个数据的本质就是每天更新一次、全天被读上万次CopyOnWriteArrayList 正是为此设计的。改完之后告警连续两周没有出现。这个案例给我最大的启发是集合框架的 bug 往往不是算法跑不通而是数据结构与使用场景不匹配。工具类和容器本身都是中性的关键在于你有没有想清楚这个 list 是谁在写、谁在读、写多还是读多、允许不允许结构变化。把这些想清楚了Java 集合框架不但不会拖后腿反而会成为你构建高性能服务最趁手的底座。