Concurrency and the JVM

A leak shows as a rising floor. Each GC reclaims less. The live set climbs toward the max heap. Full GCs free little, and then an OOM happens. A flat floor (even with frequent minor GCs) is healthy churn, not a leak.

Source: https://docs.oracle.com/en/java/javase/21/troubleshoot/troubleshooting-memory-leaks.html

The format is before->after(total). 820M was in use before the GC. The GC reclaimed memory down to 410M. The total heap is 1024M. If you track the 'after' value over time, you see the live-set trend.

Source: https://docs.oracle.com/en/java/javase/21/docs/specs/man/java.html#enable-logging-with-the-jvm-unified-logging-framework

A leak fills any heap. If you raise -Xmx, the crash happens later and the pause times increase. The fix is to stop retaining objects (bounded caches, remove listeners, close resources).

Source: https://docs.oracle.com/en/java/javase/21/troubleshoot/troubleshooting-memory-leaks.html

GC logs only cover the managed heap. Suppose the live set is flat but RSS grows. Then suspect off-heap, direct, or native memory (common with Netty, Flink managed memory, mmap).

Source: https://docs.oracle.com/en/java/javase/21/gctuning/introduction-garbage-collection-tuning.html

ExecutorService pools and reuses threads, returns Futures for results, and bounds concurrency. This is much safer than new Thread() for each task, which can exhaust resources.

Source: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/ExecutorService.html

Java has no GIL. Threads execute concurrently on multiple cores. You must protect shared mutable state (synchronized/atomic/concurrent collections). Otherwise the results are non-deterministic.

Source: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/package-summary.html

A flat floor means that objects die young. This is healthy. Frequent minor GCs only reflect a high allocation rate. The fix is to allocate less (reuse buffers, avoid per-record garbage). Do not grow the heap.

Source: https://docs.oracle.com/en/java/javase/21/gctuning/introduction-garbage-collection-tuning.html