java中JVM相关面试

写在前面：
先声明下，这个面试专题，主要是写给自己的，用来在挤公交的时候学习下，顺便做个分享。。。 我就是个小菜鸡。

](JVM)

JVM

1. 堆
   堆（Java Heap） 也叫 Java 堆或者是 GC 堆，它是一个线程共享的内存区域，也是 JVM 中占用内存最大的一块区域，Java 中所有的对象都存储在这里。所有的对象实例以及数组都应当在堆上分配。

当对象或者是变量在方法中被创建之后，其指针可能被线程所引用，而这个对象就被称作指针逃逸或者是引用逃逸。通过逃逸分析可以让变量或者是对象直接在栈上分配，从而极大地降低了垃圾回收的次数，以及堆分配对象的压力，进而提高了程序的整体运行效率。

堆的大小可以通过 -Xms和-Xmx来设置（最大值和最小值）

2. 方法区
   方法区（Method Area） 也被称为非堆区，用于和“Java 堆”的概念进行区分，它也是线程共享的内存区域，用于存储已经被 JVM 加载的类型信息、常量、静态变量、代码缓存等数据。
   在 JDK 1.7 时 HotSpot 虚拟机已经把原本放在永久代的字符串常量池和静态变量等移出了方法区，并且在 JDK 1.8 中完全废弃了永久代的概念。
3. 程序计数器
   程序计数器（Program Counter Register） 线程独有一块很小的内存区域，保存当前线程所执行字节码的位置，包括正在执行的指令、跳转、分支、循环、异常处理等。
4. 虚拟机栈
   虚拟机栈也叫 Java 虚拟机栈（Java Virtual Machine Stack），和程序计数器相同它也是线程独享的，用来描述 Java 方法的执行，在每个方法被执行时就会同步创建一个栈帧，用来存储局部变量表、操作栈、动态链接、方法出口等信息。当调用方法时执行入栈，而方法返回时执行出栈。
5. 本地方法栈
   本地方法栈（Native Method Stacks）与虚拟机栈类似，它是线程独享的，并且作用也和虚拟机栈类似。只不过虚拟机栈是为虚拟机中执行的 Java 方法服务的，而本地方法栈则是为虚拟机使用到的本地（Native）方法服务。
6. 元数据
   在 Java8 中，永久代已经被移除，被一个称为“元数据区”（元空间）的区域所取代。元空间的本质和永久代类似，元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入 native memory, 字符串池和类的静态变量放入 java 堆中，这样可以加载多少类的元数据就不再由MaxPermSize 控制, 而由系统的实际可用空间来控制。

JVM 的执行流程是，首先先把 Java 代码（.java）转化成字节码（.class），然后通过类加载器将字节码加载到内存中，执行引擎（Execution Engine）将字节码翻译成可以被底层操作系统执行的指令再去执行，这样就实现了整个 Java 程序的运行，这也是 JVM 的整体执行流程.。

类的生命周期会经历以下 7 个阶段：

1. 加载阶段
   此阶段用于查到相应的类（通过类名进行查找）并将此类的字节流转换为方法区运行时的数据结构，然后再在内存中生成一个能代表此类的 java.lang.Class 对象，作为方法区这个类的各种数据的入口。(一部分字节码文件格式的验证，在加载阶段还未完成时就已经开始验证了)
2. 验证阶段
   此步骤主要是为了确保 Class 文件的字节流中包含的信息是否符合当前虚拟机的要求，如果不做安全校验的话可能会载入非安全或有错误的字节码，从而导致系统崩溃。

验证的主要动作大概有以下几个：

• 文件格式校验包括常量池中的常量类型、Class 文件的各个部分是否被删除或被追加了其他信息等；
• 元数据校验包括父类正确性校验（检查父类是否有被 final 修饰）、抽象类校验等；
• 字节码校验，此步骤最为关键和复杂，主要用于校验程序中的语义是否合法且符合逻辑；
• 符号引用校验，对类自身以外比如常量池中的各种符号引用的信息进行匹配性校验。

