Java虚拟机（九）——方法区

文章目录

• • • 堆、栈、方法区的交互关系
    • • 线程是否共享：
      • 三者的交互关系：
    • 方法区的理解
    • • 方法区的位置
      • 基本理解：
    • 设置方法区大小
    • • JDK7以前
      • JDK8及以后：
    • 方法区的内部结构
    • • 方法区存储什么
      • 类型信息
      • 域（Field）信息
      • 方法（Method）信息
      • non-final的类变量
      • static final（全局常量）
    • 方法区的演进细节
    • • Hotspot方法区变化
      • String Table为什么要调整
      • 永久代为什么被替换？
    • 方法区的垃圾回收
    • • 两大类型常量
      • 对类型的卸载
    • 常见面试题
  • 附1 运行时常量池和常量池
  • • 常量池
    • • 为什么需要常量池
      • 常量池有什么？
    • 运行时常量池

堆、栈、方法区的交互关系

线程是否共享：

三者的交互关系：

Person person = new Person();

Person存储在方法区，person在Java栈， newPerson()则在Java堆

方法区的理解

方法区的位置

《Java虚拟机规范》中明确说明：“尽管所有的方法区逻辑上属于堆的一部分，但是一些简单的实现可能不会选择去进行垃圾收集或者压缩”

对于Hotspot来说，方法区还有一个别名：Non-heap（非堆），目的是与堆分开

所以方法区可以看做是一块独立于Java堆的内存空间

基本理解：

• 方法区与Java堆一样，是各个线程共享的内存区域
• 在JVM启动的时候被创建，并且实际物理内存空间和Java堆一样都可以不连续
• 方法区大小和堆一样，可以固定大小或可扩展
• 方法区大小决定了系统可以保存多少个类，如果系统定义了太多类，导致方法区溢出，虚拟机同样会抛出溢出错误：java.lang.OutOfMemory:Metaspace
  • 加载大量第三方jar包，Tomcat部署的工程过多（30-50个）;大量动态生成反射类
• 关闭JVM就会释放这个区域的内存

设置方法区大小

JDK7以前

• -XX:PermSize设置永久代初始分配空间，默认20.75M
• -XX:MaxPermSize设置最大永久代分配空间，32位机器默认64M，64机器默认82M
• 当JVM超出这个值，会报OutOfMemoryError:PermGen space

JDK8及以后：

• -XX：MetaspaceSize：设置永久代初始分配空间，
• -XX:MaxMetaspcaeSize设置最大永久代分配空间
• 以上两个参数默认值依赖平台，Windwos下默认21M初始空间；最大分配空间为-1，即没有限制
• 与永久代不同，如果不指定大小，默认情况下虚拟机会耗尽所有的可用系统内存，如果元数据区发生溢出，一样会报OutOfMemoryError：Metaspace
• -XX:MetaspcaeSize：设置初始的元空间大小，对于一个64位服务器端JVM来说，默认的值为21M，这是初始的高水位线，一旦触发这个水位线，Full GC将被触发并卸载没用的类（即对应类加载器将不再存活），然后高水位线被重置。新的高水位线的值将取决于GC后释放了多少元空间。如果释放空间不足，将在不超过MaxMetaspaceSize时，适当提高该值。如果释放空间较多，则适当降低该值。
• 若初始化高水位线过低，则高水位线调整情况会发生多次，Full GC 会频繁被调用从而影响性能。建议将-XX:MetaspaceSize设置为一个相对较高的值。

方法区的内部结构

方法区存储什么

《深入理解Java虚拟机》中对方法区（Method Area）存储内容描述如下：它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等

类型信息=>运行时常量池=>静态变量=>JIT代码缓存=>域信息=>方法信息

类型信息

对每个加载类的类型（类class、接口interface、枚举enum、注解annotation）。JVM需要在方法区中存储以下信息：

• 这个类的完整有效名称（全名=类名.包名）
• 这个类型的直接父类的完整有效名（对于interface或者是java.lang.Object，都没有父类）
• 这个类型的修饰符（public，abstract，final）
• 这个类型直接接口的一个有序列表

域（Field）信息

JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序

• 域的相关信息包括：域名城、域类型、域修饰符（public private protected static final volatile transient的某个子集）

方法（Method）信息

JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序

• 方法名称
• 方法返回类型
• 方法参数的数量和类型（按顺序）
• 方法的修饰符（public private protected static final synchronized native abstract）
• 方法的字节码（bytecodes）、操作数栈、局部变量表及大小
• 异常表（abstract和native方法除外）
  • 每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

non-final的类变量

• 静态变量和类关联在一起，随着类的加载而加载，他们成为类数据在逻辑上的一部分。
• 类变量被类的所有实例共享，即使没有类实例，也可以访问他

static final（全局常量）

