What is Method Area / Metaspace?
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
The method area is a shared logical memory area defined by the JVM specification. It holds per-class information such as the runtime constant pool, field and method details, and method bytecode. The specification does not require one physical layout for it.
Metaspace is a HotSpot implementation detail. Since JDK 8, HotSpot stores class metadata in native memory called Metaspace instead of the older PermGen. Metaspace is related to the method area, but the two terms are not exactly the same level of description.
For example, an application server may load every deployment with a new class loader. If a static cache keeps old loaders reachable, their classes cannot be unloaded and Metaspace can keep growing. HotSpot may eventually throw OutOfMemoryError: Metaspace.
-XX:MaxMetaspaceSize can place a limit on this native memory, but raising it does not fix a class-loader leak. Class metadata can be reclaimed when its defining loader and classes are no longer reachable and class unloading occurs. Heap tools and class-loading or native-memory diagnostics are used for different parts of this investigation.
What is Method Area / Metaspace
Direct Answer
The method area is the JVM specification's shared logical storage for per-class structures, runtime constant pools, field and method data, and method code. Metaspace is HotSpot's native-memory area for class metadata; it is an implementation detail related to, but not identical to, the entire specified method area.
Deep Dive & Architecture
Method area and Metaspace
The method area is the JVM specification's shared logical home for per-class structures. Metaspace is HotSpot's native-memory storage for class metadata. They are related, but treating them as identical hides that the specification allows different physical designs and HotSpot stores related runtime data in more than one place.
A class-loader redeployment leak
An application server loads version 1 of a web application with loader A. After deployment of version 2, loader B defines the new classes. If a timer thread or static registry still references loader A, that loader and the classes it defined cannot complete their intended lifecycle. Repeating the deployment can grow class metadata until HotSpot reports OutOfMemoryError: Metaspace.
Classes are not normally unloaded one arbitrary class at a time while their defining loader remains live. Dynamic proxies, bytecode generation, template engines, and repeated plugin loading can all produce legitimate metadata growth before reaching a plateau. A leak means old loaders or generated classes remain beyond their intended lifetime, not merely that the number rose once.
Evidence for Metaspace and heap usage
A heap dump is useful for heap objects and may reveal paths retaining class loaders, but it does not fully describe VM-native allocation. Class-loading counters, jcmd, GC/class-unloading logs, and HotSpot Native Memory Tracking can add the missing view. NMT must be enabled and has scope and overhead limits. Raising -Xmx targets the Java heap; -XX:MaxMetaspaceSize targets a different boundary.
Code Example
import java.lang.management.ClassLoadingMXBean;
import java.lang.management.ManagementFactory;
class MethodAreaAndMetaspace {
public static void main(String[] args) {
ClassLoadingMXBean classes = ManagementFactory.getClassLoadingMXBean();
System.out.println("currently loaded: " + classes.getLoadedClassCount());
System.out.println("total loaded: " + classes.getTotalLoadedClassCount());
System.out.println("total unloaded: " + classes.getUnloadedClassCount());
}
}
Check your understanding
Answer these without looking back at the article.
- Why is Metaspace not exactly the complete method area?
- What normally has to become unreachable before classes can unload?
- Does increasing -Xmx directly increase MaxMetaspaceSize?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.