直接测基本类型运算吞吐量极限需绕过JVM优化、控制测量维度、排除死码消除和常量折叠，JMH不能给出理论极限，但可逼近当前JVM+CPU配置下的实际吞吐上限。
直接测基本类型运算的吞吐量极限，关键不是“写个加法再跑JMH”，而是要绕过JVM优化干扰、控制测量维度、排除死码消除，并让结果反映真实硬件能力。JMH本身不提供“理论极限”，但它能帮你逼近当前JVM+CPU配置下该运算的实际吞吐上限。
避免死码消除与常量折叠
基本类型运算（如 a + b、i ）极易被JVM优化掉——如果结果没被使用，JIT可能直接跳过整个计算。必须用 <code>Blackhole 消耗结果，否则测出来的是0纳秒或极低值，毫无意义。
- 引入
Blackhole：在测试方法参数中声明Blackhole blackhole，并在运算后调用blackhole.consume(result) - 不要只返回值：仅
return a + b不够，JVM可能内联并消除；必须显式消费 - 避免常量全量：不要写
int x = 1 + 2这类编译期可算尽的表达式；用@State提供运行时变量，或通过循环索引生成动态值
选择吞吐量模式并合理配置迭代
吞吐量（Mode.Throughput）是测“单位时间完成多少次运算”的唯一合适模式。它输出 ops/s（每秒操作数），数值越大代表处理能力越强。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 标注方式：
@BenchmarkMode(Mode.Throughput)，配合@Benchmark - 预热足够：至少 5 轮 warmup（每轮 1 秒），让 JIT 完成 C1/C2 编译、分支预测稳定、代码热路径固化
- 测量轮次：不少于 5 轮 measurement（每轮 ≥1 秒），保证统计有效性；短于 200ms 的单轮测量易受调度抖动影响
- 禁用 profilers：避免
-prof参数干扰计时精度；纯 CPU-bound 场景下保持 JVM 干净（如-XX:+UnlockDiagnosticVMOptions -XX:+DisableExplicitGC可选）
控制线程与状态范围以逼近硬件极限
单核吞吐极限取决于指令流水线深度、寄存器带宽和ALU数量；多核则要看并行扩展性。需明确你测的是“单核峰值”还是“N核总吞吐”。
立即学习“Java免费学习笔记（深入）”；
- 测单核极限：用
@Threads(1)，搭配@Fork(1)，并在 Linux 下绑定到固定 CPU 核（如-XX:ActiveProcessorCount=1 -XX:+UseThreadPriorities） - 测多核扩展：逐步增加
@Threads(2)、@Threads(4)等，观察 ops/s 是否线性增长；若增长停滞，说明存在共享资源瓶颈（如L1缓存带宽或寄存器重命名压力） - 状态隔离：基本运算无共享状态，用默认
@State(Scope.Thread)即可；避免Scope.Benchmark引入不必要的同步开销
结果解读与横向对比要点
JMH 输出的 ops/s 是综合指标，需结合硬件参数做合理性判断。例如，在现代x86-64 CPU上，一个简单整数加法理论上可达每周期1条指令，按4 GHz主频即约40亿 ops/s —— 实际JMH结果若达 2–3G ops/s，已属高度优化；若仅几百万，大概率是测量方式出错。
- 看
Score和误差（±）：标准差应小于均值的 5%，否则说明环境不稳定（后台进程、频率缩放、温度降频） - 对比不同运算：同一测试框架下，比较
int +、long >>、float *的 ops/s，可量化各指令相对开销 - 警惕 JVM 版本差异：Java 17+ 的向量化优化（如
Vector API预热后）可能大幅提升某些运算吞吐，务必注明 JDK 版本与 JVM 参数
