方法区，也称非堆（Non-Heap），又是一个被执行绪共享的内存区域。其中主要储存载入的类字节码、class/method/field等元资料物件、static-final常量、static变数、jit编译器编译后的程式码等资料，另外，方法区包含了一个特殊的区域“执行时常量池”
它们的关系如下图所示：
（1）载入的类字节码：要使用一个类，首先需要将其字节码载入到JVM的内存中。至于类的字节码来源，可以多种多样，如.class档案、网络传输、或cglib字节码框架直接生成。
（2）class/method/field等元资料物件：字节码载入之后，JVM会根据其中的内容，为这个类生成Class/Method/Field等物件，它们用于描述一个类，通常在反射中用的比较多。不同于储存在堆中的java例项物件，这两种物件储存在方法区中。
（3）static-final常量、static变数：对于这两种型别的类成员，JVM会在方法区为它们建立一份资料，因此同一个类的static修饰的类成员只有一份；
（4）jit编译器的编译结果：以hotspot虚拟机器为例，其在执行时会使用JIT即时编译器对热点程式码进行优化，优化方式为将字节码编译成机器码。通常情况下，JVM使用“解释执行”的方式执行字节码，即JVM在读取到一个字节码指令时，会将其按照预先定好的规则执行栈操作，而栈操作会进一步对映为底层的机器操作；通过JIT编译后，执行的机器码会直接和底层机器打交道。如下图所示：
二、执行时常量池
我们了解到类的字节码在载入时会被解析并生成不同的东西存入方法区。类的字节码中不仅包含了类的版本、字段、方法、界面等描述资讯，还包含了一个常量池。常量池用于存放在字节码中使用到的所有字面量和符号引用（如字串字面量），在类载入时，它们进入方法区的执行时常量池存放。
执行时常量池是方法区中一个比较特殊的部分，具备动态性，也就是说，除了类载入时将常量池写入其中，java程式执行期间也可以向其中写入常量：
//使用StringBuilder在堆上建立字串abc，再使用intern将其放入执行时常量池
String str = new StringBuilder("abc");
str.intern();
//直接使用字串字面量xyz，其被放入执行时常量池
String str2 = "xyz";
由于jdk1.7中将字串常量池改为存放在堆中，因此intern()方法的实现原理相对以前的版本也有所改变。
三、方法区的实现
方法区的实现，虚拟机器规范中并未明确规定，目前有2种比较主流的实现方式：
（1）HotSpot虚拟机器1.7-：在JDK1.6及之前版本，HotSpot使用“永久代（permanent generation）”的概念作为实现，即将GC分代收集扩充套件至方法区。这种实现比较偷懒，可以不必为方法区编写专门的内存管理，但带来的后果是容易碰到内存溢位的问题（因为永久代有-XX:MaxPermSize的上限）。在JDK1.7+之后，HotSpot逐渐改变方法区的实现方式，如1.7版本移除了方法区中的字串常量池。
（2）HotSpot虚拟机器1.8+：1.8版本中移除了方法区并使用metaspace（元资料空间）作为替代实现。metaspace占用系统内存，也就是说，只要不碰触到系统内存上限，方法区会有足够的内存空间。但这不意味着我们不对方法区进行限制，如果方法区无限膨胀，最终会导致系统崩溃。
我们思考一个问题，为什么使用“永久代”并将GC分代收集扩充套件至方法区这种实现方式不好，会导致OOM？首先要明白方法区的内存回收目标是什么，方法区储存了类的元资料资讯和各种常量，它的内存回收目标理应当是对这些型别的解除安装和常量的回收。但由于这些资料被类的例项引用，解除安装条件变得复杂且严格，回收不当会导致堆中的类例项失去元资料资讯和常量资讯。因此，回收方法区内存不是一件简单高效的事情，往往GC在做无用功。另外随着应用规模的变大，各种框架的引入，尤其是使用了字节码生成技术的框架，会导致方法区内存占用越来越大，最终OOM。
四、方法区异常
我们了解到方法区的2种实现方式最终都会有一个最大值上限，因此若方法区（含执行时常量池）占用内存到达其最大值，且无法再申请到内存时，便会丢掷OutOfMemoryError。
在下面的例子中，我们将使用cglib字节码生成框架不断生成新的类，最终使方法区内存占用满，丢掷OutOfMemoryError：
报错资讯为：
其实，在日常开发中，不仅仅使CGlib字节码生成框架会产生大量的class资讯，动态语言、JSP、基于OSGI的应用都会在方法区额外产生大量的类资讯。
