Java Memory Options You Need in Production
JVM memory tuning can be tricky. Teams increase -Xmx and assume the problem is solved. Then the app still hits OOM.
Because maximum heap size is not the only thing that affects memory footprint.
The JVM uses RAM for much more than heap: metaspace, thread stacks, JIT/code cache, direct buffers, and native allocations. That’s why your process can run out of memory while heap still looks “fine”.
In this video, we break down how JVM memory actually works and how to control it with a minimal, production-safe set of flags. We cover heap sizing (-Xms, -Xmx), dynamic resizing, direct memory (-XX:MaxDirectMemorySize), and total RAM limits (-XX:MaxRAMPercentage) — especially in containerized environments (Docker/Kubernetes).
We also explain GC choices (G1, ZGC, Shenandoah), when defaults are enough, and why GC logging (-Xlog:gc*) is mandatory before tuning. Finally, we show how to diagnose failures with heap dumps and OOM hooks.
This is not about adding more flags. It’s about understanding what actually consumes memory — and making decisions you can justify in production.
00:00 — JVM Memory Tuning Is Misleading
00:17 — Heap Size Options (-Xms, -Xmx)
02:10 — RAM Consumption Beyond Heap
02:56 — GC Selection (G1, ZGC, Shenandoah)
03:44 — GC Logging (-Xlog:gc*)
05:48 — GC Management (Threads, Ratios)
07:05 — How to handle OutOfMemoryError
08:22 — Other useful parameters
09:22 — Conclusion: What Actually Matters
Java Memory Options PDF: https://bell-sw.com/assets/files/jvm_...
Prefer reading? Here's the article: https://bell-sw.com/blog/guide-to-jvm...