Performance tuning JVM bez mitów

Optymalizacja wydajności aplikacji Java od lat owiana jest mitami: „więcej RAM = szybciej”, „zmień GC i wszystko będzie dobrze”, „dodaj więcej wątków”. W praktyce performance tuning JVM to inżynieria oparta na pomiarach, a nie na magicznych flagach startowych.

W tym artykule obalamy popularne mity i pokazujemy, co naprawdę działa w 2026 roku.

Mit 1: „Wystarczy zmienić Garbage Collector”

JVM oferuje kilka GC (G1, ZGC, Shenandoah), ale zmiana GC bez zrozumienia problemu rzadko rozwiązuje go sama z siebie.

Najczęstsze prawdziwe przyczyny problemów:

• nadmiar alokacji obiektów,
• wycieki pamięci,
• zbyt duże struktury danych w heapie,
• blokujące operacje I/O.

Przykład: nadmierna alokacja

public String process(String input) {
    return input.toUpperCase() + "_" + System.currentTimeMillis();
}

Wywoływane tysiące razy na sekundę tworzy ogromną liczbę obiektów String.

Lepsze podejście:

StringBuilder sb = new StringBuilder(input.length() + 20);
sb.append(input.toUpperCase()).append("_").append(System.currentTimeMillis());
return sb.toString();

Najpierw optymalizuj kod, potem GC.

Mit 2: „Więcej pamięci = większa wydajność”

Zwiększenie -Xmx:

• zmniejsza częstotliwość GC,
• ale wydłuża czas pauz GC,
• może pogorszyć latencję.

Zbyt duży heap:

• maskuje wycieki pamięci,
• utrudnia debugowanie,
• zwiększa cold start.

Dobra praktyka: dobieraj heap na podstawie metryk, a nie intuicji.

Mit 3: „Thread pool 500 wątków przyspieszy aplikację”

Więcej wątków ≠ więcej wydajności.

ExecutorService executor = Executors.newFixedThreadPool(500);

Jeśli aplikacja jest CPU-bound:

• 500 wątków tylko zwiększy przełączanie kontekstu,
• realna wydajność spadnie.

Dla I/O-bound lepszym rozwiązaniem są:

• Virtual Threads (Java 21+),
• asynchroniczne API.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> service.call());
}

Mit 4: „Profilowanie to strata czasu”

Bez profilowania:

• nie wiesz, co naprawdę jest wolne,
• zgadujesz zamiast mierzyć.

Podstawowe narzędzia:

• Java Flight Recorder (JFR),
• JVisualVM,
• async-profiler,
• Micrometer + Prometheus.

Przykład: mierzenie czasu metody

long start = System.nanoTime();
service.process();
long end = System.nanoTime();
System.out.println("Time: " + (end - start));

Lepsze: metryki systemowe zamiast ręcznych logów.

Co naprawdę wpływa na wydajność JVM?

1. Architektura aplikacji

• liczba zapytań do DB,
• synchronizacja,
• sposób cache’owania,
• granice mikroserwisów.

2. Alokacje obiektów

Im mniej obiektów tworzysz:

• tym mniej pracy dla GC,
• tym niższe opóźnienia.

3. I/O i sieć

Najczęstszy bottleneck to:

• baza danych,
• API zewnętrzne,
• system plików.

Nie JVM jest wolna – tylko integracje.

Realne techniki tuningowe (bez magii)

✔ Profiluj przed optymalizacją

Zbieraj:

• CPU,
• heap,
• GC pauses,
• thread dumpy.

✔ Mierz percentile, nie średnią

Nie:

avg response = 200ms

Tylko:

p95 = 1.8s
p99 = 3.2s

✔ Uprość kod krytycznych ścieżek

List<User> users = repository.findAll();
users.stream()
     .filter(u -> u.isActive())
     .forEach(this::process);

Jeśli lista ma 1 mln rekordów – problemem jest DB, nie stream.

GC w 2026 – co wybrać?

Dla większości aplikacji:

• G1GC – domyślny, stabilny,
• ZGC / Shenandoah – gdy kluczowa jest niska latencja,
• Virtual Threads nie zmieniają zasad GC.

Nie zmieniaj GC bez:

• testów obciążeniowych,
• porównania metryk.

Ciekawostki

• Najlepsza flaga JVM to… usunięcie zbędnego kodu.
• Optymalizacja przed pomiarem często pogarsza wydajność.
• Nowoczesna JVM sama robi więcej optymalizacji niż ręczny tuning sprzed 10 lat.

Minimalna checklista tuningowa

• [ ] Profiling CPU i pamięci
• [ ] Analiza GC logs
• [ ] Metryki p95/p99
• [ ] Sprawdzenie DB i zewnętrznych API
• [ ] Redukcja alokacji obiektów
• [ ] Testy obciążeniowe po każdej zmianie

Oficjalne źródła i dokumentacja

• Java Performance Tuning Guide
• Java Flight Recorder
• Garbage Collectors
• Async Profiler
• Micrometer

Podsumowanie

Performance tuning JVM to nie sztuka rzucania flagami startowymi, lecz proces:

1. Mierzysz (profiling, metryki),
2. Rozumiesz (gdzie jest wąskie gardło),
3. Upraszasz (kod i architekturę),
4. Dopiero potem tunujesz JVM.

Nowoczesna Java jest bardzo szybka „out of the box”. Największe zyski wydajności w 2026 roku nie pochodzą z magii JVM, lecz z:

• dobrej architektury,
• ograniczenia I/O,
• świadomego użycia współbieżności,
• realnych pomiarów zamiast mitów.

Najlepszy tuning JVM to taki, którego nie musisz robić – bo aplikacja została dobrze zaprojektowana.