字节码比源码更真实反映 Arrays 行为，因 JDK 对 sort、binarySearch 等方法做了底层优化；常量池与方法签名可揭示编译器内联、泛型擦除及阈值判断等细节。
直接看字节码，比读源码更接近 Arrays 的真实行为。JDK 对 Arrays 中的 sort、binarySearch、copyOf 等静态方法做了大量底层优化，而这些优化在源码里常被封装或抽象掉，只有字节码能暴露 JVM 实际执行路径和编译器干预痕迹。
盯住常量池与方法签名，识别编译器内联与泛型擦除痕迹
反编译后若看到类似 Arrays.sort(Object[], int, int) 调用却没对应方法体，说明该调用大概率被 javac 或 JIT 内联了；再查常量池中 MethodRef 条目，若指向 java/util/Arrays.sort 但实际字节码中无 invokestatic 指令，而是直接展开为 if_icmpge、iaload 等原生指令——这就是编译器对小数组排序做的“去方法调用”优化。泛型方法如 asList(T...) 反编译后只剩 Object[]，但常量池里仍保留 Signature 属性，可据此还原原始泛型边界。
对照LineNumberTable，定位分支逻辑的真实触发点
Arrays.sort 在 JDK 7+ 后采用双轴快排 + 归并混合策略，阈值判断（如 length ）是否走插入排序，不靠 if 语句写死，而由 JVM 根据运行时数据特征动态选择。反编译代码里看似线性流程，但查看 <code>LineNumberTable 会发现同一行 Java 源码（比如 sort(a)）对应多段字节码区间，每段前都有不同条件跳转指令（if_icmplt、goto）。这些跳转目标地址在反编译输出中常被“平铺”，掩盖了真实控制流分叉——必须结合行号表回溯，才能确认哪个分支对应小数组优化、哪个走并行分支（parallelSort）。
追踪 System.arraycopy 的调用链，看清 copyOf 的零拷贝本质
Arrays.copyOf 表面是新建数组再复制，但字节码里几乎不出现循环赋值指令。它最终总归于一条 invokestatic java/lang/System.arraycopy。这个本地方法在 HotSpot 中有特殊处理：当源数组与目标数组类型兼容且内存连续时，JVM 直接调用 memmove 或 CPU 的向量化指令（如 rep movsb），完全绕过 Java 层循环。反编译工具若未开启 -nls（禁用语法糖转换），可能把 arraycopy 错误还原为 for 循环，造成“假优化”错觉。务必检查字节码原始指令，确认是否存在 invokestatic #System.arraycopy，而非 iload/astore 组合。
立即学习“Java免费学习笔记（深入）”；
比对不同 JDK 版本的字节码，捕捉 JIT 预热带来的指令级差异
同一个 Arrays.binarySearch 方法，在 JDK 8 和 JDK 17 的 class 文件中，方法体长度可能相差 30% 以上。原因在于：JDK 9+ 启用 G1 GC 后，binarySearch 的边界检查（index >= 0 && index ）被 JIT 编译为带 <code>deoptimize 的快速路径，而字节码层仍保留完整校验逻辑。此时反编译结果看似冗余，实则是为运行时优化留出的“钩子”。用 jclasslib 打开 class 文件，对比 Code 属性中的 max_stack 和 max_locals，数值越小往往代表编译器优化越激进（如消除临时变量、折叠计算）。
