要让Collections.binarySearch达到O(log N)效率，必须确保列表严格升序、类型一致、使用相同Comparator、依托RandomAccess容器（如ArrayList）、正确解读返回值，并规避并发修改、null处理及泛型擦除风险。
要让 Collections.binarySearch 真正发挥 $O(\log N)$ 效率，关键不在调用本身，而在数据准备和使用边界是否严谨。它不是“用了就快”的黑盒，而是对前提条件零容忍的精密工具。
确保列表已严格升序且类型一致
binarySearch 不排序、不校验、不兜底——只在你确认有序后快速定位。哪怕一个元素错位，结果就不可信。
- 自然序：先调用
Collections.sort(list)，后续所有查找复用同一 List - 自定义序：排序和查找必须用同一个
Comparator实例，不能“排序用 A，查找用 B” - 避免隐性偏差：比如浮点数比较受精度影响；字符串忽略大小写排序后，查找时也得用相同规则
- 数组转 List 时，用
Arrays.asList(new Integer[]{1,3,5})，别用int[]—— 基本类型数组不支持泛型查找
选对容器，避开性能陷阱
二分依赖随机访问，get(i) 必须是 $O(1)$，否则算法退化。
- 优先用
ArrayList或Arrays.asList()包装的固定列表 - 别在
LinkedList上硬套 binarySearch：它的get(i)是 $O(n)$，整体变慢查找 - 运行时可检查：
list instanceof RandomAccess，不满足就换结构或改用TreeSet
正确解读返回值，直接提取位置信息
返回值不是布尔标志，而是带语义的整数编码，能同时回答“是否存在”和“该插在哪”。
- ≥ 0：找到，值就是索引（重复元素时返回任意匹配位置）
- -result - 1（不是取反，也不是 ~result）
- 插入位置始终在
[0, list.size()]范围内，可直接用于list.add(insertionPoint, item) - 判断存在性只需
index >= 0，别用index != -1—— 负数可能为 -2、-3、-4…
规避并发与类型安全风险
看似简单的调用，常因环境松动而失效。
- 多线程下，排序后、查找前若被其他线程修改列表，结果不保证；推荐用不可变列表（如 Guava 的
ImmutableList） - 列表含
null时，Comparator必须显式处理null，否则抛NullPointerException - 泛型擦除陷阱：避免原始类型声明（如
List list = new ArrayList()），混入不同类对象会导致运行时ClassCastException - 不要对
Collection或Set直接调用 —— 它只接受List，且要求实现RandomAccess
