在Java中如何使用Collections工具类处理集合_Java集合操作实用方法解析_技术教程

Collections不能直接实例化，因其是私有构造函数的纯静态工具类，仅提供针对集合的通用操作方法。

Collections 是一个纯静态工具类，所有方法都是 static，构造函数被显式声明为 private。试图写 new Collections() 会触发编译错误：Constructor Collections() is not visible。

它不封装状态，只提供对 List、Set、Map（注意：Map 相关方法在 Collections 中极少，主要靠 Map 自身或 Map.of() 等）的通用操作
所有方法都以集合对象为参数，例如 Collections.sort(list)，而非 list.sort()（后者是 List 接口默认方法，Java 8+）
若误用 Arrays.asList() 返回的不可变列表调用 Collections.sort()，会抛出 UnsupportedOperationException —— 因为底层是固定大小数组包装，不支持增删

它返回的是原始集合的“只读视图”，不是深拷贝。底层仍引用原集合，一旦原集合被外部修改，只读视图也会反映变化（但无法通过只读视图修改）。

Collections.unmodifiableList(list) 返回的 List 调用 add() 或 set() 会立即抛出 UnsupportedOperationException
但如果原 list 在别处被修改（比如另一个引用调用了 list.add(x)），那么只读视图的 get(0) 可能返回新值
真正安全的只读封装需配合不可变数据结构（如 ImmutableList.copyOf(list) 来自 Guava）或手动复制：Collections.unmodifiableList(new ArrayList(original))

Collections.sort() 和 Collections.synchronizedList() 这类方法返回的是装饰器（Decorator）对象，使用时容易忽略其副作用边界。

Collections.sort() 要求元素实现 Comparable，否则必须传入 Comparator；若元素为 null 且比较器未处理 null，会抛 NullPointerException
Collections.synchronizedList(list) 仅保证单个方法调用线程安全（如 sList.get(0) 是原子的），但复合操作（如 if (!sList.isEmpty()) sList.remove(0)）仍需手动加锁，否则存在竞态
同步包装器性能开销明显，高频场景优先考虑 CopyOnWriteArrayList（读多写少）或 ConcurrentHashMap 替代 Collections.synchronizedMap()

避免手写 new ArrayList() 再 add()，既低效又易错。应优先使用 Collections 提供的不可变工厂方法。

空集合：Collections.emptyList()、Collections.emptySet()、Collections.emptyMap() —— 返回共享的、类型安全的不可变实例，零内存开销
单元素集合：Collections.singletonList("a")、Collections.singleton("x")、Collections.singletonMap("k", "v") —— 同样不可变，且比 Arrays.asList("a") 更明确语义
⚠️ 注意：Collections.singletonList() 返回的是 List，不是 ArrayList；调用 list.add() 会抛异常，不是因为“没初始化”，而是设计如此

String s = "hello";
List safeList = Collections.singletonList(s);
// 下面这行会抛 UnsupportedOperationException
// safeList.add("world");

很多开发者卡在“明明用了 unmodifiableList 却还是被改了”，问题往往出在没意识到原集合仍可变；或者以为 synchronizedList 能包治并发，结果在迭代时忘了加锁 —— 这些都不是 API 设计缺陷，而是对装饰器模式边界的误判。

在Java中如何使用Collections工具类处理集合_Java集合操作实用方法解析