“总线级开销”不适用于Java方法调用，因其发生在JVM软件层，不触发CPU外部总线操作；性能差异实际源于字节码类型、JIT内联能力及对象分配，而非硬件总线。
直接调用与方法引用在总线级开销上并无实质差异——它们都不涉及硬件总线操作。
为什么“总线级开销”这个说法不适用
Java 运行在 JVM 之上，所有方法调用（包括直接调用、静态调用、Lambda 表达式、方法引用）最终都编译为字节码指令（如 invokevirtual、invokestatic、invokedynamic），由 JVM 解释或 JIT 编译为本地机器码执行。这些过程发生在软件抽象层，不直接触发 CPU 外部总线（如前端总线 FSB、内存总线、PCIe 总线）的数据传输。
所谓“总线级开销”，通常指跨芯片通信（如 CPU ↔ 内存控制器 ↔ DDR 颗粒）、设备 I/O（如网卡 DMA 触发总线读写）等物理层级行为。而 Java 方法调用本身不产生这类信号。
真正影响性能的关键层级是 JVM 指令与运行时机制
对比应聚焦在字节码生成、JIT 优化能力、对象分配与内联可行性上：
- 直接调用（如 obj.doWork()）：生成标准 invokevirtual 指令；JIT 在热点代码中极易内联，尤其对 final 方法或单实现类，消除调用开销近乎为零。
- 方法引用（如 String::length）：编译为 invokedynamic 指令（首次链接时解析目标方法）；后续调用经 JVM 优化后，常被降级为等效的 invokevirtual 或直接内联，实际开销与直接调用趋同。
- Lambda 表达式（无捕获）：JVM 通常复用单例对象，避免重复分配；有捕获时需构造闭包对象，带来堆分配与 GC 压力——这是比“调用指令”更显著的开销来源。
- 反射调用（非本题但易混淆）：才真正引入可观开销——需动态查找 Method 对象、权限校验、JNI 跳转、取消内联保护；但它和“方法引用”本质不同，不可混为一谈。
实测可观察的差异点（非总线，而是运行时行为）
可通过 JMH + -XX:+PrintAssembly（配合 hsdis）验证以下现象：
- 简单方法引用（如 Integer::compareTo）在循环中被 JIT 内联后，汇编代码与直接调用完全一致；
- 若方法引用指向未优化的默认方法或接口多实现分支，JVM 可能保留虚调用桩，略微增加分支预测失败概率；
- parallelStream().map(Foo::bar) 中的方法引用，在 ForkJoinPool 线程间传递时，不产生额外序列化或跨核缓存同步开销——它只是轻量函数描述符，不是数据搬运。
结论：不必担心“总线”，要关注是否可内联、是否触发分配
方法引用不是运行时新机制，而是编译期语法糖，其字节码和运行时行为已被 JVM 高度优化。只要目标方法稳定、可见性明确、无复杂捕获，它的执行效率与直接调用基本持平。真正的性能瓶颈往往来自数据结构设计、流式计算的中间对象创建、或不当的 parallelStream 使用，而非调用形式本身。
