Arrays.binarySearch要求数组必须升序排序，否则结果未定义；小数组（如JDK8中长度<21）采用线性扫描提升性能，大数组才启用防溢出的二分查找，未找到时返回-(插入点+1)。
Java 中 Arrays.binarySearch 并不是简单地“调用二分查找”，它背后有一套兼顾性能与兼容性的实现逻辑：对小数组用线性扫描，对大数组才真正启用二分；同时严格要求输入数组必须已升序排序，否则结果无定义。
底层并非纯二分：小数组走线性扫描
源码中会先判断数组长度 —— 若长度小于某个阈值（JDK 8 中是 21），直接使用循环遍历。这是因为现代 CPU 的分支预测和缓存局部性让短距离线性扫描比反复计算中点、比较、跳转更快。
- 例如长度为 10 的数组，
binarySearch实际执行的是 for 循环，而非 mid = (low + high) / 2 的迭代 - 这个阈值不对外暴露，属于 JVM 实现细节，不同 JDK 版本可能微调
大数组才进入标准二分流程，但边界处理很严谨
当数组足够长时，它才启用经典二分逻辑，但关键细节在于：
- 使用 low + (high - low) / 2 计算中点，避免
low + high整数溢出（尤其在操作大索引数组时） - 循环条件是 low <= high，确保单元素区间也能被检查
- 查不到时返回 -(insertion point) - 1，即负的“应插入位置减 1”，方便区分未命中与索引 0 的情况
不校验排序性，出错静默且不可预测
Arrays.binarySearch 完全不验证数组是否有序。若传入乱序数组：
立即学习“Java免费学习笔记（深入）”；
- 可能返回错误的索引（比如找到一个值，但它不是第一次出现的位置）
- 可能返回负数，但该负数不代表真实插入点（因为二分前提已被破坏）
- 不会抛异常，也不会警告 —— 错误由调用方承担
重载方法多，但核心逻辑一致
无论是 int[]、Object[] 还是带 Comparator 的版本，主干逻辑相同：
- 小数组线性扫描 → 大数组安全二分 → 未找到按规则返回负值
- 对象数组版本依赖
equals()和compareTo()（或传入的Comparator），但比较次数和分支路径与基本类型版一致 - 所有重载都要求“自然有序”或“按指定 Comparator 有序”，否则行为未定义
