collections.sort()要求元素实现comparable或传入comparator，否则运行时抛异常；仅适用于list，基本类型数组用arrays.sort()；reverse()仅反转引用顺序；binarysearch()需已排序且比较逻辑一致。
用 Collections.sort() 排序前必须确认元素可比较
直接对 ArrayList<string></string> 或 ArrayList<integer></integer> 调用 Collections.sort() 没问题，但一旦元素类型没实现 Comparable（比如自定义类未重写 compareTo()），运行时抛 ClassCastException 或 IllegalArgumentException。这不是编译错误，容易漏测。
- 如果元素不可比，必须传入
Comparator，例如：Collections.sort(list, (a, b) -> a.getId().compareTo(b.getId())) -
sort()只支持List，对Set或Map值集合需先转成ArrayList再操作 - Java 8+ 更推荐用
list.sort(comparator)实例方法，避免静态调用且更直观 - 对基本类型数组（如
int[]）不能用这个方法——那是Arrays.sort()的职责
Collections.reverse() 只反转顺序，不改变元素本身
它只是把 List 中的引用位置倒过来，时间复杂度 O(n)，无额外内存开销。常见误用是以为它能“深翻转”嵌套结构或字符串内容。
- 原 list 是
[1, 2, 3]，调用后变成[3, 2, 1]；但如果 list 里存的是可变对象（比如StringBuilder），它们内部内容不会被反转 - 对
LinkedList效率略低于ArrayList（因双向链表遍历缓存友好性差），但差别通常可忽略 - 不能用于只读视图（如
Collections.unmodifiableList()包裹后的 list），会抛UnsupportedOperationException
用 Collections.synchronizedList() 同步集合仍需手动加锁遍历
很多人以为包一层就“线程安全了”，结果在多线程迭代时仍报 ConcurrentModificationException。这是因为同步只覆盖单个操作（如 add()、get()），不保证复合操作原子性。
- 遍历必须手动同步：
synchronized (syncList) { for (Object o : syncList) { ... } } - 返回的是代理对象，底层仍是原 list；若保留了原始引用并直接操作，同步失效
- 高频读写场景下性能较差，考虑
CopyOnWriteArrayList（适合读多写少）或ConcurrentHashMap配合ConcurrentLinkedQueue等更现代方案
Collections.binarySearch() 要求 list 已排序且比较逻辑一致
它不是“在任意 list 里搜关键词”，而是严格基于二分查找算法——前提是 list 必须按同一规则升序排列，否则结果不可预测（可能返回负数、错位索引，甚至找不到明明存在的元素）。
立即学习“Java免费学习笔记（深入）”；
- 若用
Comparator排过序，搜索时必须传同样的Comparator，否则行为未定义 - 返回值不是布尔值：找到返回索引 ≥ 0；未找到返回
-(insertionPoint + 1)，需用Math.abs(result) - 1解析插入点 - 对非
RandomAccesslist（如LinkedList）性能极差，每次取中点都要从头遍历，实际退化为 O(n)
实际用的时候，最容易卡住的不是“会不会调”，而是“有没有意识到排序/同步/比较这三件事必须前后对得上”。比如用 TreeSet 自动排了序，再拿去给 binarySearch() 用——不行，因为 TreeSet 不是 List。这种隐含前提，文档里写得淡，出问题才想起来。
