方法区（metaspace,1.8以后元数据区)

方法区

保存在着被加载过的每一个类的信息；这些信息由类加载器在加载类的时候，从类的源文件中抽取出来；static变量信息也保存在方法区中；

可以看做是将类（Class）的元数据，保存在方法区里；

方法区是线程共享的；当有多个线程都用到一个类的时候，而这个类还未被加载，则应该只有一个线程去加载类，让其他线程等待；

方法区的大小不必是固定的，jvm可以根据应用的需要动态调整。jvm也可以允许用户和程序指定方法区的初始大小，最小和最大限制；

方法区同样存在垃圾收集，因为通过用户定义的类加载器可以动态扩展Java程序，这样可能会导致一些类，不再被使用，变为垃圾。这时候需要进行垃圾清理。

图例（方法区中都保存什么）

类型信息

包括以下几点：

类的完整名称（比如，java.long.String）
类的直接父类的完整名称
类的直接实现接口的有序列表（因为一个类直接实现的接口可能不止一个，因此放到一个有序表中）
类的修饰符
可以看做是，对一个类进行登记，这个类的名字叫啥，他粑粑是谁、有没有实现接口， 权限是啥；

类型的常量池 （即运行时常量池）

每一个Class文件中，都维护着一个常量池（这个保存在类文件里面，不要与方法区的运行时常量池搞混），里面存放着编译时期生成的各种字面值和符号引用；这个常量池的内容，在类加载的时候，被复制到方法区的运行时常量池 ；

字面值：就是像string, 基本数据类型，以及它们的包装类的值，以及final修饰的变量，简单说就是在编译期间，就可以确定下来的值；

符号引用：不同于我们常说的引用，它们是对类型，域和方法的引用，类似于面向过程语言使用的前期绑定，对方法调用产生的引用；

存在这里面的数据，类似于保存在数组中，外部根据索引来获得它们 ；

字段信息

• 声明的顺序
• 修饰符
• 类型
• 名字

方法信息

• 声明的顺序
• 修饰符
• 返回值类型
• 名字
• 参数列表（有序保存）
• 异常表（方法抛出的异常）
• 方法字节码（native、abstract方法除外，）
• 操作数栈和局部变量表大小

