一 堆栈方法区的交互关系

image.png
image.png

二 方法区的理解

2.1 方法区的位置

1）《Java虚拟机规范》中明确说明：“尽管所有的方法区在逻辑上是属于堆的一部分，但是一些简单的实现可能不会选择去进行垃圾收集或者进行压缩”。但是这对于HotSpot而言，方法区还有一个别名：Non-Heap（非堆），目的就是要与堆分开。
2）所以：方法区可以看作是一块独立于Java堆的内存空间。可以这样想：在世界法规上，我们是宣称台湾是中国不可分割的一部分，是中国的一份子，但是在实际上，台湾和我们中国大陆还没有真正实现统一，是独立运作的一片地区，这个和方法区于堆的关系类似。

2.2 方法区基本理解

1）方法区（Method Area）是与Java堆一样，是各个线程共享的内存区域。
2）方法区在JVM启动的时候就被创建，并且它的实际物理内存空间是和堆一样可以不连续的。
3）方法区的大小和堆区一样，可以选择固定大小或者可扩展的。
4）方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致了方法区溢出，虚拟机同样会抛出内存溢出错误：java.lang.OutOfMemoryError：PermGen space 或者 java.lang.OutOfMemoryError：Metaspace
，比如可能会造成方法区内存溢出的场景：

  1. 加载了大量的第三方jar包
  2. Tomcat部署的工程过多（30-50个）
  3. 大量动态的生成反射类

5）关闭JVM会释放这个区域的内存。

2.3 Hotspot中方法区的演进

1）在jdk7及以前，习惯上把方法区，称为永久代。jdk8开始，使用元空间取代了永久代。
2）本质上，方法区和永久代并不等价，仅是对于hotspot而言。在《Java虚拟机规范》中，对如何实现方法区，并没有做统一的要求。例如：BEA JRocket / IBM J9 中则不存在永久代的概念（现在看来，当年使用永久代并不是最好的idea，会导致Java更容易发生OOM）。
3）在到了jdk8，完全抛弃了永久代的概念，改用了与JRocket，J9一样在本地内存中实现的元空间来代替。
4）元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过永久代和元空间最大的区别是：元空间不在虚拟机设置的内存中，而是使用了本地内存。
5）根据《Java虚拟机规范》，如果方法区无法满足新的内存分配要求，将会抛出OOM异常。

三 设置方法区大小和OOM

3.1 设置方法区大小

1）方法区的大小不一定是固定的，jvm可以根据应用的需要来动态调整。
2）jdk7及以前：
①通过 -XX:PermSize 来设置永久代初始分配空间，默认值是20.75M
②-XX:MaxPermSize 来设置永久代最大的可分配空间，32位机器默认是64M，64位机器默认是82M
③当jvm加载的类信息量大小超过这值，就抛出：OOM：PermGen space
3）jdk8及以后：

  1. 元数据区大小可以使用参数 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize** **来指定，替换掉上述原有的两个参数。
  2. 默认值依赖于平台：在Windows下，-XX:MetaspaceSize 默认值是21M，-XX:MaxMetaspaceSize 值是-1，即没有限制。
  3. 和永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存，如果元数据区发生溢出，虚拟机一样会抛出异常OutOfMemoryError：Metasapce。
  4. -XX:MetasapceSize：设置初始的元空间大小，对于一个64位的服务端JVM来说，其默认值为21MB，这就是初始的高水位线，一旦触及这个水位线，Full GC 将会被触发并卸载没有用的类（即这些类对应的类加载器不再存活）然后这个高水位线将会重置，新的高水位线的值取决于GC后释放了多少元空间，如果释放的空间不足，那么在不超过MaxMetaspace时，适当提高该值，如果释放空间过度，则适当降低该值。

  5. 如果初始化的高水位线设置过低，上述高水位线调整的情况会发生很多次，通过垃圾回收器的日志可以观察到 Full GC 多次调用。为了避免频繁的GC，建议将 -XX:Metaspace设置为一个较高的值。

    3.2 OOM

  6. 要解决OOM异常，或者heap space 的异常，一般的手段是通过内存映像分析工具，如：Ecilpse Memory Analyzer 对dump 出来的堆转转存储快照进行分析，重点是确认内存的对象是否是必要的，也就是要分清楚到底是出现内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。

  7. 如果是内存泄漏，可进一步通过工具查看泄漏对象到 GC Roots 的引用链，于是九能找到泄漏对象是通过怎样的路径与 GC Roots 相关联并导致垃圾回收器，无法自动回收它们的，掌握了泄漏对象的类型信息，以及 GC Roots 引用链的信息，就可以比较准确地定位泄漏代码的位置。
  8. 如果不存在内存泄漏，换句话来说，换句话来说就是内存的对象确实还必须存活着，那就应到检查虚拟机的堆参数（-Xmx，-Xms）与机器物理内存对比是否还可以调大，从代码上检查是否存在某些对象生命周期过长，持有状态时间过长的情况，尝试减少程序运行期间的内存消耗。

    四 方法区内部结构

    4.1 方法区存储什么

    1）《深入理解Java虚拟机》书中对方法区存储内容的描述：它用于存储已被Java虚拟机加载的类型信息，常量，静态变量，即时编译器编译后的代码缓存等。
    image.png

    4.1.1 类型信息

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

1）这个类型的完整有效名称（全名==包名.类名）
2）这个类型直接父类的完整有效名（对于interface、java.lang.Object，都没有父类）
3）这个类型的修饰符（public，abstract，final等的某个子集）
4）这个类型直接接口的一个有序列表

