jmh不能直接测分支预测率，需用perf等工具采集branch-misses/branches计算；但可通过@param构造不同确定性比例的分支场景，分离并观测预测开销对吞吐量的影响。
JMH本身不能直接测出分支预测率，它只能测出高并发控制结构在不同分支模式下的吞吐量差异；而分支预测率属于CPU微架构行为，必须用perf等硬件性能计数器工具采集branch-misses/branches才能算出真实值。但你可以用JMH配合流程控制，科学地把分支预测开销从整体耗时中“分离”出来，再结合外部工具交叉验证。
用@Param构造可比的分支压力场景
关键不是“测预测率”，而是让不同预测难度的分支逻辑产生可观测的吞吐差异：
- 定义
@Param({"0", "25", "50", "75", "100"})，代表分支走向的确定性比例（如i % 100 ） -
0和100是高度可预测分支（几乎总走同一路径），50是随机跳转，预测失败率最高 - 分支结果必须被实际使用：返回值、写入
@State字段，或传给Blackhole.consume()，否则JIT会优化掉整个if块
配置多线程吞吐测试，排除干扰
并发吞吐量（ops/s）才是反映分支预测失效放大效应的关键指标：
- 用
@BenchmarkMode(Mode.Throughput)，单位为ops/s，不是单次耗时 - 搭配
@Threads(4)或@Threads(8)，模拟真实竞争压力；注意@State(Scope.Benchmark)确保所有线程共享被测对象（如锁、并发队列） - 预热要充分：
@Warmup(iterations = 5, time = 3, timeUnit = TimeUnit.SECONDS)，让JIT稳定、分支预测器“热起来” - JVM参数加
-XX:+UseParallelGC -Xmx2g，避免GC抖动污染吞吐数据
用perf采集真实分支预测率，与JMH结果对齐
JMH跑完后，拿到各branchBias下的吞吐数值，再用系统级工具验证底层原因：
- 在相同代码+相同JVM参数下，用
perf stat -e branches,branch-misses,cache-references,cache-misses -- ./jmh.sh运行基准 - 计算分支预测失败率：
branch-misses / branches * 100%，典型值：可预测分支 - 对比发现：当
branchBias=50时吞吐下降明显，且branch-misses飙升——就能确认性能损失主因是分支误预测，而非内存或锁竞争
规避常见误读陷阱
很多人把吞吐下降直接等同于“预测率低”，其实中间隔着JIT优化、流水线停顿、指令重排等多层影响：
- 不要禁用C2编译器（如
-XX:-TieredStopAtLevel=1）来“简化”环境，那测的是退化模型，不是生产现实 - 不推荐用
Mode.AverageTime分析分支影响，因为单次耗时受缓存、TLB、乱序执行干扰太大；Mode.Throughput更稳定、更具业务意义 - 如果吞吐在
branchBias=50时未明显下降，说明你的分支逻辑太轻（如只是赋值），或被JIT进一步优化（如条件移动指令cmov），需加重计算负载（如嵌套循环、数组访问）提升敏感度