类变量(即static变量）

非final类变量

在java虚拟机使用一个类之前，它必须在方法区中为每个非final类变量分配空间。非final类变量存储在定义它的类中；

final类变量（不存储在这里）

由于final的不可改变性，因此，final类变量的值在编译期间，就被确定了，因此被保存在类的常量池里面，然后在加载类的时候，复制进方法区的运行时常量池里面 ；final类变量存储在运行时常量池里面，每一个使用它的类保存着一个对其的引用；

对类加载器的引用

jvm必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的，那么jvm会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。

对Class类的引用

jvm为每个加载的类都创建一个java.lang.Class的实例（存储在堆上）。而jvm必须以某种方式把Class的这个实例和存储在方法区中的类型数据（类的元数据）联系起来， 因此，类的元数据里面保存了一个Class对象的引用；

方法表

为了提高访问效率，必须仔细的设计存储在方法区中的数据信息结构。除了以上讨论的结构，jvm的实现者还可以添加一些其他的数据结构，如方法表。jvm对每个加载的非虚拟类的类型信息中都添加了一个方法表，方法表是一组对类实例方法的直接引用(包括从父类继承的方法。jvm可以通过方法表快速激活实例方法。(译者：这里的方法表与C++中的虚拟函数表一样，但java方法全都 是virtual的，自然也不用虚拟二字了。正像java宣称没有 指针了，其实java里全是指针。更安全只是加了更完备的检查机制，但这都是以牺牲效率为代价的,个人认为java的设计者 始终是把安全放在效率之上的，所有java才更适合于网络开发)

JVM如何使用方法区里面的数据

一个例子
为了显示jvm如何使用方法区中的信息，我们据一个例子，我们
看下面这个类：

class Lava {     
  private int speed = 5; // 5 kilometers per hour     
  void flow() {
  } 
}  
  class Volcano {     
    public static void main(String[] args) {         
    Lava lava = new Lava();         
    lava.flow();     
  } 
} 

下面我们描述一下main()方法的第一条指令的字节码是如何被执行的。不同的jvm实现的差别很大，这里只是其中之一。

为了运行这个程序，你以某种方式把“Volcano”传给了jvm。有了这个名字，jvm找到了这个类文件(Volcano.class)并读入，它从类文件提取了类型信息并放在了方法区中，通过解析存在方法区中的字节码，jvm激活了main()方法，在执行时，jvm保持了一个指向当前类(Volcano)常量池的指针。

注意jvm在还没有加载Lava类的时候就已经开始执行了。正像大多数的jvm一样，不会等所有类都加载了以后才开始执行，它只会在需要的时候才加载。

main()的第一条指令告知jvm为列在常量池第一项的类分配足够的内存。jvm使用指向Volcano常量池的指针找到第一项，发现是一个对Lava类的符号引用，然后它就检查方法区看lava是否已经被加载了。

这个符号引用仅仅是类lava的完整有效名”lava“。这里我们看到为了jvm能尽快从一个名称找到一个类，一个良好的数据结构是多么重要。这里jvm的实现者可以采用各种方法，如hash表，查找树等等。同样的算法可以用于Class类的forName()的实现。

当jvm发现还没有加载过一个称为”Lava”的类，它就开始查找并加载类文件”Lava.class”。它从类文件中抽取类型信息并放在了方法区中。

jvm于是以一个直接指向方法区lava类的指针替换了常量池第一项的符号引用。以后就可以用这个指针快速的找到lava类了。而这个替换过程称为常量池解析(constant pool resolution)。在这里我们替换的是一个native指针。

jvm终于开始为新的lava对象分配空间了。这次，jvm仍然需要方法区中的信息。它使用指向lava数据的指针(刚才指向volcano常量池第一项的指针)找到一个lava对象究竟需要多少空间。

jvm总能够从存储在方法区中的类型信息知道某类型对象需要的空间。但一个对象在不同的jvm中可能需要不同的空间，而且它的空间分布也是不同的。(译者：这与在C++中，不同的编译器也有不同的对象模型是一个道理)

一旦jvm知道了一个Lava对象所要的空间，它就在堆上分配这个空间并把这个实例的变量speed初始化为缺省值0。假如lava的父对象也有实例变量，则也会初始化。

当把新生成的lava对象的引用压到栈中，第一条指令也结束了。下面的指令利用这个引用激活java代码把speed变量设为初始值，5。另外一条指令会用这个引用激活Lava对象的flow()方法。

Java中GCRoots包括哪些

在垃圾回收过程中如何判断一个对象是否是垃圾，有两种算法。一种是引用记数法，一种是可达性分析法。

• 引用记数法是早期垃圾回收器中使用的算法，每一个对象维护一个该对象被引用的记数，每引用一次，记数加1，每减少引用1次，引用减1，当引用为0时，表示该对象不再被引用，可以作为垃圾被清除。但是引用记数法有一个最致命的问题，就是无法解决循环引用的问题。
• 可达性分析法，是通过从GCRoots出发，找出内存中的引用链，那么链中的对象表示可达，即不能作为被垃圾回收的。引用链之外的对象即可作为垃圾回收。Java中使用的是可达性分析法。

所以在可达性分析法中，判断哪些引用是GCRoots是垃圾回收的起点，那么这篇文章，就说说哪些引用是GCRoots。
GCRoots

• 虚拟机栈（栈帧中的本地变量表）中引用的对象
• 方法区中类静态属性引用的对象,（一般指被static修饰的对象，加载类的时候就加载到内存中。）
• 方法区中常量引用的对象
• 本地方法栈中JNI（即一般说的native方法）中引用的对象

比如下面的代码：

image

其中，类静态变量 MAPPER，loadAccount 方法的局部变量 account1、account2、accountList 都可以作为 GC Roots（ArrayList 内部是用 Object[] elementData 数组来存放元素的）。
在调用 loadAccount 方法时，堆中的对象都是可达的，因为有 GC Roots 直接或间接引用到这些对象，此时若发生垃圾回收，这些对象是不可被回收的。loadAccount 执行完后，弹出栈帧，方法内的局部变量都被回收了，虽然堆中 ArrayList 对象还指向 elementData 数组，而 elementData 指向 Account 对象，但没有任何 GC Roots 的引用链能达到这些对象，因此这些对象将变为垃圾对象，被垃圾回收器回收掉。

image