JVM09_方法区

Posted 2021-09-03 root_zhb

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了JVM09_方法区相关的知识，希望对你有一定的参考价值。

方法区

1、方法区概述
- 1.1、栈、堆、方法区的交互关系
- 1.2、概念
2、方法区内部结构
3、方法区的演进细节
4、设置方法区的大小
5、常量池和运行时常量池
- 5.1、常量池
- 5.2、运行时常量池
6、如何证明静态变量的存在
7、方法区的垃圾回收
8、图示举例方法区的使用
9、总结

1、方法区概述

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

从线程共享与否的角度看
交互关系

1.2、概念

方法区在JVM启动的时候被创建,并且它的实际的物理内存空间和Java堆区一样都可以是不连续的 | 关闭Jvm就会释放这个区域的内存
方法区时逻辑上是堆的一个组成部分,但是在不同虚拟机里头实现是不一样的，最典型的就是永久代(PermGen space)和元空间(Metaspace)
(注意：方法区时一种规范，而永久代和元空间是它的一种实现方式)
方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展。
方法区的大小决定了系统可以保存多少个类,如果系统定义了太多的类,导致方法区溢出,虚拟机同样会抛出内存溢出错误：(java.lang.OutOfMemoryError:PermGen space、java.lang.OutOfMemoryError:Metaspace)
- 加载大量的第三方的jar包
- tomcat部署的工程过多(30-50个)
- 大量动态的生成反射类
对于HotspotJVM而言,方法区还有一个别名叫非堆(Non-heap),目的就是要和堆分开,方法区可以看成一块独立于Java堆的内存空间

2、方法区内部结构

