Uncovering Hidden Java Memory Leaks in Cloud‑Native Pods with SysOM Diagnostics

Background

In a previous article we analyzed hidden memory overhead in cloud‑native environments using the SysOM diagnostic system, pinpointing abnormal consumption of file cache, shared memory, and other system‑level resources at node and pod levels.

However, some memory anomalies still stem from the application process itself, especially for Java applications after migrating from traditional IDC clusters to containerized cloud‑native deployments. Users often see pods repeatedly OOM despite JVM heap limits appearing normal.

Key Challenges

Container memory vs JVM heap discrepancy: Pod memory usage can be several times larger than the JVM heap (including off‑heap), creating a “missing memory” mystery.

OS compatibility after containerization: Switching OS or container runtime can cause sudden changes in memory usage patterns.

Toolchain blind spots: Conventional Java profilers do not cover JNI memory, libc allocations, or other non‑heap regions.

Java Memory Panorama

Java memory consists of JVM heap, off‑heap (metaspace, compressed class space, code cache, direct buffers, thread stacks) and non‑JVM memory such as JNI native allocations and libc allocations. The following diagram shows the composition.

Common Java Memory Leaks

JNI native memory leaks often arise from native libraries such as ZLIB that are invoked via JNI. These allocations are not visible to standard JVM tools.

SysOM Java Memory Diagnosis Practice

We illustrate the process with a real case from an automotive customer who migrated workloads to an ACK cluster and experienced frequent OOM caused by JNI memory leaks.

Case Background

Pods hit memory limits and were OOM‑killed.

JVM metrics showed normal heap usage.

No obvious traffic spikes or request anomalies.

Investigation Steps

Trigger a full‑stack memory analysis when the pod approaches its memory limit.

Examine the SysOM diagnostic report, which includes RSS, WorkingSet, JVM memory, process memory, anonymous and file‑backed memory usage.

Identify that the process memory exceeds JVM‑reported usage by ~570 MiB, all attributable to JNI allocations.

Enable JNI memory profiling to generate a flame graph of native allocation call stacks.

Observe that the C2 compiler JIT pre‑warm phase consumes significant JNI memory.

Since no sudden pod memory spikes were found, use continuous Java CPU hotspot tracking to compare normal and high‑memory periods.

Findings

The flame graph revealed that most native allocations originated from the C2 compiler JIT. Combined with libc’s arena, top‑chunk, and bin caching mechanisms, memory was fragmented and not promptly returned to the OS, leading to inflated RSS.

Conclusion and Solutions

Tune C2 compiler parameters to adopt a more conservative compilation strategy.

Adjust the glibc MALLOC_TRIM_THRESHOLD_ environment variable to force timely memory release.

Enable JNI memory profiling and Java CPU hotspot tracking for ongoing visibility.

Summary

Systematic memory diagnostics break through the JVM black box, exposing JNI, libc, and OS‑level memory behaviors. Alibaba Cloud’s OS console provides a full‑stack memory panorama that helps developers pinpoint the true source of memory anomalies and prevent OOM events in containerized Java workloads.