JMH不能直接测分支预测率或高并发控制结构吞吐绝对值，只能测特定并发配置下代码的可观测性能表现；需通过可控实验设计分离吞吐与分支行为影响，并用perf等硬件工具交叉验证。
jmh本身不能直接测出分支预测率，也不能单独给出“高并发控制结构”的吞吐量绝对值——它测的是你写的那段代码在特定并发配置下的可观测性能表现。关键在于：用可控实验设计把“吞吐”和“分支行为影响”拆开看，再结合硬件工具交叉验证。
测吞吐：明确线程模型与共享状态
高并发控制结构（比如自旋锁、CAS重试循环、分段锁Map）的吞吐能力，取决于线程如何争抢资源。JMH必须显式声明这个模型：
- 用@State(Scope.Benchmark)让所有线程操作同一个实例，模拟真实竞争场景；若误用Scope.Thread，就变成单线程吞吐，结果完全失真
- 用@Threads(N)指定N个线程持续并发执行，不是N次串行调用；结果单位是ops/s（整体吞吐），不是单次耗时
- 搭配@Fork(jvmArgsAppend = {"-Xmx2g", "-XX:+UseParallelGC"})固定堆与GC策略，避免内存抖动污染吞吐数据
测分支影响：构造可比的预测压力梯度
分支预测失效不会单独计时，但会让CPU流水线停顿，最终反映在吞吐下降或平均延迟升高上。你需要人为制造不同预测难度：
- 在@State类中定义@Param({"0","10","50","90","100"})，代表条件分支的“偏向比例”（如
if (random.nextInt(100) < bias)） - 确保分支结果被实际使用（例如累加到返回值），否则JIT会优化掉整个if块
- 保持其他逻辑完全一致，只让分支可预测性变化——这样吞吐差异才能归因于预测失败开销
结果解读：吞吐差 ≠ 预测率，但能定位瓶颈
运行后观察Throughput模式下的ops/s变化：
- bias=0 和 bias=100 时吞吐接近且最高 → 分支高度可预测，预测器工作良好
- bias=50 时吞吐明显下降（常降20%~50%）→ 预测器频繁失败，流水线冲刷带来可观测惩罚
- 该吞吐损失是分支预测失效引发的综合代价（含重取指令、寄存器回滚等），不是预测率数值本身
交叉验证：用perf确认硬件层事实
JMH给出的是JVM层现象，要确认是否真是分支预测问题，需在Linux下配合perf采集：
perf stat -e branches,branch-misses java -jar your-bench.jar- 计算branch-misses / branches得到真实预测失败率
- 若JMH中bias=50时吞吐骤降，且perf显示此时branch-misses比率同步飙升，则因果关系成立
