What replaced PermGen, and why?

The Answer

• PermGen was a fixed-size region inside the heap holding class metadata, static variables and interned strings. It was removed in Java 8 by JEP 122.
• Metaspace replaced it for class metadata and lives in native memory, outside the heap and outside -Xmx.
• Static variables and interned strings did not go to Metaspace. They went to the ordinary heap — statics inside the java.lang.Class mirror object.
• The motivation was the fixed ceiling: PermGen had to be sized by hand, OutOfMemoryError: PermGen space was a routine redeploy failure, and the right size was unknowable in advance.
• The failure moved rather than disappearing. Metaspace is unbounded by default, so a class-loader leak now grows until the container's limit and the process is OOMKilled — no Java error, no heap dump.
• Which is why -XX:MaxMetaspaceSize is worth setting even though nothing forces you to. A predictable failure beats an invisible one.

Understand It

Where the metadata actually lives now

Three facts, read from the running JVM rather than asserted:

System.out.println("a PermGen pool exists        : " + hasPoolNamed("Perm"));

var metaspace = pool("Metaspace");
System.out.println("Metaspace is non-heap memory : "
        + (metaspace.getType() == java.lang.management.MemoryType.NON_HEAP));
System.out.println("Metaspace has a ceiling      : "
        + (metaspace.getUsage().getMax() >= 0));

a PermGen pool exists        : false
Metaspace is non-heap memory : true
Metaspace has a ceiling      : false

The third line is the one that matters and the one nobody quotes. getMax() returning -1 means unbounded: this JVM will let class metadata grow until the operating system refuses. That is the trade JEP 122 made — no more guessing a size, and no more ceiling to catch a leak.

Pass -XX:MaxMetaspaceSize=64m and the same line prints true. Nothing else about the program changes.

It is not empty, and it only grows

var loading = classLoading();

long before = metaspaceUsed();
int loadedBefore = loading.getLoadedClassCount();

for (String name : List.of("java.util.regex.Pattern", "javax.crypto.Cipher",
        "java.net.http.HttpClient", "java.util.zip.ZipFile",
        "java.time.chrono.HijrahDate", "java.text.NumberFormat")) {
    Class.forName(name);
}

System.out.println("classes loaded before : " + loadedBefore);
System.out.println("classes loaded after  : " + loading.getLoadedClassCount());
System.out.println("metaspace grew by     : " + (metaspaceUsed() - before) + " bytes");
System.out.println("classes unloaded ever : " + loading.getUnloadedClassCount());

classes loaded before : 797
classes loaded after  : 863
metaspace grew by     : 156984 bytes
classes unloaded ever : 0

Six Class.forName calls pulled in 66 classes — each one drags its supertypes, interfaces and field types with it — and about 150 KB of metadata. The exact numbers move between runs and JDK builds; the shape does not.

The last line is the important one. Zero classes have ever been unloaded, in a program that ran to completion. That is normal, and it is the key to the whole topic.

Class metadata is unloaded per class loader, not per class

This is the mechanism, and getting it right is what separates a real answer from a recited one.

A class is not collectable on its own. A class is reachable from its ClassLoader, the loader is reachable from every class it loaded, and every instance is reachable from its class. The whole thing is one cycle, and it is collectable only when the entire loader becomes unreachable — loader, all its classes, and all their static fields, together or not at all.

For the application class loader, that never happens while the JVM is up. So in an ordinary service, Metaspace fills once during warm-up and then sits flat. Metaspace is not a place leaks come from; it is a place one specific leak shows up.

That leak is redeploying an application in a long-running container. Each deploy creates a new loader and loads a complete second copy of every class. The old loader should become unreachable — and one reference from outside is enough to stop it:

• a ThreadLocal set on a container-owned thread, holding a value whose class came from the old loader
• a JDBC driver still registered in DriverManager
• a shutdown hook, or a thread the application started and never stopped
• a listener registered with a singleton the container owns

