JVM直击重点

JVM直击重点

JVM内存模型

1. JVM中类加载器分类与核心功能

   Java里有如下几种类加载器

   引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等

   扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包

   应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类

   自定义加载器：负责加载用户自定义路径下的类包

   以下是去除行号后的代码和运行结果：

   代码：

   public class TestJDKClassLoader {
       public static void main(String[] args) {
           System.out.println(String.class.getClassLoader());
           System.out.println(com.sun.crypto.provider.DESKeyFactory.class.getClassLoader().getClass().getName());
           System.out.println(TestJDKClassLoader.class.getClassLoader().getClass().getName());
   
           System.out.println();
           ClassLoader appClassLoader = ClassLoader.getSystemClassLoader();
           ClassLoader extClassloader = appClassLoader.getParent();
           ClassLoader bootstrapLoader = extClassloader.getParent();
           System.out.println("the bootstrapLoader : " + bootstrapLoader);
           System.out.println("the extClassloader : " + extClassloader);
           System.out.println("the appClassLoader : " + appClassLoader);
   
           System.out.println();
           System.out.println("bootstrapLoader加载以下文件：");
           URL[] urls = Launcher.getBootstrapClassPath().getURLs();
           for (int i = 0; i < urls.length; i++) {
               System.out.println(urls[i]);
           }
   
           System.out.println();
           System.out.println("extClassloader加载以下文件：");
           System.out.println(System.getProperty("java.ext.dirs"));
   
           System.out.println();
           System.out.println("appClassLoader加载以下文件：");
           System.out.println(System.getProperty("java.class.path"));
       }
   }
   

   运行结果：

   null
   sun.misc.Launcher$ExtClassLoader
   sun.misc.Launcher$AppClassLoader
   
   the bootstrapLoader : null
   the extClassloader : sun.misc.Launcher$ExtClassLoader@3764951d
   the appClassLoader : sun.misc.Launcher$AppClassLoader@14dad5dc
   
   bootstrapLoader加载以下文件：
   file:/D:/dev/Java/jdk1.8.0_45/jre/lib/resources.jar
   file:/D:/dev/Java/jdk1.8.0_45/jre/lib/rt.jar
   file:/D:/dev/Java/jdk1.8.0_45/jre/lib/sunrsasign.jar
   file:/D:/dev/Java/jdk1.8.0_45/jre/lib/jsse.jar
   file:/D:/dev/Java/jdk1.8.0_45/jre/lib/jce.jar
   file:/D:/dev/Java/jdk1.8.0_45/jre/lib/charsets.jar
   file:/D:/dev/Java/jdk1.8.0_45/jre/lib/jfr.jar
   file:/D:/dev/Java/jdk1.8.0_45/jre/classes
   
   extClassloader加载以下文件：
   D:\dev\Java\jdk1.8.0_45\jre\lib\ext;C:\Windows\Sun\Java\lib\ext
   
   appClassLoader加载以下文件：
   D:\dev\Java\jdk1.8.0_45\jre\lib\charsets.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\deploy.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\access-bridge-64.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\cldrdata.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\dnsns.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\jaccess.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\jfxrt.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\localedata.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\nashorn.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\sunec.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\sunjce_provider.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\sunmscapi.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\sunpkcs11.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\ext\zipfs.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\javaws.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\jce.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\jfr.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\jfxswt.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\jsse.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\management-agent.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\plugin.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\resources.jar;D:\dev\Java\jdk1.8.0_45\jre\lib\rt.jar;D:\ideaProjects\project-all\target\classes;C:\Users\zhuge\.m2\repository\org\apache\zookeeper\zookeeper\3.4.12\zookeeper-3.4.12.jar;C:\Users\zhuge\.m2\repository\org\slf4j\slf4j-api\1.7.25\slf4j-api-1.7.25.jar;C:\Users\zhuge\.m2\repository\org\slf4j\slf4j-log4j12\1.7.25\slf4j-log4j12-1.7.25.jar;C:\Users\zhuge\.m2\repository\log4j\log4j\1.2.17\log4j-1.2.17.jar;C:\Users\zhuge\.m2\repository\jline\jline\0.9.94\jline-0.9.94.jar;C:\Users\zhuge\.m2\repository\org\apache\yetus\audience-annotations\0.5.0\audience-annotations-0.5.0.jar;C:\Users\zhuge\.m2\repository\io\netty\netty\3.10.6.Final\netty-3.10.6.Final.jar;C:\Users\zhuge\.m2\repository\com\google\guava\guava\22.0\guava-22.0.jar;C:\Users\zhuge\.m2\repository\com\google\code\findbugs\jsr305\1.3.9\jsr305-1.3.9.jar;C:\Users\zhuge\.m2\repository\com\google\errorprone\error_prone_annotations\2.0.18\error_prone_annotations-2.0.18.jar;C:\Users\zhuge\.m2\repository\com\google\j2objc\j2objc-annotations\1.1\j2objc-annotations-1.1.jar;C:\Users\zhuge\.m2\repository\org\codehaus\mojo\animal-sniffer-annotations\1.14\animal-sniffer-annotations-1.14.jar;D:\dev\IntelliJ IDEA 2018.3.2\lib\idea_rt.jar
   

   代码展示了Java类加载器的层次结构，并打印出了不同类加载器加载的类路径。需要注意的是，String.class.getClassLoader()返回null，这是因为String类是由引导类加载器（Bootstrap ClassLoader）加载的，而引导类加载器不是java.lang.ClassLoader的子类，因此没有父类加载器，返回null。

   2、类加载双亲委派机制是怎么回事

   JVM类加载器是有亲子层级结构的，如下图

   

   双亲委派机制说简单点就是，先找父亲加载加载，不行再由儿子加载器自己加载

   比如我们自己写的一个类，最先会找应用程序类加载器加载，应用程序类加载器会先委托扩展类加载器加载，扩展类加载器再委托引导类

   加载器，顶层引导类加载器在自己的类加载路径里找了半天没找到你自己写的类，则向下退回加载类的请求，扩展类加载器收到回复就自

   己加载，在自己的类加载路径里找了半天也没找到，又向下退回类的加载请求给应用程序类加载器，应用程序类加载器于是在自己的类加

   载路径里找你自己写的类，结果找到了就自己加载了。

   为什么会有双亲委派机制？

   沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心API库被随意篡改

   避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，保证被加载类的唯一性

