NOTE
JVM Performance Tuning Methodology
A hypothesis-driven performance tuning workflow from SLO and bottleneck identification through measurement, change, and regression validation.
This is a historical learning note and may contain outdated or incomplete understanding.
1. Define the Target
A tuning exercise needs a measurable target: p99 latency, throughput, CPU efficiency, memory footprint, pause budget, or startup time.
2. Find the Limiting Resource
Measure before tuning. The bottleneck may be application code, lock contention, allocation/GC, database latency, network I/O, disk, thread pools, connection pools, or container CPU/memory limits.
3. Build a Hypothesis
Examples:
- allocation rate drives frequent young collections;
- one lock serializes request processing;
- an unbounded queue hides overload and inflates latency;
- retained cache entries grow the live set.
Collect evidence specifically for the hypothesis.
4. Apply the Smallest Change
Prefer fixing workload/data-structure/concurrency behavior before manipulating obscure JVM knobs. Change one major variable at a time so causality remains visible.
5. Validate and Regress
Compare before/after behavior under representative load and over sufficient duration. Check not only the target metric but CPU, memory, error rate, and tail behavior. Keep a rollback path.