Collections.binarySearch() 实现 O(log n) 查找的前提是列表严格按业务主键升序排列、比较逻辑精准轻量、运行时无并发写入风险；需初始化排序、定制 Comparator、正确处理返回值，并优先采用不可变或线程安全有序结构。
Collections.binarySearch() 能在已排序的 List 上实现 O(log n) 时间复杂度的查找，显著优于线性扫描的 O(n)。但要真正提升吞吐量，关键不在“调用方法”，而在于**正确准备数据结构、精准定义比较逻辑、规避常见陷阱**。
确保列表严格按业务主键升序排列
binarySearch 前提是列表已排序，且排序依据必须与搜索时使用的比较器完全一致。若业务主键是 String orderId 或 long transactionId，需提前一次性排序，避免每次搜索前重排：
- 使用
Collections.sort(list, comparator)初始化时排序一次（不可在循环中反复调用） - 插入新元素时，用
Collections.binarySearch()找到插入位置，再用list.add(index, item)维持有序 —— 不要用add()后再全量重排 - 若数据来自数据库或外部系统，优先在源头按主键排序返回，减少客户端压力
为业务主键定制 Comparator，避免创建临时对象
搜索时传入的 key 往往只是主键值（如 "ORD-2024-789"），而非完整对象。Comparator 必须能直接比对 key 和 list 中对象的主键字段，且不触发装箱、字符串解析或 getter 反射调用：
- 推荐使用 Lambda 实现：
(o1, o2) -> o1.getOrderId().compareTo(o2.getOrderId()) - 搜索时传入纯主键值：
Collections.binarySearch(list, "ORD-2024-789", comparator) - 避免在 compare 方法中做 null 检查或格式转换 —— 这些应在写入列表前校验干净
正确处理返回值，区分“找到”与“未找到”语义
binarySearch 返回值不是布尔值，而是索引或负插入点。高频调用下错误解读会引入隐性 bug：
- ≥ 0 表示找到，对应索引处即为目标对象
- -(returnVal + 1)；若只关心是否存在，用
result >= 0判断即可 - 不要用
result == -1判定“不存在”——这是常见误解，-1 仅表示应插入到索引 0 位置
注意并发与不可变性约束
binarySearch 本身是无状态的，但列表若被多线程修改，排序状态极易被破坏，导致搜索结果错乱甚至死循环：
- 生产环境推荐使用排序后转为
ImmutableList（如 Guava），彻底杜绝写操作 - 若需动态更新，改用线程安全的跳表结构（如
ConcurrentSkipListSet），它原生支持 O(log n) 查找且自带排序 - 切勿在 synchronized 块内调用 binarySearch —— 锁粒度大，反而扼杀吞吐优势
核心不是“怎么调用 binarySearch”，而是让列表始终处于可二分状态、比较逻辑轻量精准、运行时无竞争风险。做到这三点，吞吐量提升是自然结果。