被声明为final的类变量的处理方法不同，每个全局常量在编译的时候就被分配了

方法区的演进细节

• JDK7之前习惯上把方法区称为永久代，JDK8开始，使用元空间取代了永久代
• 本质上，方法区和永久代并不等价，永久代是仅对Hotspot而言的。
• 如何实现方法区并不做统一要求，IMB J9、BEA JRockit中就不存在永久代
  • 现在看来，使用永久代并不是一个好的主意，使用永久代更容易造成OOM（超过-XX:MaxPermSize上限）
• JDK 8之后，完全废除了永久代的概念，改用与JRockit、J9一样在本地内存中实现的元空间（Metaspace）来代替
• 元空间本质与永久代类似，都是对JVM规范的方法区的实现。但是区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存
• 永久代、元空间的内部结构也做了调整
• 《Java虚拟机规范》规定，如果方法区无法满足新的内存分配需求时，抛出OOM异常

Hotspot方法区变化

JDK1.6及之前	有永久代，静态变量存放在永久代上
JDK1.7	有永久代，但是已经逐渐"去永久代"，字符串常量池、静态变量移除，保存在堆中
JDK1.8及之后	无永久代，类型字段、信息、方法、常量保存在本地内存的元空间，但字符串常量池、静态变量扔保存在堆中

• 只有Hotspot才有永久代

String Table为什么要调整

JDK7中将StringTable放到了堆空间中，因为永久代的回收效率很低，在FullGC的时候才会被触发。而FullGC是因为老年代空间不足、永久代空间不足时才会触发。

这就导致StringTable回收效率不高。开发中会有大量字符串被创建，回收效率低，导致永久代内存不足。放到堆里可以及时回收内存

永久代为什么被替换？

1. 永久代设置空间大小很难确定
   某些场景下，如果动态加载类过多，容易产生Perm区的OOM。
2. 对永久代进行调优很困难

方法区的垃圾回收

回收内容：主要回收两部分内容，常量池中废弃的常量和不再使用的类型

方法区回收效果难以令人满意，尤其是类型卸载的条件相当苛刻。但是这部分区域的回收 有时又确实是必要的

两大类型常量

字面量和符号引用，符号引用包括：类和接口的全限定名、字段的名称和描述符、方法的名称和描述符。

只要常量池中的常量没有被其它地方引用，就可以被回收

回收废弃常量与回收Java堆对象非常类似

对类型的卸载

需要同时满足以下三个条件：

• 该类的所有实例都已经被回收，也就是Java堆中不存在该类以及其任何派生子类的实例
• 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的长江，如OSGI或JSP的重加载等，否则是很难达成的
• 该来对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

满足以上三个条件则允许回收，是否回收还需要看-Xnoclassgc的参数是否要对类型进行回收。

在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大压力

常见面试题

JVM的内存模型有哪些区？分别是干什么的？

Java8的内存分代改进?

JVM内存分哪几个区？每个区作用是什么？

JVM内存分布/内存结构？栈和堆的区别？堆的结构？为什么两个Survivor区？

Enden和Survivor的比例分配?

为什么要有新生代和老年代？新生代为什么要分为Eden和Survivor？

讲讲jvm的运行时数据区?

什么时候对象会进入老年代？

永久代会发生垃圾回收吗？

Java8对JVM内存模型做了什么修改？

---

附1 运行时常量池和常量池

• 方法区内部包含了运行时常量池
• 字节码文件内部包含了常量池
• 要弄清楚方法区，就要理解清楚ClassFile，因为加载类的信息都在方法区
• 要弄清楚方法区的运行时常量池，需要理解清楚ClassFile中的常量池

常量池

为什么需要常量池

一个Java源文件中的类、接口，编译后产生一个字节码文件。而Java中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存在常量池，这个字节码包含了包含指向常量池的引用。在动态链接的时候会用到运行时常量池

常量池有什么？

几种在常量池中存储的数据类型：

• 数量值
• 字符串值
• 类引用
• 字段引用
• 方法引用

运行时常量池

运行时常量池（Runtime Constant Pool）是方法区的一部分

• 常量池表（Constant Pool Table）是Class文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
• 运行时常量池，在加载 类或接口 到虚拟机后，就会创建对应的运行时常量池
• JVM为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样是通过索引访问的
• 运行时常量池中包含多种不同的常量，包括编译器就已经明确的数值字面量，也包括到运行期解析后才能获得的方法或者字段引用。此时不再是常量池中的符号地址了，这里换为真实地址
  • 运行时常量池相对于Class文件常量池的另一重要特性就是具备动态性
• 运行时常量池类似于传统编程语言的符号表（Symbol table ）但是所包含的数据比符号表更加丰富
• 当创建类或者接口的运行时常量池时，如果构造 运行时常量池所需要的内存空间超过了方法区所能提供的最大值，就会报OOM