4.1.2 域（field）信息

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

  2. 域相关的信息包括：域名称，域类型，域修饰符（public，private，protected，static，final，volatile等的某个子集）

    4.1.3 方法（Method）信息

  3. 方法名称

  4. 方法的返回类型（或 void）
  5. 方法参数的数量和类型（按顺序）
  6. 方法的修饰符（public，private，protected，static，final，synchronized，native，abstract等的某个子集）
  7. 方法的字节码，操作数栈，局部变量表及大小（abstract，native 除外）

  8. 异常表（abstract，native方法除外）：每个异常处理的开始位置，结束位置，代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

    4.1.4 non-final的类变量

  9. 静态变量和类关联在一起，随着类的加载而加载，它们成为类数据在逻辑上的一部分。

  10. 类变量被类的所有实例所共享，即使没有类实例时你也可以访问它

    4.1.5 全局常量：static final

  11. 被声明为final 的类变量的处理方式不同与non-final的类变量，每个全局常量在编译的时候就已经被分配了

    4.2 常量池

    4.2.1 运行时常量池VS常量池

  12. 方法区，内部包含了运行时常量池

  13. 字节码文件，内部包含了常量池
  14. 要弄清除方法区，需要理解清楚ClassFile，因为加载的类信息都在方法区
  15. 要弄清楚方法区的运行时常量池，需要理解清楚ClassFile中的常量池
  16. 一个有效的字节码文件中除了包含类的版本信息，字段，方法以及接口等描述信息外，还包含一项信息，那就是常量池表（constant pool table），包括各种字面量和对类型、方法域和方法的符号引用

    4.2.2 常量池的作用

  • 一个Java源文件的类，接口，编译之后产生一个字节码文件。而Java的字节码需要数据支持，通常这种数据会很大以至于不能直接存储到字节码里，换另一种方式，可以存到常量池，这个字节码包含了指向常量池的引用。在动态链接的时候会使用到运行时常量池。
  • 常量池存储的数据类型包括：数量值，字符串值，类引用，字段引用，方法引用
  • 常量池，可以看作是一张表，虚拟机指令根据这张表找到要执行的类名，

    4.2.3 运行时常量池

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

    五 方法区的演进细节

    5.1 演进细节

    1）首先明确：只有HotSpot才有永久代。BEA-JRockit，IBM-J9 等来说，是不存在永久代概念的，原则上如何实现方法区时属于虚拟机的实现细节，不受《Java虚拟机规范》管束，并不要求统一。
    2）HotSpot在方法区的变化
  • JDK1.6及之前：有永久代（permanent generation），静态变量存放在永久代上
  • JDK1.7：有永久代，但是已经逐步去除永久代，字符串常量池，静态白能力溢出，保存在堆中
  • JDK1.8及之后：无永久代，类型信息，字段，方法，常量保存在本地的元空间，但是字符串常量池，静态变量仍然在堆中

image.png
image.png
image.png

5.2 永久代为什么被元空间替换掉

  1. 随着Java8的到来，HotSpot中已经去掉永久代了，但是并不意味着类的元数据信息也消失了。这些数据被迁移到一个和堆不相连的本地内存区域，这个区域叫做元空间。
  2. 由于类的元数据分配到本地内存中，元空间的最大可分配空间就是系统的可用内存空间。

  3. 这个项是很必要的，改变的原因：

    1. 为永久代设置空间大小是很难确定的。在某些场景下如果动态加载类过多，容易产生Perm区的OOM，比如某个实际web工程中，因为功能点比较多，在运行过程中，需要不断动态加载很多的类，经常出现致命错误。而元空间和永久代最大的区别就是：元空间并不在虚拟机中，而是使用了本地内存，因此默认情况下，元空间的大小仅仅受本地内存限制。
    2. 对永久代进行调优是很困难的。

      5.3 字符串常量池为什么要调整

  4. JDK7将StringTable放到了堆空间。因为永久代的垃圾回收效率太低了，在 full gc 的时候才会被触发，而full gc 是老年代的空间不足，永久代不足的时候才会触发的。这就导致了StringTable回收效率不高。

  5. 在开发中会有大量的字符串被创建，回收的效率太低导致永久代内存不足。放到堆里，能及时回收内存。

    六 方法区的垃圾回收

    1）有人认为方法区（如HotSpot虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java虚拟机规范》对方法区的约束时非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾回收。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（Java11的ZGC收集器就不支持类型卸载）。
    2）一般来说，这个区域的回收效果比较难以令人满意，尤其是类型的卸载，条件苛刻。但是这个部分的回收有时确实时必要的。以前的Sun公司的Bug列表中，曾经出现过若干严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致的内存泄漏。
    3）方法区的垃圾收集主要时回收两部分内容：常量池中废弃的常量和不再使用的类型。
    4）方法区内的常量池之中主要存放两大类常量：字面量和符号引用。字面量比较接近Java语言层次的常量概念，如文本字符串，被声明为final的常量值等。而符号引用则属于编译原理方面的概念，包括下面三类常量

  6. 类和接口的全限定名

  7. 字段的名称和描述符
  8. 方法的名称和描述符

5）HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以回收。
6）回收废弃常量和回收Java堆中的对象非常类似。
7）判断一个常量是否废弃还是相对简单的，而判断一个类型是否属于不再被使用的类的条件就比较苛刻了，需要同时满足下面三个条件

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

8）Java虚拟机被允许对满足上述三个条件的无用类进行回收，但是注意这里说的是：被允许，而不是和对象一样，没有引用就必然会被回收，关于是否对类型进行回收，HotSpot虚拟机提供了 -Xnoclassgc 参数进行控制，还可以使用 -verbose:class 以及 -XX：+TraceClass-Loading， -XX：+TraceClassUnLoading 查看类加载和卸载信息。
9）在大量使用反射，动态代理，CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常都是需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。