Week 23: JVM Performance Tuning & Virtual Threads

1. Heap, GC Algorithms & Reading a GC Log

The JVM heap is split into generations on the assumption most objects die young: a small young generation (further split into Eden and two Survivor spaces) where new objects are allocated and collected frequently and cheaply, and a larger old generation for objects that survive several young collections, collected less often but at higher cost per collection. Java 21's default collector, G1, is a good default for most Spring Boot services — it targets a configurable maximum pause time rather than optimizing purely for throughput.

java -Xlog:gc*:file=gc.log:time,uptime,level,tags -jar app.jar

[12.451s][info][gc] GC(14) Pause Young (Normal) (G1 Evacuation Pause)
    252M->38M(512M) 18.2ms

That single line says a lot: before this collection the heap held 252MB of live objects, after it only 38MB remained live (meaning ~214MB of garbage was reclaimed), out of a current total heap size of 512MB, and the whole pause — during which application threads mostly stop — took 18.2ms. A healthy service shows young collections like this fairly frequently but briefly; the two patterns actually worth worrying about are collections growing steadily longer over time (a possible memory leak, since a genuinely leaking heap has more and more live data to scan each time) and old-generation ("Mixed" or "Full") collections happening frequently, which are far more expensive and usually mean the heap is undersized for the actual working set.

2. Thread Dumps, Heap Dumps & Profiling a Live Service

When a service feels stuck — requests hanging, CPU pegged, or just "slow" with no obvious cause in the logs — a thread dump is the fastest way to see exactly what every thread is doing at that instant, without adding any instrumentation ahead of time.

jcmd <pid> Thread.print > threads.txt

# or, if actuator's threaddump endpoint is exposed (Week 12):
curl localhost:8080/actuator/threaddump

"http-nio-8080-exec-7" #47 daemon prio=5 tid=0x... nid=0x... waiting on condition
   java.lang.Thread.State: WAITING (parking)
	at java.base/jdk.internal.misc.Unsafe.park(Native Method)
	at java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:211)
	at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:XXX)
	at com.codeverse.week23.TaskService.findTask(TaskService.java:42)

A single thread waiting is normal. Twenty request-handling threads all WAITING at the exact same HikariPool.getConnection line is a specific, actionable finding — it says the connection pool (Week 11) is exhausted, not that "the service is slow" in some vague sense. Comparing two thread dumps taken a few seconds apart is even more telling: threads stuck at the identical stack trace in both dumps are genuinely blocked, not just caught mid-execution by coincidence.

A heap dump answers a different question — not what threads are doing, but what's actually consuming memory:

jcmd <pid> GC.heap_dump heap.hprof

Opened in a tool like Eclipse MAT or VisualVM, a heap dump's "dominator tree" shows exactly which objects are retaining the most memory and, critically, why they're still reachable — a static collection that keeps growing without ever evicting entries is one of the most common real memory leaks in a long-running Spring Boot service, and a heap dump is what turns "memory keeps climbing" into "this specific cache, growing unbounded, is the cause."

3. Java 21 Virtual Threads

Week 14 framed the choice between Spring MVC's thread-per-request model and WebFlux's reactive model as a fundamental tradeoff: blocking, easy-to-read code that doesn't scale to very high concurrency, versus non-blocking, harder-to-read code that does. Virtual threads, stable since Java 21, change one side of that tradeoff directly. A virtual thread is a JVM-managed thread that's extremely cheap to create (thousands can exist where a few hundred platform threads would exhaust memory) and, critically, unmounts from its underlying OS thread automatically while blocked on I/O — the OS thread is freed for other work during the wait, then a virtual thread (not necessarily the same OS thread) resumes it when the I/O completes.

spring.threads.virtual.enabled=true

With that single property, ordinary Spring MVC request-handling threads become virtual threads — no code changes anywhere. The Week 3 blocking controller and the Week 4 JPA repository call inside it are entirely unchanged:

@GetMapping("/{id}")
TaskResponse getTask(@PathVariable Long id) {
    return toResponse(taskRepository.findById(id)          // still a blocking call
        .orElseThrow(TaskNotFoundException::new));
}

What's different is what happens while that call blocks waiting on the database: instead of tying up one of a small, fixed platform thread pool for the whole wait (the original thread-per-request cost Week 14 described), the virtual thread parks and releases its carrier OS thread, which is immediately free to run other virtual threads. The result is thread-per-request's simple, blocking programming model with much closer to WebFlux's concurrency characteristics — without rewriting a single controller or repository as reactive code.

4. Hands-on Exercise

5. Knowledge Check

Three quick questions. Expand each to check your answer.