What is JMH, and why should you use it instead of hand-rolled timing with System.nanoTime() loops for Java microbenchmarks?

## What a microbenchmark is A *microbenchmark* measures the speed of a very small piece of code — a single method, a loop body, one operation — rather than a whole program. The goal is to answer questions like "is approach A faster than approach B for this one operation?" ## Why this is hard on the JVM The **JVM (Java Virtual Machine)** is not a simple interpreter; it is a dynamic, adaptive runtime. Several of its behaviors make naive timing wrong: - **JIT compilation & warmup.** Java code first runs *interpreted* (slow), and only after a method or loop becomes "hot" (executed thousands of times) does the **JIT (Just-In-Time) compiler** compile it to optimized machine code. The first measurements are therefore measuring the interpreter, not the optimized code you care about. The period of running until performance stabilizes is called **warmup**. - **Dead-code elimination (DCE).** The optimizer removes computations whose results are never used. If your benchmark computes `Math.log(x)` and throws the result away, the JIT may delete the call entirely — you'd measure nothing. - **Constant folding.** If an input is a compile-time or provably-constant value, the optimizer can precompute the answer once, so your loop measures nothing. - **On-stack replacement (OSR).** The JVM can swap a still-running interpreted loop for a compiled version mid-flight, producing measurements from artificially-shaped code that never occurs in real call sites. - **GC and background compilation noise** add variance. A hand-written `long t = System.nanoTime(); for (...) { work(); } long elapsed = System.nanoTime() - t;` ignores all of this and routinely produces numbers that are off by orders of magnitude or measure the wrong thing. ## What JMH is **JMH = Java Microbenchmark Harness.** It is the benchmarking framework maintained by the same OpenJDK engineers who build the JVM, precisely because they understand these pitfalls. You write a benchmark by annotating a method with **`@Benchmark`**; JMH's **annotation processor** generates boilerplate "harness" code at build time that runs your method correctly. ## How JMH defends correctness - **Warmup iterations** run your code (results discarded) until the JIT has compiled and stabilized it; only then does it run **measurement iterations**. - **Forking:** each trial runs in a *fresh JVM process* so one benchmark's compilation profile can't pollute another's. - **Blackhole / return-value consumption:** returning a value from `@Benchmark` (or passing it to a `Blackhole`) tells JMH to *consume* it so the JIT cannot dead-code-eliminate the work. - **State objects** (`@State`) hold inputs in a way the optimizer can't constant-fold. - **Statistics:** JMH aggregates many iterations across many forks and reports a score with error/confidence, not a single lucky number. ## When NOT to use it JMH is for *micro* benchmarks (sub-millisecond to millisecond operations). For end-to-end/application throughput you'd use load-testing tools instead. But for "which of these two implementations of a hot method is faster," JMH is the standard answer.