Direct answer

Garbage collection is expected in a Java Minecraft server. A GC issue is more plausible when pauses or allocation pressure align with the lag players report.

How to check it

  1. Run /spark gc to view GC history, then toggle /spark gcmonitor while observing a reproducible lag period.
  2. Capture /spark tps and optionally a profiler result during the same workload. Record player count and any recent plugin or JVM flag changes.
  3. Compare heap occupancy after GC, collection frequency and pause time rather than looking at total allocated memory alone.
  4. Disable the monitor after the diagnostic session; keep any detailed GC logs in a protected admin-only location.
/spark gc
/spark gcmonitor
/spark tps

What to change

If collections correlate with spikes, investigate object allocation hotspots, a plugin leak or an unsuitable heap configuration. Avoid changing to copied JVM “optimization” flag sets without a baseline; GC settings can trade pauses for CPU and memory overhead.

Software and version notes

spark command names may differ on proxies and modded clients. Oracle documents JVM GC logging; a collection displayed by spark does not, on its own, prove the root cause of lag.

Verify the result

Repeat under comparable load. Compare GC pause statistics and player-visible spikes after any single change, and retain the old flags for rollback.

References