六、JVM从入门到精通之运行时数据区分析（篇三）

前言

hello ,大家好，我是猿小许呀！上一篇中我们将运行时数据区的本地方法栈及堆空间做了详细的讲解说明，接下来我们会对运行时数据区的其他部分进行剖析说明以及代码优化的几种情况 ，Are you ready?
go!

一、JVM之代码优化

1.1 代码优化：逃逸分析

上一篇我们对逃逸分析做了详细说明，如果对其有不太明白的地方，就点击这个传送门可以回顾一下传送门链接，定位到3.5.2
和3.5.3的小节，是专门对逃逸分析做的说明和示例，这里我们就不重复过多说明了

使用逃逸分析，编译器可以对代码做如下优化：

• 一、栈上分配：j将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
• 二、同步省略：如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以考虑不同步。
• 三、分离对象或标量替换:有的对象可能不需要作为一个连续的内存结构存在也可能被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。

package com.jvmTest.userClassLoader;

/*
* 如何快速的判断是否发生了逃逸分析；
* 大家就看new的对象实体是否有可能在方法外被调用。
* */
public class EscapeAnalysis {

    public EscapeAnalysis obj;

    //方法返回EscapeAnalysis对象，发生逃逸
    public EscapeAnalysis getInstance(){
        return obj==null?new EscapeAnalysis():obj;
    }

    //为成员属性赋值，发生逃逸
    public  void setObj(){
        this.obj=new EscapeAnalysis();
    }

    //对象的作用域仅在当前方法中有效，没有发生逃逸
    public void UseEscapeAnalysis(){
        EscapeAnalysis e=new EscapeAnalysis();
    }

    //引用成员变量的值，发生逃逸
    public void useEscapeAnalysis1(){
        EscapeAnalysis e=getInstance();
    }

}

1.2 代码优化之同步省略（消除）

• 如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以考虑不同步。
• 线程同步的代价是相当高的，同步的后果是降低并发性和性能。
• 在动态编译同步代码块的时候，JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。如果没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能够打打提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁清除。

//如下代码
    public void f(){
        Object hollis=new Object();
        synchronized (hollis){
            System.out.println(hollis);
        }
    }

代码中对hollis这个对象进行加锁，但是hollis对象的生命周期只在f()方法中，并不会被其他线程所访问到，所以在JIT编译阶段就会被优化掉。优化成：

 public void f(){
        Object hollis = new Object();
        System.out.println(hollis);
    }

1.3 分离对象或标量替换

有的对象可能不需要作为一个连续的内存结构存在也可能被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。

标量（Scalar) 是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。
相对的，那些还可以分解的数据叫做聚合量（Aggregate),Java中的对象就是聚合两，因为他可以分解成其他聚合量和标量。
在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。

以上代码，经过标量替换后，就会变成：

可以看到，Point这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个标量了，那么标量替换有什么好处呢？就是可以大大减少堆内存的占用，因为一旦不需要创建对象了，那么就不再需要分配堆内存了。

标量替换为栈上分配提供了很好的基础

标量替换参数设置：

• 参数-XX：+EliminateAllocations:开启了标量替换（默认打开），允许将对象打散分配到栈上。

1.3.1 代码测试示例

我们写一段测试代码，并用jprofiler观察是否在堆中的新生代分配了内存

package com.jvmTest.userClassLoader;

/*
* 如何快速的判断是否发生了逃逸分析；
* 大家就看new的对象实体是否有可能在方法外被调用。
* */
public class EscapeAnalysis {

    public static class User{
        public int id;
        public  String name;
    }
    public static void alloc(){
        User user = new User();
        user.id=5;
        user.name="猿小许";
    }

    public static void main(String[] args) {
        long start=System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            alloc();
        }
        long end = System.currentTimeMillis();
        System.out.println("花费的时间为："+(end-start)+"ms");
    }
}

设置开启使用标量替换

结果：

关闭清除分配设置：

-XX:-EliminateAllocations

结果：

是不是被惊讶到了

1.4 逃逸分析的现状

• 关于逃逸分析的论文在1999年就已经发表了，但直到JDK 1.6才有实现，而且这项技术到如今也并不是十分成熟的。
• 其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。
• 一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。
• 虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于JVM设计者的选择。据我所知，oracle HotspotJVM中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是创建在堆上。
• 目前很多书籍还是基于JDK 7以前的版本，JDK已经发生了很大变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是，intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论:对象实例都是分配在堆上。

二、方法区

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

2.2 方法区的基本理解

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

