JVM--方法区学习笔记

方法区

方法区在逻辑上是堆的一部分，但在具体实现上不强制方法区的位置，不同的虚拟机厂 商可以有不同的实现

如 JDK1.8 之前使用永久代实现，1.8 后使用元空间实现

方法区在 JVM 启动时创建它是所有线程所共享的

方法区用于存储类的结构：

运行时常量池(含字符串常量)、静态变量、类的信息、常量。

类信息： 魔数，版本号，常量池，类（字段和方法），父类和接口数组，字段，方法等 信息

方法区是 JVM 中的一个规范、永久带和元空间是方法区的两个不同实现

JVM 内存模型不同版本间的比较图:

方法区的理解

• 《Java虚拟机规范》中明确说明：‘尽管所有的方法区在逻辑上属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。’但对于HotSpotJVM而言，方法区还有一个别名叫做Non-heap（非堆），目的就是要和堆分开。  所以，方法区可以看作是一块独立于Java堆的内存空间。

• 方法区（Method Area）与Java堆一样，是各个线程共享的内存区域

• 方法区在JVM启动时就会被创建，并且它的实际的物理内存空间中和Java堆区一样都可以是不连续的

• 方法区的大小，跟堆空间一样，可以选择固定大小或者可拓展

• 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误：OOM。

  • 比如：
    • 加载大量的第三方jar包；
    • Tomcat部署的工程过多；
    • 大量动态生成反射类；

• 关闭JVM就会释放这个区域的内存

方法区内存溢出

运行时常量池

• 常量池，就是 一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等信息。

• 运行时常量池，常量池是*.class文件中的，当该类被加载，它的常量池信息就会被放在运行时常量池，并把里面的符号地址变为真实地址

方法区的演进细节

• 首先明确：只有HotSpot才有永久代。 BEA JRockit、IBM J9等来说，是不存在永久代的概念的。原则上如何实现方法区属于虛拟机实现细节，不受《Java虚拟机规范》管束，并不要求统一。

• 针对HotSpot

  版本	方法区实现
  jdk1.6及之前	静态变量及字符串常量池存放在永久代（方法区1.6的实现）上
  jdk1.7	有永久代，但已经逐步“去永久代”，字符串常量池、静态变量移除，保存在堆中
  jdk1.8及之后	无永久代，类型信息、字段、方法、常量保存在本地内存的元空间，但字符串常量池、静态变量仍在堆

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

• 随着Java8的到来，HotSpot VM中再也见不到永久代了。但是这并不意味着类.的元数据信息也消失了。这些数据被移到了一个与堆不相连的本地内存区域，这个区域叫做元空间（ Metaspace ）。

• 由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间。

• 这项改动是很有必要的，原因有：

  • 1）为永久代设置空间大小是很难确定的。
    • 在某些场景下，如果动态加载类过多，容易产生Perm区的O0M。
    • 比如某个实际Web工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现致命错误。 "Exception in thread' dubbo client x.x connector’java.lang.OutOfMemoryError： PermGenspace"
    • 而元空间和永久代之间最大的区别在于：==元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制==。
  • 2）对永久代进行调优是很困难的。。

 StringTable为什么要调整

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

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