collections工具类是集合操作的静态方法集合，需谨慎使用：排序与查找须严格守序，不可变/同步视图非深拷贝，填充替换等操作注意边界与副作用，高频场景优先用stream而非链式调用。
Collections 工具类不是集合本身，而是一套专为集合操作设计的静态方法集合。用得好，能显著减少样板代码、提升可读性与安全性；用得随意，反而容易引发 UnsupportedOperationException、ConcurrentModificationException 或二分查找失败等隐性问题。关键不在“会不会调用”，而在“何时用、怎么用、为何这样用”。
排序与查找：必须守序，否则失效
sort() 和 binarySearch() 是强耦合的一对。binarySearch 要求列表**严格升序排列**（自然顺序或按同一 Comparator 排），否则返回值无意义——它不校验顺序，只按算法逻辑计算索引。
- 先排序，再查找：哪怕只查一次，也要显式调用
Collections.sort(list)或Collections.sort(list, cmp) - 避免重复排序：若需多次查找，应确保 list 在生命周期内仅排序一次；频繁增删后查找，考虑改用 TreeSet 或维护有序结构
- 降序场景慎用 binarySearch：若用
Collections.reverseOrder()排成降序，binarySearch 仍按升序逻辑匹配，结果错误。正确做法是保持升序，用Comparator.reversed()查找时反向解释语义，或改用 stream filter
不可变与线程安全：视图 ≠ 原始集合
unmodifiableList()、synchronizedList() 等方法返回的是原始集合的“包装视图”，不是深拷贝。它们的约束只作用于该视图接口层面。
- 不可变视图仍会反映原始集合变更：若原始 list 后续被修改，unmodifiable 视图读取时能看到新内容，但调用 add/remove 会抛异常
- 同步包装仅保障单个方法原子性：synchronizedList 可防并发调用 add、get 等单操作冲突，但复合操作（如“检查是否存在再添加”）仍需手动加锁
- 空集合与单元素集合优先复用：用
Collections.emptyList()替代new ArrayList()，用Collections.singletonList("x")替代新建含一个元素的 list，节省对象开销且天然不可变
填充、替换与统计：注意边界与副作用
像 fill()、replaceAll()、frequency() 这类方法看似简单，但对集合状态和泛型类型敏感。
- fill() 会覆盖全部元素：传入的 list 必须已初始化且有容量，否则抛 IndexOutOfBoundsException；它不扩容，只写入已有位置
- replaceAll() 使用函数式接口：传入的 UnaryOperator 不应修改原对象状态（如改变字段值），否则可能破坏集合一致性；建议用于纯转换，如字符串转大写
- frequency() 对 null 安全：可正常统计 null 出现次数，但要注意 equals 实现——若元素自定义了 equals 且未处理 null，可能导致误判
性能与可维护性：少链式、多意图明确
Collections 方法本质是算法封装，每次调用都遍历整个集合。高频场景下，叠加多个操作（如先 sort 再 reverse 再 shuffle）会带来明显开销。
- 避免“为用而用”：比如仅需取最大值，直接
Collections.max(list)即可，不必先排序再取 get(0) - 不要链式调用多个 Collections 方法来模拟流式处理：Collections 没有惰性求值，每个方法都是全量扫描；真需复杂变换，优先考虑 Stream API
- 方法命名即契约：看到
swap()就知只换两个位置，看到shuffle()就默认使用默认随机源（可传 SecureRandom 提升随机质量），不猜测内部实现
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