3. 准备阶段
   此阶段是用来初始化并为类中定义的静态变量分配内存的，在方法区中分配这些变量所使用的内存空间。
   HotSpot 虚拟机在 JDK 1.7 之前都在方法区，而 JDK 1.8 之后此变量会随着类对象一起存放到 Java 堆中。

public static int v = 8080;

实际上变量 v 在准备阶段过后的初始值为 0 而不是 8080。将 v 赋值为 8080 的 put static 指令是程序被编译后，存放于类构造器方法之中。

4. 解析阶段
   此阶段主要是用来解析类、接口、字段及方法的，解析是虚拟机将常量池中的符号引用替换为直接引用的过程。

符号引用和直接引用有一个重要的区别：使用符号引用时被引用的目标不一定已经加载到内存中；而使用直接引用时，引用的目标必定已经存在虚拟机的内存中了。

5. 初始化
   初始化阶段 JVM 就正式开始执行类中编写的 Java 业务代码了。到这一步骤之后，类的加载过程就算正式完成了。

双亲委派模式

当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载其中，只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到所需加载的Class），子类加载器才会尝试自己去加载。

作用：为了避免类的重复加载，避免核心API被修改

类加载器：

1. 启动类加载器（BootStrap ClassLoader） <Java_HOme>/lib
2. 扩展类加载器(ExtClassLoader) <Java_HOme>/lib/ext
3. 应用类加载器(AppClassLoader) java-classpath
4. 自定义(Custom ClassLoador)

如何自定义类加载器：继承ClassLoader， 重写findClass方法，调用defineClass()方法

判断一个对象是否为死亡状态

引用计数算法（Reference Counting） 属于垃圾收集器最早的实现算法了，它是指在创建对象时关联一个与之相对应的计数器，当此对象被使用时加 1，相反销毁时 -1。当此计数器为 0 时，则表示此对象未使用，可以被垃圾收集器回收。

引用计数算法的优缺点很明显，其优点是垃圾回收比较及时，实时性比较高，只要对象计数器为 0，则可以直接进行回收操作；而缺点是无法解决循环引用的问题(a和b被互相依赖)

可达性分析算法（Reachability Analysis） 是目前商业系统中所采用的判断对象死亡的常用算法，它是指从对象的起点（GC Roots）开始向下搜索，如果对象到 GC Roots 没有任何引用链相连时，也就是说此对象到 GC Roots 不可达时，则表示此对象可以被垃圾回收器所回收，

垃圾回收的常见算法

1. 标记-清除（Mark-Sweep）算法属于最早的垃圾回收算法，它是由标记阶段和清除阶段构成的。标记阶段会给所有的存活对象做上标记，而清除阶段会把没有被标记的死亡对象进行回收。而标记的判断方法就是前面讲的引用计数算法和可达性分析算法。

标记-清除算法有一个最大的问题就是会产生内存空间的碎片化问题，也就是说标记-清除算法执行完成之后会产生大量的不连续内存，这样当程序需要分配一个大对象时，因为没有足够的连续内存而导致需要提前触发一次垃圾回收动作。

2. 标记-复制算法是标记-清除算法的一个升级，使用它可以有效地解决内存碎片化的问题。它是指将内存分为大小相同的两块区域，每次只使用其中的一块区域，这样在进行垃圾回收时就可以直接将存活的东西复制到新的内存上，然后再把另一块内存全部清理掉。

需要将内存分为大小相同的两块内存，那么内存的实际可用量其实只有原来的一半，这样此算法导致了内存的可用率大幅降低了。

3. 标记-整理算法的诞生晚于标记-清除算法和标记-复制算法，它也是由两个阶段组成的：标记阶段和整理阶段。其中标记阶段和标记-清除算法的标记阶段一样，不同的是后面的一个阶段，标记-整理算法的后一个阶段不是直接对内存进行清除，而是把所有存活的对象移动到内存的一端，然后把另一端的所有死亡对象全部清除。

CG Roots

在 Java 中可以作为 CG Roots 的对象，主要包含以下几个：

