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) 都要从头遍历。
