如何解读Java 8 Metaspace转储文件？技术求助

First off, great job fixing the Metaspace OOM by caching compiled Groovy scripts—this is exactly the right approach for this common issue. Dynamic Groovy script compilation generates new class definitions every time it runs, which quickly fills up Metaspace if not cached, so your fix stopping daily crashes is a solid win.

Let’s break down the Metaspace dump data you shared, starting with the key distinctions you asked about:

Class Space vs. NonClass Space #

These are two distinct regions within Metaspace, split to support the JVM's compressed pointer optimizations (CompressedClassPointers):

• Class Space: This stores class structural metadata accessed via compressed pointers—think class field definitions, method bytecode, and the runtime constant pool. Your CompressedClassSpaceSize (528,482,304 B ≈ 504MB) sets the hard limit for this region, and Reserved (1GB) is the virtual memory the JVM has set aside for it (not yet allocated from the OS).
• NonClass Space: This holds all other metadata that doesn’t fit into Class Space—things like method names, string constants, annotation data, and internal JVM metadata related to classes but not part of their core structure. This is the larger, more dynamic part of Metaspace for many applications.

Calculating Total Committed Metaspace Memory #

Committed memory is what the JVM has actually requested from the operating system (as opposed to reserved, which is just pre-allocated virtual address space). To get the total:

Total Committed = Class Space Committed + NonClass Spaces Committed
= 44,572,672 B + 347,594,752 B
= 392,167,424 B ≈ 374 MB

For context, your total used memory is ~190MB (21,412,264 B + 178,477,376 B), which is well below your MaxMetaspaceSize (536,870,912 B ≈ 512MB). This confirms your fix is working: memory usage is stable, not creeping up toward the OOM threshold like it was before.

Quick Notes on Your Dump Data #

• MaxMetaspaceSize: The overall hard limit for all Metaspace regions combined (512MB in your case).
• Capacity: The amount of memory the JVM has allocated internally within the committed space (not all of it is in use yet).
• Used: The actual amount of memory occupied by metadata—this is the number you want to watch for unexpected growth over time.

If you want to keep monitoring stability long-term, use the jstat -gcmetacapacity <pid> command to track Metaspace usage in real time. The full dump file would only be necessary if you wanted to dig into exactly which classes are taking up space, but from the header data alone, your fix is clearly effective.

内容的提问来源于stack exchange，提问作者machinarium