39.67% of your live heap (4.73 GB) is being held by the CoreProtect plugin, specifically by static caches inside net.coreprotect.config.ConfigHandler. Two other "suspects" MAT flagged (loaded chunks, ~1.8GB and ~1.4GB) are just normal loaded-world data tied to your server's active chunks — not a leak, ignore those.
What's actually accumulating, inside CoreProtect's cache maps (ConcurrentHashMap/SynchronizedMap fields on ConfigHandler):
- 29.7 million net.minecraft.world.item.ItemStack
- 29.9 million org.bukkit.craftbukkit.inventory.CraftItemStack
- 29.7 million PatchedDataComponentMap
- 29.9 million CraftItemStack$3 / CraftPersistentDataAdapterContext
- 6.4 million ItemStack[] arrays
That's tens of millions of item-stack objects sitting in memory, never released.
Root cause, from the thread stack: CoreProtect's hopper-transfer logging worker is stuck:
Craft Scheduler Thread - 1170 - CoreProtect
InventoryChangeListener.checkTasks
HopperPullListener.processHopperBatch
HopperPullListener.lambda$startHopperProcessor$0
CoreProtect batches hopper/inventory-change events into a queue before writing them to its database. This worker thread is idling in wait() instead of actively draining that queue — meaning inventory-change events (from hoppers, chests, etc.) are being queued and cached faster than CoreProtect is flushing them to disk. Every hopper pull/inventory transaction on your server queues item-stack snapshots that never get released, so the leak grows continuously with normal gameplay/redstone activity — it will never plateau on its own.
1. Update CoreProtect to the latest version — this looks like the known CoreProtect hopper-transaction/inventory-cache growth issue that's been reported and patched over several releases.
2. Check CoreProtect's config for hopper-transaction logging (hopper-transactions / hopper-item settings) — if you don't need item-level hopper logging, disabling it removes this code path entirely.
3. Check your server's disk I/O / database performance for CoreProtect's backing DB (SQLite/MySQL) — if writes are slow, the queue backs up faster, which would explain why it grew to multiple GB.
4. If it's still leaking on the latest version, this is worth reporting to the CoreProtect issue tracker with this heap dump analysis (dominator path + thread stack above).
The full interactive report (with drill-down) is at C:\Users\********\Desktop\Claude-projekt\heapdump\LeakSuspects\index.html if you want to open it yourself. I'll leave the Top Components report generating in the background in case you want a second data point, but the leak suspects report already gives a conclusive answer.