1. 为什么 Collections 工具类值得单独拎出来讲1.1 从一道面试题说起面试里问Collections很多人第一反应是“不就是个工具类吗sort、reverse、shuffle那几个方法”。但真正拉开差距的地方在于面试官往往不是考你会不会调 API而是考你知不知道Collections和Collection的区别、synchronizedList和CopyOnWriteArrayList的取舍、unmodifiableList到底“不可变”到什么程度、sort底层用的什么排序、binarySearch为什么必须先排序。我自己带过几轮面试也被人面试过。一个很典型的场景是候选人能背出Collections.sort(list)的用法但当我追问“如果这个 list 是Arrays.asList()返回的能不能排序”十个人里有六七个会卡住。再追问“Collections.unmodifiableList包一层之后原 list 改了会怎样”能答对的更少。所以这篇东西不是一份 API 手册而是把Collections这个类里真正容易踩坑、面试高频、生产环境也真会用到的点一条一条拆开讲清楚。适合正在准备面试的同学也适合写了几年业务代码、但对集合工具类只停留在“会用”层面的开发者。1.2 Collections 和 Collection 到底差在哪先把最容易混淆的一对概念钉死。Collection是接口是List、Set、Queue这些单列集合的顶层父接口它定义的是“一个集合该有什么行为”——add、remove、size、iterator这些。Collections是类位于java.util包下是一个纯粹的工具类构造函数被私有化你没法new它。它里面全是static方法作用是对集合进行“操作”或“包装”。一句话记Collection是“是什么”Collections是“能对它做什么”。面试里如果连这个都说不清基本就凉了一半。Collections的方法大致可以分成这么几类我按使用频率和面试频率排一下分类代表方法面试频率排序与查找sort、binarySearch、reverse、shuffle极高最值max、min中线程安全包装synchronizedList、synchronizedMap、synchronizedSet极高不可变包装unmodifiableList、unmodifiableMap高空集合emptyList、emptyMap、emptySet中单元素集合singletonList、singleton中批量操作addAll、fill、copy、replaceAll中类型检查checkedList、checkedMap低频率统计frequency、disjoint低这张表建议先有个印象下面逐个展开。2. 排序与查找sort 和 binarySearch 的隐藏考点2.1 Collections.sort 底层到底怎么排的Collections.sort(ListT list)这个方法很多人以为它自己实现了一套排序算法。实际上它的实现是这样的public static T extends Comparable? super T void sort(ListT list) { list.sort(null); }它把活直接甩给了List接口的sort默认方法。而List.sort的默认实现是default void sort(Comparator? super E c) { Object[] a this.toArray(); Arrays.sort(a, (Comparator) c); ListIteratorE i this.listIterator(); for (Object e : a) { i.next(); i.set((E) e); } }也就是说先把 list 转成数组用Arrays.sort排好再通过ListIterator一个个写回去。这里有个关键点Arrays.sort对对象数组用的是TimSort归并排序的优化版本时间复杂度稳定在 O(n log n)而且是稳定排序。为什么强调“稳定”因为面试官很爱问“Collections.sort是稳定排序吗”答案是稳定的。稳定意味着相等元素的相对顺序不会被打乱。比如你有一个按年龄排好的列表再按姓名排一次同姓名的人年龄顺序还是保持的。那如果我想降序怎么办两种写法// 写法一传自定义 Comparator Collections.sort(list, (a, b) - b.compareTo(a)); // 写法二用 reverseOrder Collections.sort(list, Collections.reverseOrder());Collections.reverseOrder()返回一个反转自然顺序的比较器这个在面试里也常被问到因为它内部其实是对Comparable做了个包装把compareTo的参数顺序调换。2.2 一个高频陷阱Arrays.asList 返回的 list 不能排序这是我自己踩过的坑也是面试里区分度很高的一题。ListInteger list Arrays.asList(3, 1, 2); Collections.sort(list); // 抛 UnsupportedOperationException为什么因为Arrays.asList返回的是Arrays内部的ArrayList注意不是java.util.ArrayList它底层直接引用原数组不支持结构性修改。sort方法里调用了ListIterator.set()而这个内部类没有重写set所以直接抛异常。那怎么破包一层ListInteger list new ArrayList(Arrays.asList(3, 1, 2)); Collections.sort(list); // 正常这个点面试官特别爱问因为它同时考了Arrays.asList的语义、ListIterator的行为、以及“结构性修改”和“非结构性修改”的区别。set属于非结构性修改不改变长度但Arrays内部类连set都不支持所以照样炸。2.3 binarySearch 为什么必须先排序Collections.binarySearch(list, key)用的是二分查找时间复杂度 O(log n)。但它的前提是列表已经按升序排好。如果你没排序就调用结果是未定义的——可能返回负数可能返回错误的索引反正不会报错这才是最坑的。ListInteger list Arrays.asList(5, 2, 8, 1); int idx Collections.binarySearch(list, 8); // 结果不可预测正确姿势ListInteger list new ArrayList(Arrays.asList(5, 2, 8, 1)); Collections.sort(list); // 先排序 int idx Collections.binarySearch(list, 8); // 返回 3返回值也有讲究找到就返回索引从 0 开始找不到返回的是-(插入点) - 1。这个负数设计是为了让你既能知道“没找到”又能知道“如果插入应该插在哪”。比如在[1, 3, 5]里找 4返回-3因为插入点是索引 2-(2)-1 -3。注意如果列表里有重复元素binarySearch不保证返回哪一个的索引。想要第一个或最后一个得自己再往两边扫。2.4 reverse、shuffle、swap 这些“小方法”的实战价值Collections.reverse(list)就是把列表原地反转实现很朴素双指针从两头往中间换。面试里偶尔会让人手写反转其实就是在考这个。Collections.shuffle(list)是洗牌底层用Random做 Fisher-Yates 洗牌。这个在写抽奖、随机排序、打乱题目顺序时特别有用。有个细节shuffle可以传入一个Random对象这样你可以控制随机种子方便测试复现。Collections.shuffle(list, new Random(42)); // 固定种子结果可复现Collections.swap(list, i, j)交换两个位置的元素看着简单但自己写容易越界用现成的更稳。Collections.rotate(list, distance)是循环移位这个冷门但有意思。比如[1,2,3,4,5]旋转 2 位变成[4,5,1,2,3]。写轮播、循环队列的时候能用上。3. 线程安全包装synchronizedXxx 的真相3.1 synchronizedList 到底锁了什么Collections.synchronizedList(list)返回一个包装类SynchronizedList它内部所有方法都加了synchronized块锁的是包装对象自己mutex。ListString syncList Collections.synchronizedList(new ArrayList()); syncList.add(a); // 内部 synchronized (mutex) { ... }但这里有个巨大的坑面试必问单个方法是线程安全的但复合操作不是。// 错误示范这不是原子的 if (!syncList.isEmpty()) { syncList.get(0); }因为isEmpty()和get(0)是两次独立加锁中间可能被其他线程插入修改。正确做法是自己加锁synchronized (syncList) { if (!syncList.isEmpty()) { syncList.get(0); } }还有一个更隐蔽的坑迭代的时候必须手动同步。// 错误示范可能抛 ConcurrentModificationException for (String s : syncList) { System.out.println(s); } // 正确示范 synchronized (syncList) { for (String s : syncList) { System.out.println(s); } }为什么因为迭代器是fail-fast的它不检查锁只检查modCount。别的线程一改你的迭代器就炸。这个点在《Java 并发编程实战》里专门提过面试官也爱拿来考。3.2 synchronizedList 和 CopyOnWriteArrayList 怎么选这是并发集合选型的经典问题。我列个表对比维度synchronizedListCopyOnWriteArrayList锁粒度方法级 synchronized写时加锁读无锁读性能一般要抢锁极高无锁写性能一般差每次复制整个数组内存占用低高写时双倍迭代器fail-fast需手动同步快照弱一致不需同步适用场景读写均衡读多写极少选型逻辑很简单读多写极少用 CopyOnWriteArrayList读写差不多或者写不少就用 synchronizedList。比如配置列表、监听器列表这种“几乎不变、频繁遍历”的场景CopyOnWriteArrayList 是绝配。但如果是频繁增删的队列用 CopyOnWriteArrayList 就是灾难每次写都复制整个数组内存和 CPU 都扛不住。实操心得我见过有项目在日志收集场景用 CopyOnWriteArrayList 存日志结果写太频繁GC 直接爆了。这种场景应该用ConcurrentLinkedQueue或者LinkedBlockingQueue。3.3 synchronizedMap 和 ConcurrentHashMap 的关系Collections.synchronizedMap(map)和ConcurrentHashMap都是线程安全的 Map但实现完全不同。synchronizedMap是全表锁所有操作抢同一把锁并发度是 1。ConcurrentHashMap在 JDK 8 之后是CAS synchronized 锁单个桶并发度高得多。那synchronizedMap还有存在价值吗有但很少。比如你需要包装一个非线程安全的LinkedHashMap并保持其插入顺序语义同时并发量很低这时候synchronizedMap就够了。但绝大多数场景直接上ConcurrentHashMap更合适。面试里如果问“为什么有了 synchronizedMap 还要 ConcurrentHashMap”核心答案就是锁粒度和并发度。4. 不可变包装unmodifiableXxx 的边界4.1 unmodifiableList 不是真的“不可变”这是最容易被误解的一个点。Collections.unmodifiableList(list)返回的是一个视图它只是拦截了所有修改方法抛UnsupportedOperationException。但原 list 还是可以改的而且改了之后这个“不可变”视图也会跟着变。ListString original new ArrayList(); original.add(a); ListString unmod Collections.unmodifiableList(original); original.add(b); System.out.println(unmod); // 输出 [a, b]看到没unmod自己不能改但它反映的是original的实时状态。所以它叫“不可修改视图”不叫“不可变集合”。真正的不可变集合是 JDK 9 引入的List.of()、Set.of()、Map.of()那些才是从根上不可变。面试里如果问“怎么创建一个不可变集合”答Collections.unmodifiableList只能算及格能补充List.of()的才是加分项。4.2 为什么需要不可变视图两个典型场景场景一防御性编程。你写一个方法返回内部集合如果直接返回原引用调用方可以随意改你的内部状态。包一层unmodifiableList就能防止这种“越权修改”。public ListString getItems() { return Collections.unmodifiableList(this.items); }场景二只读共享。多个线程只读一个集合用不可变视图可以省掉同步开销因为大家心里都清楚“没人会改”。但要注意unmodifiableList本身不保证线程安全。如果原 list 在别的线程被改你读的时候照样可能出问题。它只是“禁止通过这个视图修改”不是“保证底层不变”。4.3 emptyList、singletonList 的妙用Collections.emptyList()返回一个空的不可变列表。它的好处是不用每次 new全局共享一个实例省内存。而且它类型安全Collections.StringemptyList()能正确推断泛型。public ListUser findUsers(String name) { if (name null) { return Collections.emptyList(); // 比 return null 好一万倍 } // ... }返回空集合而不是 null是《Effective Java》里明确推荐的做法。调用方不用做 null 检查直接 for 循环也不会 NPE。Collections.singletonList(obj)返回只含一个元素的不可变列表。写单元测试、构造简单返回值时特别顺手。return Collections.singletonList(new User(张三));这两个方法在面试里常和“如何避免返回 null”一起考答上来就是加分。5. 批量操作与统计addAll、fill、frequency5.1 addAll 的可变参数版本Collections.addAll(Collection, T...)是把一批元素加进集合比list.addAll(Arrays.asList(...))更高效因为它不用先创建一个中间 list。ListString list new ArrayList(); Collections.addAll(list, a, b, c);这个在初始化集合时很好用比一个个add清爽。5.2 fill 和 copy 的边界Collections.fill(list, obj)把列表所有位置填成同一个对象。注意是同一个引用不是每个位置 new 一个。如果对象是可变的改一个等于改全部。Collections.copy(dest, src)把 src 的元素复制到 dest要求dest.size() src.size()否则抛IndexOutOfBoundsException。这个和System.arraycopy不一样后者不要求目标有足够空间。5.3 frequency 和 disjoint 的实用场景Collections.frequency(collection, obj)统计某元素出现次数。底层就是遍历 equals比较O(n)。int count Collections.frequency(list, a);Collections.disjoint(c1, c2)判断两个集合是否没有交集返回 true 表示完全不相交。这个在权限校验、标签匹配里能用上。if (Collections.disjoint(userRoles, requiredRoles)) { throw new AccessDeniedException(权限不足); }这两个方法冷门但实用面试里偶尔会问答出来显得你基础扎实。6. 常见问题与排查技巧实录6.1 高频问题速查表问题现象根本原因解决方案UnsupportedOperationException对Arrays.asList或unmodifiableList做修改包一层new ArrayList(...)ConcurrentModificationException迭代时被其他线程或自己修改用迭代器的remove或手动同步binarySearch返回错误索引列表未排序先sort再binarySearchsynchronizedList复合操作出错单方法加锁复合操作没锁手动synchronized (list)unmodifiableList内容变了原 list 被修改用List.of()或深拷贝sort结果不稳定用了不稳定的比较器确保比较器满足传递性6.2 几个我踩过的坑坑一Collections.sort的比较器必须满足传递性。我见过有人写了个比较器a b返回 1a b返回 -1但a b时返回 1结果 TimSort 直接抛IllegalArgumentException: Comparison method violates its general contract!。这个异常在 JDK 7 之后才出现因为 TimSort 对比较器的合法性做了检查。解决办法就是老老实实返回 0。坑二synchronizedList的迭代器同步容易忘。我review代码时见过好几次单方法都加了锁一到 for 循环就忘了包synchronized线上偶发ConcurrentModificationException查半天。后来团队直接约定用synchronizedList的地方迭代必须写synchronized块code review 重点看这个。坑三unmodifiableMap的entrySet也能改。这个比较隐蔽。Collections.unmodifiableMap(map).entrySet()返回的 set 里的Map.Entry它的setValue方法是能改的因为unmodifiableMap只拦截了put、remove这些没拦截Entry.setValue。要真正不可变得用Map.of()或者自己包一层。MapString, String map new HashMap(); map.put(a, 1); MapString, String unmod Collections.unmodifiableMap(map); for (Map.EntryString, String e : unmod.entrySet()) { e.setValue(2); // 居然能改 }这个点在面试里属于“杀手锏”级别能答出来的候选人我基本都会给高分。6.3 面试答题的层次感最后说点答题技巧。面试问Collections别一上来就背 API。按这个层次答第一层说清Collections和Collection的区别这是基本功。第二层挑两三个高频方法讲透比如sort的底层是 TimSort、synchronizedList的复合操作陷阱、unmodifiableList的视图语义。第三层主动对比比如synchronizedListvsCopyOnWriteArrayList、unmodifiableListvsList.of()展示你的选型能力。第四层讲踩坑经验比如Arrays.asList不能排序、Entry.setValue能绕过不可变这些是区分“背过”和“用过”的关键。我个人在实际面试中的体会是能把第四层讲出来的候选人基本都过了。因为这说明他不是临时抱佛脚而是真在项目里用过、踩过、总结过。这种经验比背一百个 API 都值钱。
1. 为什么 Collections 工具类值得单独拎出来讲1.1 从一道面试题说起面试里问Collections很多人第一反应是“不就是个工具类吗sort、reverse、shuffle那几个方法”。但真正拉开差距的地方在于面试官往往不是考你会不会调 API而是考你知不知道Collections和Collection的区别、synchronizedList和CopyOnWriteArrayList的取舍、unmodifiableList到底“不可变”到什么程度、sort底层用的什么排序、binarySearch为什么必须先排序。我自己带过几轮面试也被人面试过。一个很典型的场景是候选人能背出Collections.sort(list)的用法但当我追问“如果这个 list 是Arrays.asList()返回的能不能排序”十个人里有六七个会卡住。再追问“Collections.unmodifiableList包一层之后原 list 改了会怎样”能答对的更少。所以这篇东西不是一份 API 手册而是把Collections这个类里真正容易踩坑、面试高频、生产环境也真会用到的点一条一条拆开讲清楚。适合正在准备面试的同学也适合写了几年业务代码、但对集合工具类只停留在“会用”层面的开发者。1.2 Collections 和 Collection 到底差在哪先把最容易混淆的一对概念钉死。Collection是接口是List、Set、Queue这些单列集合的顶层父接口它定义的是“一个集合该有什么行为”——add、remove、size、iterator这些。Collections是类位于java.util包下是一个纯粹的工具类构造函数被私有化你没法new它。它里面全是static方法作用是对集合进行“操作”或“包装”。一句话记Collection是“是什么”Collections是“能对它做什么”。面试里如果连这个都说不清基本就凉了一半。Collections的方法大致可以分成这么几类我按使用频率和面试频率排一下分类代表方法面试频率排序与查找sort、binarySearch、reverse、shuffle极高最值max、min中线程安全包装synchronizedList、synchronizedMap、synchronizedSet极高不可变包装unmodifiableList、unmodifiableMap高空集合emptyList、emptyMap、emptySet中单元素集合singletonList、singleton中批量操作addAll、fill、copy、replaceAll中类型检查checkedList、checkedMap低频率统计frequency、disjoint低这张表建议先有个印象下面逐个展开。2. 排序与查找sort 和 binarySearch 的隐藏考点2.1 Collections.sort 底层到底怎么排的Collections.sort(ListT list)这个方法很多人以为它自己实现了一套排序算法。实际上它的实现是这样的public static T extends Comparable? super T void sort(ListT list) { list.sort(null); }它把活直接甩给了List接口的sort默认方法。而List.sort的默认实现是default void sort(Comparator? super E c) { Object[] a this.toArray(); Arrays.sort(a, (Comparator) c); ListIteratorE i this.listIterator(); for (Object e : a) { i.next(); i.set((E) e); } }也就是说先把 list 转成数组用Arrays.sort排好再通过ListIterator一个个写回去。这里有个关键点Arrays.sort对对象数组用的是TimSort归并排序的优化版本时间复杂度稳定在 O(n log n)而且是稳定排序。为什么强调“稳定”因为面试官很爱问“Collections.sort是稳定排序吗”答案是稳定的。稳定意味着相等元素的相对顺序不会被打乱。比如你有一个按年龄排好的列表再按姓名排一次同姓名的人年龄顺序还是保持的。那如果我想降序怎么办两种写法// 写法一传自定义 Comparator Collections.sort(list, (a, b) - b.compareTo(a)); // 写法二用 reverseOrder Collections.sort(list, Collections.reverseOrder());Collections.reverseOrder()返回一个反转自然顺序的比较器这个在面试里也常被问到因为它内部其实是对Comparable做了个包装把compareTo的参数顺序调换。2.2 一个高频陷阱Arrays.asList 返回的 list 不能排序这是我自己踩过的坑也是面试里区分度很高的一题。ListInteger list Arrays.asList(3, 1, 2); Collections.sort(list); // 抛 UnsupportedOperationException为什么因为Arrays.asList返回的是Arrays内部的ArrayList注意不是java.util.ArrayList它底层直接引用原数组不支持结构性修改。sort方法里调用了ListIterator.set()而这个内部类没有重写set所以直接抛异常。那怎么破包一层ListInteger list new ArrayList(Arrays.asList(3, 1, 2)); Collections.sort(list); // 正常这个点面试官特别爱问因为它同时考了Arrays.asList的语义、ListIterator的行为、以及“结构性修改”和“非结构性修改”的区别。set属于非结构性修改不改变长度但Arrays内部类连set都不支持所以照样炸。2.3 binarySearch 为什么必须先排序Collections.binarySearch(list, key)用的是二分查找时间复杂度 O(log n)。但它的前提是列表已经按升序排好。如果你没排序就调用结果是未定义的——可能返回负数可能返回错误的索引反正不会报错这才是最坑的。ListInteger list Arrays.asList(5, 2, 8, 1); int idx Collections.binarySearch(list, 8); // 结果不可预测正确姿势ListInteger list new ArrayList(Arrays.asList(5, 2, 8, 1)); Collections.sort(list); // 先排序 int idx Collections.binarySearch(list, 8); // 返回 3返回值也有讲究找到就返回索引从 0 开始找不到返回的是-(插入点) - 1。这个负数设计是为了让你既能知道“没找到”又能知道“如果插入应该插在哪”。比如在[1, 3, 5]里找 4返回-3因为插入点是索引 2-(2)-1 -3。注意如果列表里有重复元素binarySearch不保证返回哪一个的索引。想要第一个或最后一个得自己再往两边扫。2.4 reverse、shuffle、swap 这些“小方法”的实战价值Collections.reverse(list)就是把列表原地反转实现很朴素双指针从两头往中间换。面试里偶尔会让人手写反转其实就是在考这个。Collections.shuffle(list)是洗牌底层用Random做 Fisher-Yates 洗牌。这个在写抽奖、随机排序、打乱题目顺序时特别有用。有个细节shuffle可以传入一个Random对象这样你可以控制随机种子方便测试复现。Collections.shuffle(list, new Random(42)); // 固定种子结果可复现Collections.swap(list, i, j)交换两个位置的元素看着简单但自己写容易越界用现成的更稳。Collections.rotate(list, distance)是循环移位这个冷门但有意思。比如[1,2,3,4,5]旋转 2 位变成[4,5,1,2,3]。写轮播、循环队列的时候能用上。3. 线程安全包装synchronizedXxx 的真相3.1 synchronizedList 到底锁了什么Collections.synchronizedList(list)返回一个包装类SynchronizedList它内部所有方法都加了synchronized块锁的是包装对象自己mutex。ListString syncList Collections.synchronizedList(new ArrayList()); syncList.add(a); // 内部 synchronized (mutex) { ... }但这里有个巨大的坑面试必问单个方法是线程安全的但复合操作不是。// 错误示范这不是原子的 if (!syncList.isEmpty()) { syncList.get(0); }因为isEmpty()和get(0)是两次独立加锁中间可能被其他线程插入修改。正确做法是自己加锁synchronized (syncList) { if (!syncList.isEmpty()) { syncList.get(0); } }还有一个更隐蔽的坑迭代的时候必须手动同步。// 错误示范可能抛 ConcurrentModificationException for (String s : syncList) { System.out.println(s); } // 正确示范 synchronized (syncList) { for (String s : syncList) { System.out.println(s); } }为什么因为迭代器是fail-fast的它不检查锁只检查modCount。别的线程一改你的迭代器就炸。这个点在《Java 并发编程实战》里专门提过面试官也爱拿来考。3.2 synchronizedList 和 CopyOnWriteArrayList 怎么选这是并发集合选型的经典问题。我列个表对比维度synchronizedListCopyOnWriteArrayList锁粒度方法级 synchronized写时加锁读无锁读性能一般要抢锁极高无锁写性能一般差每次复制整个数组内存占用低高写时双倍迭代器fail-fast需手动同步快照弱一致不需同步适用场景读写均衡读多写极少选型逻辑很简单读多写极少用 CopyOnWriteArrayList读写差不多或者写不少就用 synchronizedList。比如配置列表、监听器列表这种“几乎不变、频繁遍历”的场景CopyOnWriteArrayList 是绝配。但如果是频繁增删的队列用 CopyOnWriteArrayList 就是灾难每次写都复制整个数组内存和 CPU 都扛不住。实操心得我见过有项目在日志收集场景用 CopyOnWriteArrayList 存日志结果写太频繁GC 直接爆了。这种场景应该用ConcurrentLinkedQueue或者LinkedBlockingQueue。3.3 synchronizedMap 和 ConcurrentHashMap 的关系Collections.synchronizedMap(map)和ConcurrentHashMap都是线程安全的 Map但实现完全不同。synchronizedMap是全表锁所有操作抢同一把锁并发度是 1。ConcurrentHashMap在 JDK 8 之后是CAS synchronized 锁单个桶并发度高得多。那synchronizedMap还有存在价值吗有但很少。比如你需要包装一个非线程安全的LinkedHashMap并保持其插入顺序语义同时并发量很低这时候synchronizedMap就够了。但绝大多数场景直接上ConcurrentHashMap更合适。面试里如果问“为什么有了 synchronizedMap 还要 ConcurrentHashMap”核心答案就是锁粒度和并发度。4. 不可变包装unmodifiableXxx 的边界4.1 unmodifiableList 不是真的“不可变”这是最容易被误解的一个点。Collections.unmodifiableList(list)返回的是一个视图它只是拦截了所有修改方法抛UnsupportedOperationException。但原 list 还是可以改的而且改了之后这个“不可变”视图也会跟着变。ListString original new ArrayList(); original.add(a); ListString unmod Collections.unmodifiableList(original); original.add(b); System.out.println(unmod); // 输出 [a, b]看到没unmod自己不能改但它反映的是original的实时状态。所以它叫“不可修改视图”不叫“不可变集合”。真正的不可变集合是 JDK 9 引入的List.of()、Set.of()、Map.of()那些才是从根上不可变。面试里如果问“怎么创建一个不可变集合”答Collections.unmodifiableList只能算及格能补充List.of()的才是加分项。4.2 为什么需要不可变视图两个典型场景场景一防御性编程。你写一个方法返回内部集合如果直接返回原引用调用方可以随意改你的内部状态。包一层unmodifiableList就能防止这种“越权修改”。public ListString getItems() { return Collections.unmodifiableList(this.items); }场景二只读共享。多个线程只读一个集合用不可变视图可以省掉同步开销因为大家心里都清楚“没人会改”。但要注意unmodifiableList本身不保证线程安全。如果原 list 在别的线程被改你读的时候照样可能出问题。它只是“禁止通过这个视图修改”不是“保证底层不变”。4.3 emptyList、singletonList 的妙用Collections.emptyList()返回一个空的不可变列表。它的好处是不用每次 new全局共享一个实例省内存。而且它类型安全Collections.StringemptyList()能正确推断泛型。public ListUser findUsers(String name) { if (name null) { return Collections.emptyList(); // 比 return null 好一万倍 } // ... }返回空集合而不是 null是《Effective Java》里明确推荐的做法。调用方不用做 null 检查直接 for 循环也不会 NPE。Collections.singletonList(obj)返回只含一个元素的不可变列表。写单元测试、构造简单返回值时特别顺手。return Collections.singletonList(new User(张三));这两个方法在面试里常和“如何避免返回 null”一起考答上来就是加分。5. 批量操作与统计addAll、fill、frequency5.1 addAll 的可变参数版本Collections.addAll(Collection, T...)是把一批元素加进集合比list.addAll(Arrays.asList(...))更高效因为它不用先创建一个中间 list。ListString list new ArrayList(); Collections.addAll(list, a, b, c);这个在初始化集合时很好用比一个个add清爽。5.2 fill 和 copy 的边界Collections.fill(list, obj)把列表所有位置填成同一个对象。注意是同一个引用不是每个位置 new 一个。如果对象是可变的改一个等于改全部。Collections.copy(dest, src)把 src 的元素复制到 dest要求dest.size() src.size()否则抛IndexOutOfBoundsException。这个和System.arraycopy不一样后者不要求目标有足够空间。5.3 frequency 和 disjoint 的实用场景Collections.frequency(collection, obj)统计某元素出现次数。底层就是遍历 equals比较O(n)。int count Collections.frequency(list, a);Collections.disjoint(c1, c2)判断两个集合是否没有交集返回 true 表示完全不相交。这个在权限校验、标签匹配里能用上。if (Collections.disjoint(userRoles, requiredRoles)) { throw new AccessDeniedException(权限不足); }这两个方法冷门但实用面试里偶尔会问答出来显得你基础扎实。6. 常见问题与排查技巧实录6.1 高频问题速查表问题现象根本原因解决方案UnsupportedOperationException对Arrays.asList或unmodifiableList做修改包一层new ArrayList(...)ConcurrentModificationException迭代时被其他线程或自己修改用迭代器的remove或手动同步binarySearch返回错误索引列表未排序先sort再binarySearchsynchronizedList复合操作出错单方法加锁复合操作没锁手动synchronized (list)unmodifiableList内容变了原 list 被修改用List.of()或深拷贝sort结果不稳定用了不稳定的比较器确保比较器满足传递性6.2 几个我踩过的坑坑一Collections.sort的比较器必须满足传递性。我见过有人写了个比较器a b返回 1a b返回 -1但a b时返回 1结果 TimSort 直接抛IllegalArgumentException: Comparison method violates its general contract!。这个异常在 JDK 7 之后才出现因为 TimSort 对比较器的合法性做了检查。解决办法就是老老实实返回 0。坑二synchronizedList的迭代器同步容易忘。我review代码时见过好几次单方法都加了锁一到 for 循环就忘了包synchronized线上偶发ConcurrentModificationException查半天。后来团队直接约定用synchronizedList的地方迭代必须写synchronized块code review 重点看这个。坑三unmodifiableMap的entrySet也能改。这个比较隐蔽。Collections.unmodifiableMap(map).entrySet()返回的 set 里的Map.Entry它的setValue方法是能改的因为unmodifiableMap只拦截了put、remove这些没拦截Entry.setValue。要真正不可变得用Map.of()或者自己包一层。MapString, String map new HashMap(); map.put(a, 1); MapString, String unmod Collections.unmodifiableMap(map); for (Map.EntryString, String e : unmod.entrySet()) { e.setValue(2); // 居然能改 }这个点在面试里属于“杀手锏”级别能答出来的候选人我基本都会给高分。6.3 面试答题的层次感最后说点答题技巧。面试问Collections别一上来就背 API。按这个层次答第一层说清Collections和Collection的区别这是基本功。第二层挑两三个高频方法讲透比如sort的底层是 TimSort、synchronizedList的复合操作陷阱、unmodifiableList的视图语义。第三层主动对比比如synchronizedListvsCopyOnWriteArrayList、unmodifiableListvsList.of()展示你的选型能力。第四层讲踩坑经验比如Arrays.asList不能排序、Entry.setValue能绕过不可变这些是区分“背过”和“用过”的关键。我个人在实际面试中的体会是能把第四层讲出来的候选人基本都过了。因为这说明他不是临时抱佛脚而是真在项目里用过、踩过、总结过。这种经验比背一百个 API 都值钱。