Any one of those pins the loader, and the loader pins every class and every static field. See memory-leaks — this is the same "unwanted reachability" rule, applied to loaders instead of objects.

Why the new failure is worse than the old one

This is the honest part, and it is the answer an interviewer is actually listening for.

PermGen was annoying: you had to size it, and OutOfMemoryError: PermGen space after three redeploys was a rite of passage. But look at what that failure gave you. A Java error, thrown by the JVM, at a ceiling you chose, with a stack trace, which -XX:+HeapDumpOnOutOfMemoryError turned into a dump you could open.

The Metaspace version of the same leak produces none of that. It grows into native memory until the container's limit, and then the kernel kills the process. No exception, no dump, nothing in the application log, and a heap dump taken beforehand looks healthy — because the retained objects are classes, not instances.

The diagnostic signature worth memorising: a container OOMKill with no OutOfMemoryError in the log is a native-memory story. Metaspace is one of the candidates, along with thread stacks, the code cache and direct byte buffers.

Reference

Flags, and what each is for

# Bound it. Nothing forces you to, and that is the problem.
-XX:MaxMetaspaceSize=256m        # a real ceiling: you get OutOfMemoryError:
                                 #   Metaspace instead of an OOMKill
-XX:MetaspaceSize=128m           # NOT an initial size — the threshold at
                                 #   which the first metadata GC is triggered.
                                 #   Set it above your steady state to avoid a
                                 #   pointless full GC during warm-up.

# Removed in 8. The JVM refuses to start if you pass them.
-XX:PermSize=128m                # Unrecognized VM option
-XX:MaxPermSize=256m             # Unrecognized VM option

# See it happening.
-Xlog:class+unload=info          # every class unload, with the loader
-Xlog:class+load=info            # every load — noisy, but conclusive
-Xlog:gc+metaspace=info
-XX:NativeMemoryTracking=summary # then jcmd <pid> VM.native_memory summary

-XX:MetaspaceSize being a GC threshold rather than an initial allocation is the most commonly misread flag in this area. Leaving it at the default on an application with a large class count means a full GC early in warm-up that achieves nothing.

Diagnosing it

# Is it growing at all?
jcmd <pid> GC.class_stats              # needs -XX:+UnlockDiagnosticVMOptions
jcmd <pid> VM.metaspace summary        # per-loader breakdown — the useful one
jcmd <pid> VM.classloader_stats        # loaders, class counts, metadata bytes

# The signature of a redeploy leak: N copies of the same class name,
# one per loader that was never collected.
jcmd <pid> GC.class_histogram | grep YourApplicationClass

# And the one that names the problem outright.
jcmd <pid> VM.native_memory summary    # Class (metadata) section

VM.classloader_stats is the fastest route to a diagnosis: seeing four WebappClassLoader instances in a container that has been deployed to four times is the entire finding.

From inside the JVM

// Metaspace is a memory pool like any other.
for (MemoryPoolMXBean pool : ManagementFactory.getMemoryPoolMXBeans()) {
    if (pool.getType() == MemoryType.NON_HEAP) {
        System.out.println(pool.getName() + " " + pool.getUsage());
    }
}

// Loaded vs unloaded is the leak indicator in one line: in a service that
// redeploys, loaded should come back down after a deploy settles.
ClassLoadingMXBean loading = ManagementFactory.getClassLoadingMXBean();
loading.getLoadedClassCount();       // currently loaded
loading.getTotalLoadedClassCount();  // ever loaded
loading.getUnloadedClassCount();     // ever unloaded

Exporting loaded - unloaded as a metric is cheap and is the single most useful early warning for this class of problem.

Where each thing went in Java 8

The middle two are what the common answer gets wrong. "Statics live in Metaspace" is repeated everywhere and JEP 122 says otherwise — see heap-vs-stack.

Scenarios

