栈、堆、方法区的交互关系
从线程共享与否的角度来看
线程共享要注意：线程安全问题。
方法区的理解
《Java 虚拟机规范》中明确说明
尽管所有的方法区在逻辑上属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。
HotSpot JVM 的方法区还有一个别名叫做 Non-Heap（非堆），目的就是要和堆分开。所以：**方法区看作是一块独立于 Java 堆的内存空间。**方法区和 Java 堆内数据变化频率差异非常大，方法区内的数据是稳定的，所以后续表现出的特性不一样（垃圾回收频率和策略不一样），可以考虑物理隔离。
-
方法区（Method Area）线程共享的内存区域
-
方法区在 JVM 启动的时候被创建，它的实际的物理内存空间可以不连续，逻辑上连续的
-
方法区的大小可以固定大小或者扩展
-
方法区的大小决定了系统可以保存多少个类，如果系统定义的类太多，会导致方法区溢出。报错：java.lang.OutOfMemoryError:PermGen space 或者 java.lang.OutOfMemoryError:Metaspace
-
关闭 JVM 就会释放方法区的内存
-
在 JDK7 之前，方法区被称为永久代。JDK 8 开始，使用元空间取代了永久代。
-
元空间的本质与永久代类似，都是对 JVM 规范中方法区的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存
设置方法区大小与OOM
方法区的大小不必是固定的，JVM可以根据应用的需求动态调整
JDK 7 及以前
-
通过 -XX:PermSize 来设置永久代初始分配空间，默认值是：20.75M
-
-XX:MaxPermSize 来设置永久代最大可分配空间，32位机器默认值是 64M，64位机器默认值是 82M
-
当 JVM 加载类信息容量超过这个值，会报异常：OutOfMemoryError:PermGenspace
JDK 8 及以后
- 元数据区大小可以使用参数 -XX:MetaspaceSize=1G 和 -XX:MaxMetaspaceSize=16G 指定。
- 默认值依赖平台：Mac 下，-XX:MetaspaceSize 的值是 21M 和 -XX:MaxMetaspaceSize 的值是：18446744073709547520，即没有限制
- 与永久代不同，如果不指定大小，默认情况，虚拟机会耗尽所有的可用系统内存。如果元数据区发生溢出，虚拟机一样会抛出异常：OutOfMemoryError：Metaspace
- -XX:MetaspaceSize 是初始值的高水位线，一旦触及这个水位线，Full GC 将会被触发并卸载没用的类，然后这个高水位线将会重置。新的高水位线的值取决于 GC 后释放了多少元空间。如果释放的空间不足，那么在不超过 MaxMetaspaceSize 前提下，适当提高该值。如果释放空间过多，则适当降低该值。
- 如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次，Full GC 将会多次调用。为了避免频繁的 Full GC，建议将 MetaspaceSize 设置为一个相对较高的值。
方法区出现 OOM
xml
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm</artifactId>
<version>9.4</version>
</dependency>
java
import org.objectweb.asm.ClassWriter;
import org.objectweb.asm.Opcodes;
/**
* -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
*/
public class JavaMethodAreaOOM extends ClassLoader {
public static void main(String[] args) {
int j = 0;
try {
JavaMethodAreaOOM test = new JavaMethodAreaOOM();
for (int i = 0; i < 100000; i++) {
// 创建 ClassWriter 对象，用于生成类的二进制字节码
ClassWriter classWriter = new ClassWriter(0);
// 版本号,修饰符，类名，包名，父类，接口
classWriter.visit(Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);
// 返回 byte[]
byte[] code = classWriter.toByteArray();
// 类的加载
test.defineClass("Class" + i, code, 0, code.length);
j++;
}
} finally {
System.out.println(j);
}
}
}
方法区的内部结构
方法区用于存储已被虚拟机加载的
- 类型信息
- 域信息
- 方法信息
- 运行时常量池
- 静态变量
- JIT 代码缓存
类型信息
对每个加载的类型（类class、接口 interface、枚举 enum、注解 annotation），JVM 必须在方法区中存储以下类型信息
- 这个类型的完整有效名称（全名=包名.类名）
- 这个类型直接父类的完整有效名（对于 interface 或者是 java.lang.Object，都没有父类）
- 这个类型的修饰符（public，abstract，fianl 的某个子类）
- 这个类型直接接口的一个列表（类可能实现多个接口，是有序的）
java
public class MethodInnerStructTest extends Object implements Comparable<String>,Serializable {
}字节码文件中的类信息
域（Field）信息
JVM 必须在方法区中保存类型的所有域的相关信息以及域的声明顺序
- 域的相关信息包括：域名称、域类型、域修饰符（public、private、protected、static、fianl、volatile、transient 的某个子集）
java
public int num = 10;
private static String str = "dyf";字节码文件中的域信息
方法（Method）信息
JVM 必须在方法区中保存类型的所有方法的相关信息以及方法的声明顺序
- 方法名称
- 方法的返回类型（或 void）
- 方法参数的数量和类型（按顺序）
- 方法的修饰符（public、private、protected、static、fianl、synchronized、native、abstract 的某个子集）
- 方法的字节码（bytecodes）、操作数栈、局部变量表以及大小（native、abstract 方法除外）
- 异常表（native、abstract 方法除外）
- 每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
java
public void test1() {
int count = 20;
System.out.println("count = " + count);
}
public static int test2(int cal) {
int result = 0;
try {
int value = 30;
result = value / cal;
} catch (Exception e) {
e.printStackTrace();
}
return result;
}字节码文件中的域信息
下图方法时默认生成的类构造器
在 test2方法中，有异常表，如下图红框
non-final 变量
- 静态变量和类关联在一起，随着类的加载而加载，它们成为类数据在逻辑上的一部分
- 类变量被类的所有实例共享，即使没有类的实例时，你也可以访问它。
全局常量（static final）
被声明为 final 的类变量在编译的时候就会被分配了（final 不在变化，能放到离线处理的就不放在在线处理）
java
class Order {
public static int count = 1;
public static final int number = 2;
运行时常量池
常量池的建立是为了数据的重复利用，类级别的叫常量池，方法级别叫局部变量表。思路都是一样。
- 常量池表（Constant Pool Table）包含各种字面量和对类型、域、方法的符号引用。
常量池，可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名，方法名，参数类型，字面量等类型。
下图为字节码文件中常量池：
- 运行时常量池（Runtime Constant Pool）是方法区的一部分。
- 常量池（Constant Pool Table）是 Class 文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池。
- 运行时常量池，在加载类和接口到虚拟机后，就会创建对应的运行时常量池。
- JVM 为每个已加载的类型（类或者接口）都维护一个常量池。池中的数据项像数组一样，是通过索引访问的。
- 运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能获得的方法或者字段引用。此时不再是常量池中的符号地址了，这里已经替换为真实地址。
- 运行时常量池，相对于 Class 文件常量池的另一个重要特征是：具备动态性。
- 当创建类或者接口的运行时常量池时，如果构造运行时常量池所需的空间超过了方法区所能提供的最大值，则 JVM 会抛出 OutOfMemoryError 异常。
方法区使用举例
java
public static void main(String[] args) {
int x = 500;
int y = 100;
int a = x / y;
int b = 50;
System.out.println(a + b);
}
方法区的演进细节
| JDK 1.6及以前 | 有永久代（permanent generation）,静态变量存放在永久代上 |
|---|---|
| JDK1.7 | 有永久代，但已经逐步"去永久代"，字符串常量池、静态变量迁移到堆中。 |
| JDK 1.8 及以后 | 无永久代，类型信息、字段、方法、常量保存在本地内存的元空间，但字符串常量池、静态变量仍在堆中 |
永久代为什么要被元空间替换？
Java 8 将永久代中的数据迁移到一个与堆不相连的本地内存区域，这个区域叫做元空间（Metaspace）。
最本质的类的元数据信息与对象实例信息，数据特性差异很大。类的元数据信息一旦加载，几乎是不变的，并且它更抽象远离业务，被更多的线程共享。而对象实例 80% 是朝生夕死的，它存在大量空间浪费，需要即使回收。这两种不同类型数据如果放在一起管理，会带来一些问题。
比如：
- 为永久代设置空间大小是很难确定的。
- 元空间使用本地内存，默认情况下，元空间的大小仅受本地内存限制。
- 对永久代进行调优是很困难的。
- 元空间内数据更重要，回收策略更谨慎，与对象实例信息的回收策略，差异很大。
StringTable 为什么要调整？
还是因为 StringTable 与类的元数据信息数据性质差异太大，而与堆上的数据更相似。StringTable 与静态变量大部分是用户线程创建、修改的数据，很多数据也是朝生夕死，需要即时回收。如果放在元空间中，元空间中垃圾回收效率很低，存在大量的空间浪费。
方法区的垃圾回收
方法区的垃圾回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。
方法区的垃圾回收主要回收两部分内容：
- 常量池中废弃的常量
- 不再使用的类型
方法区内常量池存放两大类型常量：
- 字面量：文本字符串、被声明为 final 的常量值。
- 符号引用
- 类和接口的全限定名
- 字段的名称和描述符
- 方法的名称和描述符
常量池的回收策略很明确：只要常量池中常量没有被任何地方引用，就可以被回收。与回收 Java 堆中的对象非常类似。
判定一个类型是否属于"不在被使用的类" 的条件比较苛刻。需要同事满足下面三个条件：
- 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类及其任何派生子类的实例（现在没有，后续用户线程要创建该类的实例，还是需要用到该类的元数据信息）
- 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的加载等，否则通常是很难达成（断了后续的香火）
- 该类对应的 java.lang.CLass 对象没有在任何地方被引用过，无法在任何地方通过反射访问该类的方法。（将反射的口也给堵死了）
在大量使用反射、动态代理、CGLib 等字节码框架，动态生成 JSP 以及 OSGi 这类频繁自定义类加载器的场景，通常都需要 Java 虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。原则：自己创建的内存，自己要对它负责（生、老、病、死）。
总结