所有被同步锁持有的对象，比如被 synchronize 持有的对象；
字符串常量池里的引用（String Table）；
类型为引用类型的静态变量；
虚拟机栈中引用对象；
本地方法栈中的引用对象。

死亡对象判断

当使用可达性分析判断一个对象不可达时，并不会直接标识这个对象为死亡状态，而是先将它标记为“待死亡”状态再进行一次校验。校验的内容就是此对象是否重写了 finalize() 方法，如果该对象重写了 finalize() 方法，那么这个对象将会被存入到 F-Queue 队列中，等待 JVM 的 Finalizer 线程去执行重写的 finalize() 方法，在这个方法中如果此对象将自己赋值给某个类变量时，则表示此对象已经被引用了。因此不能被标识为死亡状态，其他情况则会被标识为死亡状态。

虽然可以从 finalize() 方法中把自己从死亡状态“拯救”出来，但是不建议这样做，因为所有对象的 finalize() 方法只会执行一次。因此同样的代码可能产生的结果是不同的，这样就给程序的执行带来了很大的不确定性。

垃圾收集器

Serial 收集器属于最早期的垃圾收集器，也是 JDK 1.3 版本之前唯一的垃圾收集器。它是单线程运行的垃圾收集器，其单线程是指在进行垃圾回收时所有的工作线程必须暂停，直到垃圾回收结束为止。

Serial 收集器的特点是简单和高效，并且本身的运行对内存要求不高，因此它在客户端模式下使用的比较多。

ParNew 收集器实际上是 Serial 收集器的多线程并行版本

Parallel Scavenge 收集器和 ParNew 收集器类似，它也是一个并行运行的垃圾回收器；不同的是，该收集器关注的侧重点是实现一个可以控制的吞吐量。而这个吞吐量计算的也很奇怪，它的计算公式是：用户运行代码的时间 / （用户运行代码的时间 + 垃圾回收执行的时间）。比如用户运行的时间是 8 分钟，垃圾回收运行的时间是 2 分钟，那么吞吐量就是 80%。Parallel Scavenge 收集器追求的目标就是将这个吞吐量的值，控制在一定的范围内。

Parallel Scavenge 收集器有两个重要的参数：
-XX:MaxGCPauseMillis 参数：它是用来控制垃圾回收的最大停顿时间；
-XX:GCTimeRatio 参数：它是用来直接设置吞吐量的值的。

Serial Old 收集器为 Serial 收集器的老年代版本，而 Parallel Old 收集器是 Parallel Scavenge 收集器的老年代版本。

CMS（Concurrent Mark Sweep）收集器与以吞吐量为目标的 Parallel Scavenge 收集器不同，它强调的是提供最短的停顿时间，因此可能会牺牲一定的吞吐量。它主要应用在 Java Web 项目中，它满足了系统需要短时间停顿的要求，以此来提高用户的交互体验。

Garbage First（简称 G1）收集器是一款更先进的垃圾收集器，主要面向服务端应用的垃圾收集器。它将内存划分为多个 Region 分区，回收时则以分区为单位进行回收，这样它就可以用相对较少的时间优先回收包含垃圾最多区块。从 JDK 9 之后也成了官方默认的垃圾收集器。实现了逻辑上区分新生代和老年代，物理上没有区分。

新生代划分

将内存(新生代内存)分为一块较大的Eden(伊甸园)空间和两块较小的Survivor(幸存者)空间，每次使用Eden和其中一块Survivor（两个Survivor区域一个称为From区，另一个称为To区域）。
当进行垃圾回收时，将Eden和Survivor中还存活的对象一次性复制到另一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。

如何晋升到老年代