Metaspace grows on every redeploy and the heap looks fine. The heap looking fine is the diagnosis: what is retained is classes, not instances, so a heap dump shows nothing unusual. Run jcmd VM.classloader_stats and count loaders — one per deploy that was never collected. Then find the single outside reference pinning the old one: threads the application started, JDBC drivers in DriverManager, ThreadLocals on container threads, listeners on container singletons.

A framework generates proxies at runtime and Metaspace creeps. Anything using CGLIB, ByteBuddy, or dynamic proxies creates classes at runtime, and if the generating loader is retained per-instance rather than shared, each one is permanent. Common with a badly-scoped mapper or an expression evaluator that compiles a class per expression. The give-away in GC.class_histogram is many classes with generated-looking names and an increasing numeric suffix. The fix is nearly always to cache and reuse rather than to raise the ceiling.

Somebody proposes removing -XX:MaxMetaspaceSize because it caused an outage. They are right that it caused the outage and wrong about the fix. An unbounded Metaspace does not remove the leak, it removes the signal — you trade a Java error naming the problem for a kernel OOMKill that names nothing. Raise the ceiling to something above the real steady state with headroom, keep it, and alert on loaded - unloaded. Removing it is choosing a worse failure mode for the same bug.

"We restart on every deploy, so who cares?" Genuinely reasonable, and worth saying out loud rather than treating as laziness. If you deploy by replacing containers, the class-loader leak has no time to matter and the ceiling protects you from nothing. The interesting question is what else in your estate does not restart — a long-running batch host, a legacy application server, anything with hot-reload in development. Development is where this bites most often now, because an IDE with hot-swap is exactly the redeploy loop that was the original problem.

Interviewer's Next Move

1. "What replaced PermGen, and why?" Metaspace, in Java 8 via JEP 122, holding class metadata in native memory outside the heap. The motivation was the fixed ceiling: PermGen had to be sized by hand, the right size was unknowable, and OutOfMemoryError: PermGen space was a routine failure in anything that redeployed. Note also that only the metadata moved — statics and interned strings went to the heap.

2. "So is the PermGen problem solved?" The ceiling is gone; the leak is not. Metaspace is unbounded by default, so the same class-loader leak now grows into native memory until the kernel kills the process — no Java exception, nothing in the log, and a heap dump that looks healthy because classes are not heap objects. Arguably a worse failure mode, which is why setting -XX:MaxMetaspaceSize is still worth doing.

3. "When is class metadata actually unloaded?" When the entire class loader becomes unreachable, not per class. A class holds its loader, the loader holds all its classes, and instances hold their class — so it is all-or-nothing per loader. For the application class loader that never happens while the JVM is running, which is why Metaspace normally fills during warm-up and then stays flat.

4. "What is a ClassLoader leak and how would you find one?" A redeploy creates a new loader and a second copy of every class; one reference from outside — a ThreadLocal on a container thread, a registered JDBC driver, a thread that was never stopped — pins the old loader and everything it loaded. Find it with jcmd VM.classloader_stats and count loaders, or a class histogram showing N copies of one class name.

5. "Where do static variables live, then?" On the heap, inside the java.lang.Class mirror object. JEP 122 moved them there along with interned strings when PermGen went; only the metadata went to Metaspace. Most people answer "Metaspace", and the distinction matters because it means a large static cache counts against -Xmx and shows up in a heap dump.

Code traps

// A service with a long uptime and a config system that compiles each
// expression rule into a class, using a fresh loader per compile.
for (Rule rule : rulesReloadedEveryMinute()) {
    ClassLoader loader = new RuleClassLoader(parent);
    Class<?> compiled = loader.defineRule(rule);
    cache.put(rule.id(), compiled);
}

java -XX:MaxPermSize=256m -jar app.jar

Common wrong answers

Check Yourself

Q1. PermGen is gone. Is the failure it used to cause gone with it?

Q2. Your service is OOMKilled, there is no OutOfMemoryError in the log, and the last heap dump looks healthy. What does that combination point at?

Q3. When does the JVM actually unload a class?

Practice