Arrays.binarySearch 性能与逻辑实战

先说个核心判断：Arrays.binarySearch 远远不是一个“一搜就灵”的黑箱工具。它的性能优势只在特定条件下才能兑现，逻辑细节也常常被误读。用得对，能把查找从 O(n) 压到 O(log n)；用错了，可能比遍历还慢，甚至返回一个看似合理却完全错误的结果。

小数组走线性扫描，这不是bug，是刻意的优化

别以为 binarySearch 只要一调用，就一定会执行二分查找。在 JDK 8 中，如果数组长度小于 21，底层实际上会用一个 for 循环直接遍历。这可不是偷懒，而是现代 CPU 缓存友好性做出的实际选择：短距离内的顺序访问，比反复计算中点、进行分支跳转要快得多。

• 对于一个长度为 15 的 int[] 查找某个数，底层的操作是一个简单循环，而不是我们熟悉的 mid = (low + high) / 2。
• 这个阈值并不公开，不同 JDK 版本可能会调整。你不需要，也不应该硬编码依赖它。
• 所以，对于几十个元素的配置数组或枚举缓存，用 binarySearch 没问题，但别期待“二分加速”，因为二分本来就没启动。

大数组才真正二分，但防溢出和边界逻辑很较真

当数组长度足够大的时候，binarySearch 才会真正启动标准的二分查找，但它的实现比教科书更严谨：

• 中点计算用的是 low + (high - low) / 2，而不是 (low + high) / 2。这是为了避免索引值超出 int 范围（比如数组长度接近 2³¹ 时）。
• 循环条件是 low <= high，确保即使是单元素区间也能被检查到，不会漏掉 arr[0] 或 arr[n-1]。
• 当查不到目标时，返回值是 -(insertion point) - 1，而不是简单的 -1。这个负数自带位置信息，按位取反（~result）就能还原出插入索引。

不校验排序，错得静默且不可预测

这是最容易被忽视的一个坑：binarySearch 完全不检查你传进来的数组是否真的有序。它默认你已经排好了，直接开搜。

• 一个乱序的数组，可能返回一个正数，但这个索引对应的值根本不是你要找的。
• 也可能返回一个负数，但 -(insertion point) - 1 的语义已经失效，因为“插入点”在无序的前提下毫无意义。
• 它不会抛出异常，不打日志，也不给任何警告。错误的结果由你的代码默默承担，线上排查时往往绕了一大圈，才回到排序这一步。

返回值不是布尔值，而是带语义的整数

理解这个返回值，才是真正用好 binarySearch 的关键：

• ≥ 0：找到了，值就是索引。但要注意，它不保证是最左或最右的重复元素位置。
• < 0：没找到，值 = -(应插入位置) - 1。举个例子，在 [1,3,5,7] 里查 4，返回 -3，这意味着插入点是 2（即放在索引 2 处），计算一下：~(-3) == 2。
• 空数组查任意值，固定返回 -1。因为插入点恒为 0，-(0)-1 = -1。

对象数组和原始类型不能混用

int[] 和 Integer[] 对应的是完全不同的重载方法，Ja va 不会自动帮你转换：

• 传一个 int[] 却调用 binarySearch(Object[], Object) → 编译直接报错。
• 传一个 Integer[] 却调用 binarySearch(int[], int) → 同样编译失败。
• Integer[] 版本涉及装箱/拆箱操作，在百万级数据量下，性能比 int[] 慢 3 到 5 倍。在性能敏感的场景里，务必选对重载。