Collections类不简化集合操作，仅提供静态工具方法；真正简化的是Stream API和集合增强；unmodifiableList()因不隔离底层状态变化仍可能抛ConcurrentModificationException。
Java 的 Collections 类本身不简化集合操作——它只提供静态工具方法，且多数方法作用于已存在的集合对象；真正简化操作的是 Java 8+ 的 Stream API 和后续版本的集合增强（如 List.of()、Map.copyOf()），而 Collections 更多用于不可变包装、同步代理或基础算法。
为什么 Collections.unmodifiableList() 返回的集合仍可能报 ConcurrentModificationException
这不是线程安全问题，而是底层检测机制导致的误判：当你用 Collections.unmodifiableList() 包装一个非线程安全但正在被迭代的 ArrayList，此时另一个线程（或同一线程）修改原列表，迭代器仍会触发 ConcurrentModificationException。因为 unmodifiableXxx() 只是加了一层“拒绝写操作”的代理，不隔离底层集合的状态变化。
-
unmodifiableList()返回的对象调用add()、remove()会直接抛UnsupportedOperationException - 但它不阻止你通过原始引用修改底层数组，迭代器仍检查
modCount - 若需真正安全的只读视图，应配合
CopyOnWriteArrayList或在构造后不再持有可变引用
Collections.synchronizedList() 的锁粒度陷阱
Collections.synchronizedList() 返回的代理对象，所有方法（包括 get()、size()、iterator()）都用同一把对象锁（this），看似线程安全，实则隐藏严重性能瓶颈和逻辑漏洞。
- 单个方法调用是原子的，但复合操作（如“检查是否存在再添加”）仍需手动同步
-
iterator()返回的迭代器本身不加锁，遍历时必须手动synchronized(list) - 高并发读场景下，
get(i)被阻塞在写操作之后，吞吐量远低于CopyOnWriteArrayList或ConcurrentHashMap - 替代方案优先考虑
java.util.concurrent包下的具体类，而非用Collections做同步包装
Collections.binarySearch() 对 List 的真实要求
Collections.binarySearch() 不要求传入的 List 是 RandomAccess 实现，但性能差异极大：对 LinkedList 调用该方法，时间复杂度退化为 O(n)，因为每次 get(mid) 都要从头遍历。
立即学习“Java免费学习笔记（深入）”；
- 必须确保列表已按自然顺序或指定
Comparator排序，否则结果无意义 - 支持
null元素的前提是Comparator显式处理null，否则抛NullPointerException - 返回值为负数时，
-(insertionPoint) - 1，不是简单的-1表示未找到 - 若频繁搜索，建议改用
TreeSet或排序后构建Arrays.binarySearch()（转为数组更高效）
真正需要简化集合操作时，别卡在 Collections 上——它的设计目标是“最小侵入式增强”，不是“开箱即用的便捷层”。比如排序，Collections.sort(list) 内部还是调 list.sort(null)；查找元素，list.stream().filter(...).findFirst() 更直观且可组合。容易忽略的一点：几乎所有 Collections 工具方法都不接受 null 集合引用，传 null 直接 NullPointerException，连防御性提示都没有。
