Direct answer

Increasing Java memory usage does not by itself prove a leak. The JVM grows its heap, keeps caches and uses native memory; investigate whether usage keeps rising after garbage collections and under a stable workload.

What it means

A panel may display process RSS, heap used, container memory or filesystem cache. These metrics are not interchangeable and may tell different stories.

Practical example: Example: a server with -Xmx8G may grow to use most of its 8 GB heap and then stabilize, which is normal. A persistent rise in live heap measured after collections under comparable load is a more meaningful leak indicator. A container OOM kill can also occur when native memory exceeds the host limit.

If you are a player

  • Note whether players experience freezing, long GC pauses or an actual out-of-memory crash.
  • Record the player load and duration before reporting rising RAM to the owner.

If you run the server

  1. Record -Xms, -Xmx, hosting/container limits and the actual Java runtime.
  2. Use spark memory/GC reporting or appropriate JVM tools to distinguish heap usage from native and container memory.
  3. Compare memory after full collections across comparable activity rather than a single peak.
  4. Check recent plugin changes, scheduled tasks and world activity; reproduce on staging to isolate a growing collection.
  5. If an OOM kill occurs, collect host/kernel memory evidence and avoid allocating every byte of system RAM to -Xmx.

Important notes

  • More allocated RAM does not make a slow main-thread workload faster. Change heap size only when memory/GC evidence supports it.

References

Use the documentation for the exact software and release you run. These sources support the settings or diagnostic behavior used in this fix.

Was this article helpful?
Help us improve this article

Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.

What could we improve?
Do not include passwords, server IPs, or other private information.0 / 1000