Java / Java 17 Garbage Collection Interview Questions
How do you troubleshoot frequent full GCs in a Java 17 application?
Start by enabling GC logging (-Xlog:gc*:file=gc.log:time,uptime,level,tags) if it isn't already on, and look at what's triggering each full GC - the log will show whether it's an evacuation failure, Metaspace pressure, or an explicit System.gc() call.
Next, plot old-generation occupancy over time (tools like GCEasy or GCViewer make this easy): if the baseline occupancy right after each full GC keeps climbing rather than returning to a stable floor, that's a strong signal of a real memory leak rather than just heap pressure.
If it looks like a leak, take a heap dump (jmap -dump:live,format=b,file=heap.hprof <pid>) at two points in time and compare object histograms or dominator trees in a tool like Eclipse MAT to find what's accumulating. If it isn't a leak, consider whether the heap is simply undersized for the live-data working set, whether allocation rate has spiked, or whether the current collector (especially Parallel GC or an under-provisioned G1) is a poor fit for the workload.
Finally, check for stray System.gc() calls in application or third-party library code, which can be neutralized with -XX:+DisableExplicitGC as a stopgap while the root cause is addressed.
More Related questions...