(1)、Eden区满时，进行Minor GC，当Eden和一个Survivor区中依然存活的对象无法放入到Survivor中，则通过分配担保机制提前转移到老年代中。
(2)、若对象体积太大, 新生代无法容纳这个对象，-XX:PretenureSizeThreshold即对象的大小大于此值, 就会绕过新生代, 直接在老年代分配, 此参数只对Serial及ParNew两款收集器有效。
(3)、长期存活的对象将进入老年代。
虚拟机对每个对象定义了一个对象年龄（Age）计数器。当年龄增加到一定的临界值（默认15）时，就会晋升到老年代中，该临界值由参数：-XX:MaxTenuringThreshold来设置。
如果对象在Eden出生并在第一次发生MinorGC时仍然存活，并且能够被Survivor中所容纳的话，则该对象会被移动到Survivor中，并且设Age=1；以后每经历一次Minor GC，该对象还存活的话Age=Age+1。
(4)、动态对象年龄判定。
虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升到老年代，如果在Survivor区中相同年龄（设年龄为age）的对象的所有大小之和超过Survivor空间的一半，年龄大于或等于该年龄（age）的对象就可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄。

CMS 收集器的具体执行流程

CMS 的实现整个过程可以分为四个阶段：
初始标记（CMS initial mark）-> 并发标记（CMS concurrent mark）-> 重新标记（CMS remark）-> 并发清除（CMS concurrent sweep）
首先，初始标记阶段的执行时间很短，它只是标记一下 CG Roots 的关联对象；并发阶段是从 GC Roots 关联的对象进行遍历判断并标识死亡对象，这个过程比较慢，但不需要停止用户线程，用户的线程可以和垃圾收集线程并发执行；而重新标记阶段则是为了判断并标记，刚刚并发阶段用户继续运行的那一部分对象，所以此阶段的执行时间也比较短；最后是并发清除阶段，也就是清除上面标记的死亡对象，由于 CMS 使用的是标记-清除算法，而非标记-整理算法，因此无须移动存活的对象，这个阶段垃圾收集线程也可以和用户线程并发执行。

CMS在收集时产生大量的空间碎片，为了解决这个问题，CMS 收集器提供了一个 -XX:+UseCMS-CompactAtFullCollection 的参数（默认是开启的，此参数从 JDK9 开始废弃），用于在 CMS 收集器进行 Full GC 时开启内存碎片的合并和整理。
但又因为碎片整理的过程必须移动存活的对象，所以它和用户线程是无法并发执行的，为了解决这个问题 CMS 收集器又提供了另外一个参数 -XX:CMSFullGCsBefore-Compaction，用于规定多少次（根据此参数的值决定）之后再进行一次碎片整理。

ZGC

ZGC 收集器是 JDK 11 中新增的垃圾收集器，它是由 Oracle 官方开发的，并且支持 TB 级别的堆内存管理，而且 ZGC 收集器也非常高效，可以做到 10ms 以内完成垃圾收集。

在 ZGC 收集器中没有新生代和老生代的概念，它只有一代。ZGC 收集器采用的着色指针技术，利用指针中多余的信息位来实现着色标记，并且 ZGC 使用了读屏障来解决 GC 线程和应用线程可能存在的并发（修改对象状态的）问题，从而避免了Stop The World（全局停顿），因此使得 GC 的性能大幅提升。

ZGC 的执行流程和 CMS 比较相似，首先是进行 GC Roots 标记，然后再通过指针进行并发着色标记，之后便是对标记为死亡的对象进行回收（被标记为橘色的对象），最后是重定位，将 GC 之后存活的对象进行移动，以解决内存碎片的问题。

JVM 调优

JVM 调优主要是根据实际的硬件配置信息重新设置 JVM 参数来进行调优的，例如，硬件的内存配置很高，但 JVM 因为是默认参数，所以最大内存和初始化堆内存很小，这样就不能更好地利用本地的硬件优势了。因此，需要调整这些参数，让 JVM 在固定的配置下发挥最大的价值。

JVM 常见调优参数包含以下这些：
-Xmx，设置最大堆内存大小；
-Xms，设置初始堆内存大小；
-XX:MaxNewSize，设置新生代的最大内存；
-XX:MaxTenuringThreshold，设置新生代对象经过一定的次数晋升到老生代；
-XX:PretrnureSizeThreshold，设置大对象的值，超过这个值的对象会直接进入老生代；
-XX:NewRatio，设置分代垃圾回收器新生代和老生代内存占比；
-XX:SurvivorRatio，设置新生代 Eden、Form Survivor、To Survivor 占比。