2. 执行引擎：也称为解释器，负责解释指令，交由操作系统执行。

3. 运行时数据区：JVM的内存区域，包括方法区、堆、虚拟机栈、本地方法栈、程序计数器。

4. 本地接口：与其他语言交互时所使用的接口。

3、Tomcat底层类加载是用的双亲委派机制吗

不是！Tomcat底层类加载打破了双亲委派机制！

一个Tomcat Web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同

一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。

Tomcat自定义加载器

tomcat的几个主要类加载器：

commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；

catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；

sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；

WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见，比如加载war包里相关的

类，每个war包应用都有自己的WebappClassLoader，实现相互隔离，比如不同war包应用引入了不同的spring版本，这样实现就

能加载各自的spring版本；

从图中的委派关系中可以看出：

CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而

CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。

WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。

而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文

件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的热加载功能。

tomcat 这种类加载机制违背了java 推荐的双亲委派模型了吗？答案是：违背了。

很显然，tomcat 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文

件，不会传递给父类加载器，打破了双亲委派机制。

4、说下对象完整创建流程

对象创建的主要流程:

1.类加载检查

虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类

是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

new指令对应到语言层面上讲是，new关键词、对象克隆、对象序列化等。

2.分配内存

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务

等同于把一块确定大小的内存从Java堆中划分出来。

3.初始化零值

内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头）。

4.设置对象头

初始化零值之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象

的GC分代年龄等信息。这些信息存放在对象的对象头Object Header之中。

在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块区域：对象头（Header）、 实例数据（Instance Data）和对齐填充

（Padding）。 HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC分

代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时 间戳等。对象头的另外一部分是类型指针，即对象指向它的类元数据的指针，

虚拟机通过这个指针来确定这个对象是哪个类的实例。

32位对象头

64位对象头

5.执行方法

执行方法，即对象按照程序员的意愿进行初始化。对应到语言层面上讲，就是为属性赋值（注意，这与上面的赋零值不同，这是由

程序员赋的值），和执行构造方法。

5、对象指针压缩是怎么回事

什么是java对象的指针压缩？

1.jdk1.6 update14开始，在64bit操作系统中，JVM支持指针压缩

2.jvm配置参数:UseCompressedOops，compressed­­压缩、oop(ordinary object pointer)­­对象指针

3.启用指针压缩:­XX:+UseCompressedOops(默认开启)，禁止指针压缩:­XX:­UseCompressedOops

