Java集合工具类作用及常用方法解析

Collections工具类提供安全高效的操作封装，所有方法静态调用；仅List支持sort等原地操作，需元素可比较且binarySearch前必须排序；推荐用emptyList()、singletonList()替代new ArrayList()；synchronizedList不保证复合操作线程安全。

Collections 工具类不是用来“替代”集合的，而是帮你**安全、高效地操作已有集合**——比如排序、找最大值、转成只读视图、包装成线程安全版本，或者快速初始化空/单元素集合。 它所有方法都是静态的，直接调用 Collections.sort(...) 就行，不用 new；但它不改变集合底层数据结构，只是提供一层操作封装。用错前提或忽略约束，很容易出诡异结果。

排序和反转必须分清前提：List 才支持，且 binarySearch 要先 sort

只有 List 支持 sort()、reverse()、shuffle()、swap() 等原地操作。对 Set 或 Map 直接调用会编译报错。

• Collections.sort(list) 要求元素实现 Comparable（如 Integer、String 可以，自定义类需手动实现）
• 想降序？别先 sort() 再 reverse() —— 推荐一步到位：Collections.sort(list, Comparator.reverseOrder())
• Collections.binarySearch(list, target) 必须在 list 已排序后调用，否则返回值完全不可信（不是“找不到”，是“算错了”）
• 注意：sort() 和 reverse() 都是原地修改，不返回新 List

别直接返回 new ArrayList()，用 emptyList() / singletonList() 更轻量

对外提供集合时，返回 new ArrayList<>() 是常见但低效的做法：既可被外部修改，又多占内存。用 Collections 的工厂方法更稳妥：

• Collections.emptyList() 返回一个全局共享的、不可变的空 List，零内存开销，线程安全
• Collections.singletonList("x") 比 Arrays.asList("x") 更明确语义，且返回的 List 真正不可变（add() 会抛 UnsupportedOperationException）
• 如果需要“只读但可变长度”的视图，才用 Collections.unmodifiableList(original) —— 但注意：它只是包装，original 被改，视图也会变

线程安全包装有陷阱：synchronizedList() 不等于“全自动线程安全”

Collections.synchronizedList(new ArrayList<>()) 确实让单个方法（如 add()、get()）加了锁，但复合操作仍可能出问题：

• 遍历必须手动加锁：

  synchronized (syncList) {
      for (String s : syncList) { ... }
  }

  否则可能抛 ConcurrentModificationException 或读到脏数据
• 像 if (!list.contains(x)) list.add(x) 这种检查+添加，不是原子的，即使用了 synchronizedList 也会竞态
• 真要高并发读写，优先考虑 CopyOnWriteArrayList 或 ConcurrentHashMap，而不是靠 Collections 包装

fill()、replaceAll()、frequency() 这些“小功能”其实很实用

它们常被忽略，但在批量处理或调试时省事很多：

• Collections.fill(list, "N/A")：快速把整个 List 填成默认值，比循环简洁
• Collections.replaceAll(list, null, "unknown")：安全替换 null（前提是 list 元素类型允许 null）
• Collections.frequency(collection, "abc")：统计任意 Collection（不只是 List）中某元素出现次数，比手写循环少出错
• Collections.copy(dest, src)：要求 dest 容量 ≥ src.size()，否则抛 IndexOutOfBoundsException —— 别忘了先 dest.ensureCapacity(src.size()) 或用 new ArrayList<>(src) 更省心

真正容易翻车的地方，往往不在“会不会用”，而在于**忽略约束条件**：比如对未排序 List 调 binarySearch，或以为 synchronizedList 能防住所有并发问题。这些方法本身很稳定，但它们的契约（contract）必须被严格遵守。