Performance & Optimization

JMH is the Java Microbenchmark Harness, an official tool for measuring how fast small pieces of Java code run. It's better than manual nanoTime loops because the JVM warms up and optimizes code over time, and JMH handles that warmup and the JIT effects so your numbers are trustworthy.

Dead-code elimination is when the JVM deletes code whose result is never used. In a benchmark, if you compute something but never use the value, the JIT may delete the work, so the benchmark times nothing and reports an impossibly fast result.

@Warmup runs the code to get the JVM up to speed and throws those numbers away. @Measurement runs it again and keeps those numbers. You set how many rounds (iterations) and how long each round lasts (time).

The JVM starts running code interpreted and only compiles hot code to fast machine code after it runs many times. If you measure the first runs, you measure slow startup, not the real speed. Warmup runs the code first so the fast version is in place before timing.

A sampling profiler peeks at what the program is doing every so often and adds up where it spends most time. An instrumentation profiler adds extra code to every method to count and time every single call exactly, which is more accurate but much slower.

Autoboxing converts a primitive (like int) into its wrapper object (Integer) automatically; unboxing does the reverse. Each box can allocate a new object, which costs memory and creates garbage. In tight loops that adds up and slows things down.

Lazy initialization means you delay creating an object until the first time it is actually needed, instead of creating it up front. You use it when the object is expensive to build and might never be used.

It means don't make code faster before you know it's slow. First write clear, correct code, then measure where the real slowness is, and only optimize that part. Guessing usually wastes effort and hurts readability.

Strings in Java can't be changed, so each += makes a brand-new String by copying all the characters so far plus the new ones. Doing that every loop turn means you copy more and more text, so the total work grows much faster than the number of loops.

Integer.valueOf caches small Integer objects from -128 to 127 and reuses them. So two boxed 100s are the same object (== is true), but two boxed 1000s are different objects (== is false). Use .equals() to compare values, not ==, which compares object identity.

jcmd is a JDK command-line tool that sends diagnostic commands to a running JVM. Instead of separate tools, one tool can dump the heap, print threads, run GC, show flags, and more. It's safer and unified, so it replaces jmap and jstack.

Both are free GUI tools that ship with (or pair with) the JDK to watch a live Java program: heap memory, garbage collection, thread count and CPU. jconsole is the minimal built-in monitor; VisualVM does more, including CPU/memory profiling and dumps.

jmap is a JDK command-line tool that inspects a running Java program's heap (its object memory). Its two main uses are printing a histogram of how many objects of each class exist, and dumping the whole heap to a file for offline analysis.

jstack is a JDK command-line tool that prints a thread dump: a snapshot of every thread in a running Java process and what line of code each one is currently executing. You use it when an app hangs, is frozen, or is using too much CPU.

Run 'jcmd <pid> Thread.print' to print every thread's stack. To diagnose a hang look for BLOCKED threads and deadlocks; for high CPU look for RUNNABLE threads stuck in the same code across several dumps.