方法区用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等
类型信息(对每个加载的类型(类class、接口interface、枚举enum、注解annotation),JVM必须在方法区中存储以下类型信息：
- 这个类型的完整有效名称（全名=包名.类名）
- 这个类型直接父类的完整有效名（对于interface或是java. lang.Object，都没有父类）
- 这个类型的修饰符（public， abstract， final的某个子集）
- 这个类型直接接口的一个有序列表
域信息（成员变量）
- JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
- 域的相关信息包括：域名称、域类型、域修饰符（public， private， protected， static， final， volatile， transient的某个子集）
方法信息：JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序
- 方法名称
- 方法的返回类型（或void）
- 方法参数的数量和类型（按顺序）
- 方法的修饰符（public， private， protected， static， final，synchronized， native ， abstract的一个子集）
- 方法的字节码（bytecodes）、操作数栈、局部变量表及大小（ abstract和native 方法除外）
- 异常表（ abstract和native方法除外）
  每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
non-final的类变量
以下代码不会报空指针异常

public class MethodAreaTest {
    public static void main(String[] args) {
        Order order = null;
        order.hello();
        System.out.println(order.count);
    }
}

class Order {
    public static int count = 1;
    public static final int number = 2;

    public static void hello() {
        System.out.println("hello!");
    }
}

(Order.class字节码文件，右键Open in Teminal打开控制台，使用javap -v -p Order.class > test.txt 将字节码文件反编译并输出txt文件,可以看到
static final修饰的常量number在编译时就被赋值了，
static修饰的变量count是在类加载的准备阶段被赋值为默认的初始化值,在初始化的时候赋予正确的初始化值

 public static int count;
    descriptor: I
    flags: ACC_PUBLIC, ACC_STATIC

  public static final int number;
    descriptor: I
    flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
    ConstantValue: int 2

3、方法区的演进细节

3.1、演进

Jdk 1.6 及之前：有永久代，静态变量、字符串常量池1.6在方法区
Jdk 1.7 ：有永久代，但已经逐步 " 去永久代 "，字符串常量池(StringTable)、静态变量移除,保存在堆中
jdk 1.8 及之后：无永久代，常量池1.8在元空间。但静态变量、字符串常量池仍在堆中

3.2、为什么要用元空间取代永久代？

为永久代设置空间大小是很难确定的
①. 永久代参数设置过小,在某些场景下,如果动态加载的类过多,容易产生Perm区的OOM,比如某个实际Web工程中,因为功能点比较多,在运行过程中,要不断动态加载很多类,经常出现致命错误
②. 永久代参数设置过大,导致空间浪费
③. 默认情况下,元空间的大小受本地内存限制)
对永久代进行调优是很困难的
(方法区的垃圾收集主要回收两部分：常量池中废弃的常量和不再使用的类型,而不再使用的类或类的加载器回收比较复杂,full gc 的时间长)

3.3、字符串常量池（StringTable）为什么要调整？

StringTable只存储对java.lang.String实例的引用，而不存储String对象的内容

jdk7中将StringTable放到了堆空间中。因为永久代的回收效率很低,在full gc的时候才能触发。而full gc是老年代的空间不足、永久代不足才会触发
这就导致StringTable回收效率不高,而我们开发中会有大量的字符串被创建,回收效率低,导致永久代内存不足,放到堆里,能及时回收内存

4、设置方法区的大小

jdk7及以前
① -XX:PermSize=100m(默认值是20.75M)
② -XX:MaxPermSize=100m(32位机器默认是64M,64位机器模式是82M)
③ 当JVM加载的类信息容量超过了这个值，会报异常OutOfMemoryError:PerGenspace
④ 图解
jdk8及以后
① -XX:MetaspaceSize=100m(windows下,默认约等于21M)
② -XX:MaxMetaspaceSize=100m(默认是-1,即没有限制)

5、常量池和运行时常量池

位置
常量池——字节码文件
运行时常量池——方法区
关系
类加载后，常量池中的数据会在运行时常量池中存放！

5.1、常量池

常量池，可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型

javap -v -p Order.class

Constant pool:
   #1 = Methodref          #7.#24         // java/lang/Object."<init>":()V
   #2 = Fieldref           #25.#26        // java/lang/System.out:Ljava/io/PrintStream;
   #3 = String             #27            // hello!
   #4 = Methodref          #28.#29        // java/io/PrintStream.println:(Ljava/lang/String;)V
   #5 = Fieldref           #6.#30         // Order.count:I

一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息那就是常量池表（Constant Poo1 Table），包括各种字面量和对类型域和方法的符号引用。

为什么需要常量池？

一个 java 源文件中的类、接口，编译后产生一个字节码文件。而 Java 中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存到常量池，这个字节码包含了指向常量池的引用。在动态链接的时候会用到运行时常量池。
比如如下代码，虽然只有 194 字节，但是里面却使用了 string、System、Printstream 及 Object 等结构。这里代码量其实已经很小了。如果代码多，引用到的结构会更多！

Public class Simpleclass {
public void sayhelloo() {
    System.out.Println (hello) }
}

5.2、运行时常量池

运行时常量池，常量池是 *.class 文件中的，当该类被加载，它的常量池信息就会放入运行时常量池，并把里面的符号地址变为真实地址
运行时常量池（ Runtime Constant Pool）是方法区的一部分。
常量池表（Constant Pool Table）是Class文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
运行时常量池中包含多种不同的常量,包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用，此时不再是常量池中的符号地址了，这里换为真实地址。
(方法区内常量池之中主要存放的两大类常量：字面量和符号引用。
字面量比较接近Java语言层次的常量概念，如文本字符串、被声明为final的常量值等。
而符号引用则属于编译原理方面的概念，包括下面三类常量：
1、类和接口的全限定名
2、字段的名称和描述符
3、方法的名称和描述符)

6、如何证明静态变量的存在

/**
 1、《深入理解Java虚拟机》中的案例：
 2、staticObj、instanceObj、localObj存放在哪里？
 */
public class StaticObjTest {
    static class Test {
        static ObjectHolder staticObj = new ObjectHolder();
        ObjectHolder instanceObj = new ObjectHolder();

        void foo() {
            ObjectHolder localObj = new ObjectHolder();
            System.out.println("done");
        }
    }

    private static class ObjectHolder {
    }

    public static void main(String[] args) {
        Test test = new StaticObjTest.Test();
        test.foo();
    }
}

staticObj随着Test的类型信息存放在方法区，instance0bj 随着Test的对象实例存放在Java堆，localobject则是存放在foo()方法栈帧的局部变量表中

hsdb>scanoops 0x00007f32c7800000 0x00007f32c7b50000 JHSDB_ _TestCase$Obj ectHolder
0x00007f32c7a7c458 JHSDB_ TestCase$Obj ectHolder
0x00007f32c7a7c480 JHSDB_ TestCase$Obj ectHolder
0x00007f32c7a7c490 JHSDB_ TestCase$Obj ectHolder

测试发现：三个对象的数据在内存中的地址都落在Eden区范围内，所以结论：只要是对象实例必然会在Java堆中分配
接着，找到了一个引用该staticObj对象的地方，是在一个java.lang.Class的实例里，并且给出了这个实例的地址，通过Inspector查看该对象实例，可以清楚看到这确实是一个
java.lang.Class类型的对象实例，里面有一个名为staticObj的实例字段：
从《Java 虛拟机规范》所定义的概念模型来看，所有 Class 相关的信息都应该存放在方法区之中，但方法区该如何实现，《Java 虚拟机规范》并未做出规定，这就成了一件允许不同虚拟机自己灵活把握的事情。JDK7 及其以后版本的 Hotspot 虚拟机选择把静态变量与类型在 Java 语言一端的映射 Class 对象存放在一起，存储于java 堆之中，从我们的实验中也明确验证了这一点.

7、方法区的垃圾回收

背景
(1).有些人认为方法区（如Hotspot，虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如JDK11 时期的 ZGC 收集器就不支持类卸载）
(2).一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前 Sun 公司的Bug 列表中，曾出现过的若干个严重的 Bug 就是由于低版本的 Hotspot 虚拟机对此区域未完全回收而导致内存泄漏。

方法区的垃圾收集主要回收两部分内容：常量池中废奔的常量和不再使用的类型
先来说说方法区内常量池之中主要存放的两大类常量：字面量和符号引用。字面量比较接近Java语言层次的常量概念，如文本字符串、被声明为final的常量值等。而符号引用则属于编译原理方面的概念，包括下面三类常量
- 类和接口的全限定名
- 字段的名称和描述符
- 方法的名称和描述符
HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。回收废弃常量与回收Java堆中的对象非常类似。
判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：
- 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例。
- 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法
Java虛拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了-Xnoclassgc 参数进行控制，还可以使用-verbose：class以及-XX： +TraceClass-Loading、-XX：+TraceClassUnLoading查看类加载和卸载信息
在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及oSGi这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力