Collections.binarySearch查找效率探讨：二分法查找的优势分析

二分法查找的最大优势，就是把搜索次数压缩到了对数级别——100万个元素，最多只需要20次比较，远远甩开线性扫描那种逐个遍历的笨办法。 当然，这个优势不是无条件就能拿到的。它有两个硬性前提：数据必须已经排好序，而且底层容器得支持O(1)时间定位中间元素——所以ArrayList行，LinkedList不行。后者每次取中间位置都得从头遍历，时间复杂度直接退化到O(n)，二分查找也就名存实亡了。 - 调用binarySearch之前，务必确认列表已经按相同规则排好序 - 如果用了自定义Comparator来排序，binarySearch时也必须传入同一个实例 - 升序排完却拿降序Comparator去查，结果等于在乱序数据上硬套逻辑，毫无可靠性可言

效率对比非常直观

线性查找平均要检查一半元素，最坏情况得比对全部n个；二分查找每次砍掉一半范围，10⁶元素最多20次，10⁹元素也才约30次。这个差距在真实业务里直接反映为响应延迟的大幅下降。 - 数组长度每翻一倍，二分查找最多只多一次比较 - 而线性查找的最坏耗时会同步翻倍 - 数据量超过几万后，二分的优势就非常明显了

查不到也能立刻知道插哪

返回的负值不是随便设计的：-4意味着目标应该插入索引3的位置。这个insertionIndex可以直接用于list.add(-result - 1, target)，无需额外遍历或重写逻辑——特别适合维护动态有序缓存，或者构建轻量级优先队列。 - 避免重复计算插入位置，减少出错可能 - 配合sort + binarySearch + add，能稳定维持列表的有序性 - 适用于读多写少、需要保持局部有序的场景 不复杂，但容易忽略细节。