Hur optimerar du prestanda i JVM-applikationer?

Question

Accepted Answer

Optimering av JVM-applikationer omfattar **profilering** för att hitta flaskhalsar, **JVM/GC-justering**, **kodnivaförbättringar** och att utnyttja JIT-kompilatorn. Som alltid gäller regeln: **mät först, optimera den bevisade flaskhalsen** — gissa aldrig.

## Profilera innan du optimerar

```text
Tools:
  ✓ JProfiler / YourKit / VisualVM — CPU & memory profiling, hotspots
  ✓ Java Flight Recorder (JFR) + Mission Control — low-overhead production profiling
  ✓ async-profiler — flame graphs for CPU/allocation
  ✓ heap dumps + Eclipse MAT — memory leak analysis
```

Profilering avslöjar *var* tid och minne faktiskt går, så du fixar de verkliga 20% som spelar roll istället för att mikrooptimera irrelevant kod.

## JIT-kompilatorn arbetar för dig

```text
The JVM's JIT (Just-In-Time) compiler identifies "hot" frequently-run code and
compiles it to optimized native machine code at runtime (with inlining, etc.).
→ Java often approaches native speed for hot paths after warm-up.
→ Implication: benchmark AFTER warm-up; let the JIT optimize before measuring.
```

## GC-justering

```bash
# choose a collector appropriate to the workload, size the heap
java -Xms2g -Xmx2g \          # set heap size (avoid resizing; -Xms = -Xmx)
     -XX:+UseG1GC \           # G1 (balanced, default) — or ZGC for low pause
     -XX:MaxGCPauseMillis=200 \
MyApp
```

```text
✓ Right-size the heap (too small → frequent GC; too large → long pauses)
✓ Pick the GC for your goal: G1 (balanced), Parallel (throughput), ZGC (low latency)
✓ Reduce allocation churn — fewer short-lived objects = less GC pressure
```

## Kodnivaförbättringar

```text
✓ Better algorithms & data structures — biggest wins (HashMap O(1) vs list O(n))
✓ Avoid unnecessary object creation (esp. in loops; reuse, use primitives over wrappers)
✓ Use StringBuilder for string building in loops (not + concatenation)
✓ Minimize autoboxing (Integer vs int) in hot paths
✓ Cache expensive results; use connection/thread pools
✓ Lazy initialization for costly objects not always needed
✓ Reduce I/O round-trips; batch database queries (avoid N+1)
```

## Databasen är ofta den riktiga flaskhalsen

```text
For server apps, the slow part is frequently DB queries (N+1, missing indexes) or
network I/O — NOT Java code. Profiling reveals this so you fix the true cause.
```

## Undvik förhastande optimering

```text
"Premature optimization is the root of all evil." Write clear, correct code first;
profile under realistic load; then optimize the measured hotspots specifically.
```

## Varför det är viktigt

Optimering av JVM-prestanda har högt värde men måste vara **disciplinerad och mätningsdriven** — gissningar slösar bort insats och lägger till komplexitet.

Det är viktigt att känna till hela verktygskistan: profilerar (JFR, async-profiler) för att lokalisera verkliga flaskhalsar; förståelse för JIT (som optimerar varm kod vid körning, så benchmarks behöver uppvärmning); GC-justering (heapstorlek och val av samlare — G1/ZGC — för att balansera genomströmning mot pausvaraktighet); och kodnivavinster (bättre algoritmer/datastrukturer, minskad allokering och autoboxing, pooling, batchbearbetning).

Igenkännandet av att flaskhalsen ofta är **databasen eller I/O**, inte Java-kod, fokuserar insatsen korrekt.

Denna kombination — profilera först, justera JVM och GC på lämpligt sätt, optimera bevisade hotspots och undvik förhastande mikrooptimering — är det som håller stora JVM-applikationer snabba och skalbara, och återspeglar expertis på seniornivå inom drift.