当我们的业务场景会有很多大的临时对象产生时，因为这些大对象只有很短的生命周期，因此需要把“-XX:MaxNewSize”的值设置的尽量大一些，否则就会造成大量短生命周期的大对象进入老生代，从而很快消耗掉了老生代的内存，这样就会频繁地触发 full gc，从而影响了业务的正常运行。

触发FullGC

• 老年代空间不足
  如果创建一个大对象，Eden区域当中放不下这个大对象，会直接保存在老年代当中，如果老年代空间也不足，就会触发Full GC。为了避免这种情况，最好就是不要创建太大的对象。
• 持久代空间不足
  如果有持久代空间的话，系统当中需要加载的类，调用的方法很多，同时持久代当中没有足够的空间，就出触发一次Full GC
• YGC出现promotion failure
  promotion failure发生在Young GC, 如果Survivor区当中存活对象的年龄达到了设定值，会就将Survivor区当中的对象拷贝到老年代，如果老年代的空间不足，就会发生promotion failure， 接下去就会发生Full GC.
• 统计YGC发生时晋升到老年代的平均总大小大于老年代的空闲空间
  在发生YGC是会判断，是否安全，这里的安全指的是，当前老年代空间可以容纳YGC晋升的对象的平均大小，如果不安全，就不会执行YGC,转而执行Full GC。

6 个非常实用的命令行工具

1. jps（虚拟机进程状况工具）
   jps（JVM Process Status tool，虚拟机进程状况工具）它的功能和 Linux 中的 ps 命令比较类似，用于列出正在运行的 JVM 的 LVMID（Local Virtual Machine IDentifier，本地虚拟机唯一 ID），以及 JVM 的执行主类、JVM 启动参数等信息。
   jps [options] [hostid]

常用的 options 选项：
-l：用于输出运行主类的全名，如果是 jar 包，则输出 jar 包的路径；
-q：用于输出 LVMID（Local Virtual Machine Identifier，虚拟机唯一 ID）；
-m：用于输出虚拟机启动时传递给主类 main() 方法的参数；
-v：用于输出启动时的 JVM 参数。

2. jstat（虚拟机统计信息监视工具）
   jstat（JVM Statistics Monitoring Tool，虚拟机统计信息监视工具）用于监控虚拟机的运行状态信息。
   jstat -gc 43704

jstat 常用的查询参数有：
-class，查询类加载器信息；
-compiler，JIT 相关信息；
-gc，GC 堆状态；
-gcnew，新生代统计信息；
-gcutil，GC 堆统计汇总信息。

3. jinfo（查询虚拟机参数配置工具）
   jinfo（Configuration Info for Java）用于查看和调整虚拟机各项参数。
   jinfo -flags 45129
   我们可以通过 jinfo -flag [+/-]（+开启，-关闭）name 来修改虚拟机的参数值。

4. jmap（堆快照生成工具）
   jmap（Memory Map for Java）用于查询堆的快照信息。
   jmap -heap 45129

5. jhat（堆快照分析功能）
   jhat（JVM Heap Analysis Tool，堆快照分析工具）和 jmap 搭配使用，用于启动一个 web 站点来分析 jmap 生成的快照文件。

6. jstack（查询虚拟机当前的线程快照信息）
   jstack（Stack Trace for Java）用于查看当前虚拟机的线程快照，用它可以排查线程的执行状况，例如排查死锁、死循环等问题。
   bin jstack -l 50016

JConsole 和JVisualVM 都位于 JDK 的 bin 目录下

视图调试工具
使用 JConsole 可以监控线程、CPU、类、堆以及 VM 的相关信息，同样我们可以通过线程这一页的信息，发现之前我们故意写的死锁问题，

可以看出 JVisualVM 除了包含了 JConsole 的信息之外，还有更多的详细信息，并且更加智能。直接显示死锁

本文偷个懒，把自己之前的笔记直接复制过来了。

相关推荐