6、对象内存分配流程是怎样的

7、解释下对象栈上分配、逃逸分析与标量替换

对象栈上分配

我们通过JVM内存分配可以知道JAVA中的对象都是在堆上进行分配，当对象没有被引用的时候，需要依靠GC进行回收内

存，如果对象数量较多的时候，会给GC带来较大压力，也间接影响了应用的性能。为了减少临时对象在堆内分配的数

量，JVM通过逃逸分析确定该对象不会被外部访问。如果不会逃逸可以将该对象在栈上分配内存，这样该对象所占用的

内存空间就可以随栈帧出栈而销毁，就减轻了垃圾回收的压力。

对象逃逸分析：就是分析对象动态作用域，当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参

数传递到其他地方中。

很显然test1方法中的user对象被返回了，这个对象的作用域范围不确定，test2方法中的user对象我们可以确定当方法结

束这个对象就可以认为是无效对象了，对于这样的对象我们其实可以将其分配在栈内存里，让其在方法结束时跟随栈内

存一起被回收掉。

JVM对于这种情况可以通过开启逃逸分析参数(-XX:+DoEscapeAnalysis)来优化对象内存分配位置，使其通过标量替换优

先分配在栈上(栈上分配)，JDK7之后默认开启逃逸分析，如果要关闭使用参数(-XX:-DoEscapeAnalysis)

**标量替换：**通过逃逸分析确定该对象不会被外部访问，并且对象可以被进一步分解时，JVM不会创建该对象，而是将该

对象成员变量分解若干个被这个方法使用的成员变量所代替，这些代替的成员变量在栈帧或寄存器上分配空间，这样就

不会因为没有一大块连续空间导致对象内存不够分配。开启标量替换参数(-XX:+EliminateAllocations)，JDK7之后默认

开启。

**标量与聚合量：**标量即不可被进一步分解的量，而JAVA的基本数据类型就是标量（如：int，long等基本数据类型以及

reference类型等），标量的对立就是可以被进一步分解的量，而这种量称之为聚合量。而在JAVA中对象就是可以被进一

步分解的聚合量。

栈上分配示例：

**结论：**栈上分配依赖于逃逸分析和标量替换

8、判断对象是否是垃圾的引用计数法有什么问题

给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加1；当引用失效，计数器就减1；任何时候计数器为0

的对象就是不可能再被使用的。

这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决

对象之间相互循环引用的问题。 所谓对象之间的相互引用问题，如下面代码所示：除了对象objA 和 objB 相互引用着对

方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为0，于是引用计数算

法无法通知 GC 回收器回收他们

9、什么样的类能被回收

该类所有的对象实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。

加载该类的 ClassLoader 已经被回收。

该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

10、解释下JVM内部各种垃圾收集算法

分代收集理论

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几

块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。

比如在新生代中，每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可

以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选

择“标记-清除”或“标记-整理”算法进行垃圾收集。注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以

上。

复制算法

为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的

内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对

内存区间的一半进行回收。

标记-清除算法

算法分为“标记”和“清除”阶段：标记存活的对象， 统一回收所有未被标记的对象(一般选择这种)；也可以反过来，标

记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象 。它是最基础的收集算法，比较简单，但是会带来

两个明显的问题：

1. 效率问题 (如果需要标记的对象太多，效率不高)

2. 空间问题（标记清除后会产生大量不连续的碎片）

标记-整理算法

根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回

收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

11、解释下CMS收集器垃圾收集过程

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验

的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基

本上）同时工作。

从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面

几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但

是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的

对象状态发生改变。

重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对

象的标记记录(主要是处理漏标问题)，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶

段时间短。主要用到三色标记里的****增量更新算法(见下面详解)做重新标记。

并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑

色不做任何处理(见下面三色标记算法详解)。

**并发重置：**重置本次GC过程中的标记数据。

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面几个明显的缺点：

对CPU资源敏感（会和服务抢资源）；

无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；

它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-

XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理

执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并

发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent

mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收

12、CMS比较严重的问题并发收集阶段再次触发Full gc怎么处理

CMS垃圾收集器收集垃圾过程中，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标

记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode

lection可以让jvm在执行完标记清除后再做整理

执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并

发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent

mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收

12、CMS比较严重的问题并发收集阶段再次触发Full gc怎么处理

CMS垃圾收集器收集垃圾过程中，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标

记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode

failure"，此时会进入stop the world，用serial old垃圾收集器来回收