Direct answer

A memory leak is suspected when memory retained after comparable garbage collections keeps increasing under a similar workload. A rising heap graph by itself is not proof of a leak.

How to check it

  1. Keep the same Minecraft version, plugin/mod list and workload while gathering readings. Record the time of each lag spike and whether the player count or explored chunks changed.
  2. Use /spark gc for garbage-collection history and /spark health show --memory for a memory snapshot. Compare multiple readings rather than one screenshot.
  3. If growth persists, collect a carefully scheduled heap summary with /spark heapsummary. Large heap dumps are sensitive and can pause a server or consume substantial disk space.
  4. Check container RAM and native memory separately: a process can exceed a hosting limit even when Java heap use is below -Xmx.
/spark gc
/spark health show --memory
/spark heapsummary

What to change

First confirm the trend after garbage collection, then test suspected plugins or mods one at a time on a copy of the server. Fix the responsible component or report the finding with a profiler or heap summary; increasing -Xmx only delays a genuine leak. Heap snapshots may contain private server data, so do not publish raw dumps.

Software and version notes

spark command availability depends on the installed platform and permissions. Oracle documents GC logging and heap diagnostics for the JVM. Do not diagnose leaks from operating-system memory usage alone: OS page cache and native allocations are different from the Java heap.

Verify the result

After the change, compare memory readings after several comparable GC cycles and a similar duration of play. Retained heap should stabilize rather than steadily grow.

References