• 方法区（Method Area)与Java堆一样，是各个线程共享的内存区域。
• 方法区在JVM启动的时候被创建，并且它的实际的物理内存空间中和Java堆区一样都可以是不连续的。
• 方法区的大小，跟堆空间一样，可以选择固定大小或者扩展。
• 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误；java.lang.OutofMemmoryError:PermGen space 或者 java.lang.OutOfMemmoryError:Metaspace
• 关闭JVM就会释放这个区域的内存

2.3 HotSpot中方法区的演进

• 在JDK7及以前，习惯上把方法区，称为永久代，jdk8开始，使用元空间取代了永久代。
• 本质上，方法区和永久代并不等价。仅是对hotspot而言的。《java虚拟机规范》对如何实现方法区，不做统一要求，例如：BEA JRockit/IBM J9不存在永久代的概念。
• 现在看来，当年使用永久代，不是好的idea。导致Java程序更容易OOM（超过-XX:MaxPermSize上限)
• 而到了JDK 8，终于完全废弃了永久代的概念，改用与JRocket、J9一样在本地内存中实现的元空间（Metaspace）来代替
• 元空间的本质和永久代累死，都是对JVM规范中方法去的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存
• 永久代、元空间二者并不只是名字变了，内部结构也调整了。
• 根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，就会抛出OOM异常。

2.4 设置方法区大小与OOM

方法区的大小不必是固定的，jvm可以根据应用的需要动态调整

jdk7及以前：

• 通过-XX：PermSize来设置永久代初始化分配空间，默认值是20.75M;-xx:MaxPermSize来设定最大可分配空间。32位机器默认是64M,64位机器模式默认是82M
• 当JVM加载的类信息容量超过了这个值，会报异常OutOfMemoryError：PermGen Space。

jdk8及以后：

• 元数据区大小可以使用参数-XX:MetaspaceSize和-XX:MaxMetaspaceSize指定，替代上述原有的两个参数。
• 默认值依赖于平台，Windows下，-XX:MetaspaceSize是21M,-XX：MaxMetaspaceSize的值是-1，即没有限制。
• 与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存，如果元数据区发生溢出，虚拟机一样会抛出异常OutOfMemoryError:Netaspace
• -XX:MetaspaceSize：设置初始的元空间大小，对于一个64位的服务器端JVM来说，其默认的-XX：MetaspaceSize值为21M,这就是初始的高水位线,一旦触及这个水位线,Full GC将会被触发并卸载没用的类（即这些类对应的类加载器不再存活），然后高水位线将会重置，新的高水位线的值取决于GC后释放了多少元空间。如果释放空间不足，那么在不超过MaxMetaspace时，适当提高该值。如果释放空间过多，则适当降低该值。
• 如果初始化的高水位线设置过低，上诉高水位线调整情况会发生多次。通过垃圾回收器的日志可以观察到Full GC多次调用，为了避免频繁的GC，建议将-XX：MetaSpaceSize设置一个相对较高的值。

2.5 方法区的内部存储结构

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

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

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

域（Field)信息

• JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
• 域的相关信息包括：域名称、域类型、域修饰符（public,private,protexted,static,final,volatile,transient的某个子集）

方法的信息

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

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

2.6 运行时常量池和常量池

• 方法区，内部包含了运行时常量池
• 字节码文件，内部包含了常量池
• 要弄清楚方法区，需要理解清楚ClassFile,因为加载类的信息都在方法区。
• 要弄清楚方法区的运行时敞亮池，需要理解清楚ClassFile中的常量池。如下：
  
  一个有效的字节码文件中除了包含类的版本信息、字段、方法及接口等描述信息外，还包含一项信息就是常量池表（Constant Pool Table),包括各种字面量和对类型、域、和方法的符号引用。
  
  

2.6.1 为什么需要常量池？

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

public class SimpleClass{
   public void sayHello(){
     System.out.println("hello");
     }
 }

虽然只有194字节，但是里面却使用了String、System、PrintStream及Object等结构，这里代码量以及很小了，如果代码多，引用的结构会更多！这里就需要常量池了！

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

2.6.2 运行时常量池

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

2.7 方法区的演进细节

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

StringTable为什么要调整？

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

2.8 方法区的垃圾收集

有些人认为方法区（HotSpot虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如JDK 11时期的ZGC收集器就不支持类卸载）。

一般来说这个区域的回收效果比较令人难以满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收导致内存泄漏。

方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。

判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：

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

Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是被允许，而并不是和对象一样，没有引用了就必然被回收。

好了到此，我们本篇就把运行时数据区的方法区的情况讲解完了，下篇我们就将讲解对象的实例化及直接内存，记得关注点赞哦

推荐阅读

上一篇：五、JVM从入门到精通之运行时数据区分析（篇二）

下一篇：七、JVM从入门到精通之对象实例化过程