说一下 JVM 的主要组成部分及其作用？

JVM包含两个子系统和两个组件，两个子系统为Class loader(类装载)、Execution engine(执行引擎)；
两个组件为Runtime data area(运行时数据区)、Native Interface(本地接口)。
Class loader(类装载)：根据给定的全限定名类名(如：java.lang.Object)来装载class文件到
Runtime data area中的method area。
Execution engine（执行引擎）：执行classes中的指令。
Native Interface(本地接口)：与native libraries交互，是其它编程语言交互的接口。
Runtime data area(运行时数据区域)：这就是我们常说的JVM的内存。
作用 ：首先通过编译器把 Java 代码转换成字节码，类加载器（ClassLoader）再把字节码加载到内存
中，将其放在运行时数据区（Runtime data area）的方法区内，而字节码文件只是 JVM 的一套指令集
规范，并不能直接交给底层操作系统去执行，因此需要特定的命令解析器执行引擎（Execution
Engine），将字节码翻译成底层系统指令，再交由 CPU 去执行，而这个过程中需要调用其他语言的本
地库接口（Native Interface）来实现整个程序的功能。
下面是Java程序运行机制详细说明
Java程序运行机制步骤
首先利用IDE集成开发工具编写Java源代码，源文件的后缀为.java；
再利用编译器(javac命令)将源代码编译成字节码文件，字节码文件的后缀名为.class；
运行字节码的工作是由解释器(java命令)来完成的。

从上图可以看，java文件通过编译器变成了.class文件，接下来类加载器又将这些.class文件加载到JVM
中。
其实可以一句话来解释：类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运
行时数据区的方法区内，然后在堆区创建一个 java.lang.Class对象，用来封装类在方法区内的数据结
构。

说一下 JVM 运行时数据区 ？

Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存区域划分为若干个不同的数据区域。这些区
域都有各自的用途，以及创建和销毁的时间，有些区域随着虚拟机进程的启动而存在，有些区域则是依
赖线程的启动和结束而建立和销毁。Java 虚拟机所管理的内存被划分为如下几个区域：

不同虚拟机的运行时数据区可能略微有所不同，但都会遵从 Java 虚拟机规范， Java 虚拟机规范规定的
区域分为以下 5 个部分：
程序计数器（Program Counter Register）：当前线程所执行的字节码的行号指示器，字节码解
析器的工作是通过改变这个计数器的值，来选取下一条需要执行的字节码指令，分支、循环、跳
转、异常处理、线程恢复等基础功能，都需要依赖这个计数器来完成；
Java 虚拟机栈（Java Virtual Machine Stacks）：用于存储局部变量表、操作数栈、动态链接、方
法出口等信息；
本地方法栈（Native Method Stack）：与虚拟机栈的作用是一样的，只不过虚拟机栈是服务 Java
方法的，而本地方法栈是为虚拟机调用 Native 方法服务的；
Java 堆（Java Heap）：Java 虚拟机中内存最大的一块，是被所有线程共享的，几乎所有的对象实
例都在这里分配内存；
方法区（Methed Area）：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的
代码等数据。

JVM中哪些是线程共享区 ？

堆区和⽅法区是所有线程共享的，栈、本地⽅法栈、程序计数器是每个线程独有的

说一下堆栈的区别？

物理地址
堆的物理地址分配对对象是不连续的。因此性能慢些。在GC的时候也要考虑到不连续的分配，所以有
各种算法。比如，标记-消除，复制，标记-压缩，分代（即新生代使用复制算法，老年代使用标记——
压缩）
栈使用的是数据结构中的栈，先进后出的原则，物理地址分配是连续的。所以性能快。
内存分别
堆因为是不连续的，所以分配的内存是在 运行期 确认的，因此大小不固定。一般堆大小远远大于栈。
栈是连续的，所以分配的内存大小要在 编译期 就确认，大小是固定的。
存放的内容
堆存放的是对象的实例和数组。因此该区更关注的是数据的存储
栈存放：局部变量，操作数栈，返回结果。该区更关注的是程序方法的执行。
PS：

1. 静态变量放在方法区
2. 静态的对象还是放在堆。
   程序的可见度
   堆对于整个应用程序都是共享、可见的。
   栈只对于线程是可见的。所以也是线程私有。他的生命周期和线程相同。

队列和栈是什么？有什么区别？

队列和栈都是被用来预存储数据的。
操作的名称不同。队列的插入称为入队，队列的删除称为出队。栈的插入称为进栈，栈的删除称为
出栈。
可操作的方式不同。队列是在队尾入队，队头出队，即两边都可操作。而栈的进栈和出栈都是在栈
顶进行的，无法对栈底直接进行操作。
操作的方法不同。队列是先进先出（FIFO），即队列的修改是依先进先出的原则进行的。新来的
成员总是加入队尾（不能从中间插入），每次离开的成员总是队列头上（不允许中途离队）。而栈
为后进先出（LIFO）,即每次删除（出栈）的总是当前栈中最新的元素，即最后插入（进栈）的元
素，而最先插入的被放在栈的底部，要到最后才能删除。

简述Java类加载机制?

虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验，解析和初始化，最终形成可以被
虚拟机直接使用的Java类型。

说一下类装载的执行过程？

类装载分为以下 5 个步骤：
加载：根据查找路径找到相应的 class 文件然后导入；
验证：检查加载的 class 文件的正确性；
准备：给类中的静态变量分配内存空间；
解析：虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为一个标示，而在直
接引用直接指向内存中的地址；
初始化：对静态变量和静态代码块执行初始化工作。

什么是类加载器 ? Java中有哪些类加载器?

实现通过类的权限定名获取该类的二进制字节流的代码块叫做类加载器。
JDK⾃带有三个类加载器：bootstrap ClassLoader、ExtClassLoader、AppClassLoader。
BootStrapClassLoader是ExtClassLoader的⽗类加载器，默认负责加载%JAVA_HOME%lib下的jar包和class⽂件。
ExtClassLoader是AppClassLoader的⽗类加载器，负责加载%JAVA_HOME%/lib/ext⽂件夹下的jar包和class类。
AppClassLoader是⾃定义类加载器的⽗类，负责加载classpath下的类⽂件。

描述一下JVM加载Class文件的原理机制 ？

Java中的所有类，都需要由类加载器装载到JVM中才能运行。类加载器本身也是一个类，而它的工作就
是把class文件从硬盘读取到内存中。在写程序的时候，我们几乎不需要关心类的加载，因为这些都是隐
式装载的，除非我们有特殊的用法，像是反射，就需要显式的加载所需要的类。
类装载方式，有两种 ：
1.隐式装载， 程序在运行过程中当碰到通过new 等方式生成对象时，隐式调用类装载器加载对应的类到
jvm中，
2.显式装载， 通过class.forname()等方法，显式加载需要的类
Java类的加载是动态的，它并不会一次性将所有类全部加载后再运行，而是保证程序运行的基础类(像是
基类)完全加载到jvm中，至于其他类，则在需要的时候才加载。这当然就是为了节省内存开销。

JVM 的双亲委派机制？

JVM 中存在三个默认的类加载器
BootStrapClassLoader
ExtClassLoader
AppClassLoader
AppClassLoader 的父类加载器是 ExtClassLoader,ExtClaasLoader 的父类加载是BootStrapClassLoader

JVM 在加载一个类时,会调用 AppClassLoader 的 loadClass 方法来加载这个类，
不过在这个方法中会先使用 ExtClassLoader 的 loadClass 方法来加载类,同样
ExtClassLoader 的 LoadClass 方法中会先使用 BootStrapClassLoader 来加载类
如果 BootStrapClass 加载到就成功了,如果没有加载到，那么 ExtClassLoader
就会自己尝试加载类，如果没有加载到，那么则会由 AppClassLoader 来加载类。
所以，双亲委派机制指的是，JVM 在加载类时会委派给 Ext 和 BootStrap 进行加载
如果没有加载得到，才由自己加载。

怎么确定⼀个对象到底是不是垃圾？

1. 引⽤计数算法： 这种⽅式是给堆内存当中的每个对象记录⼀个引⽤个数。引⽤个数为0的就认为是
   垃圾。这是早期JDK中使⽤的⽅式。引⽤计数⽆法解决循环引⽤的问题。
2. 可达性算法： 这种⽅式是在内存中，从根对象向下⼀直找引⽤，找到的对象就不是垃圾，没找到的
   对象就是垃圾。

怎么判断对象是否可以被回收？

垃圾收集器在做垃圾回收的时候，首先需要判定的就是哪些内存是需要被回收的，哪些对象是「存活」
的，是不可以被回收的；哪些对象已经「死掉」了，需要被回收。
一般有两种方法来判断：
引用计数器法：为每个对象创建一个引用计数，有对象引用时计数器 +1，引用被释放时计数 -1，
当计数器为 0 时就可以被回收。它有一个缺点不能解决循环引用的问题；
可达性分析算法：从 GC Roots 开始向下搜索，搜索所走过的路径称

什么是STW ？

STW: Stop-The-World，是在垃圾回收算法执⾏过程当中，需要将JVM内存冻结的⼀种状态。在STW
状态下，JAVA的所有线程都是停⽌执⾏的-GC线程除外，native⽅法可以执⾏，但是，不能与JVM交
互。GC各种算法优化的重点，就是减少STW，同时这也是JVM调优的重点。

在Java中，对象什么时候可以被垃圾回收 ？

当对象对当前使用这个对象的应用程序变得不可触及的时候，这个对象就可以被回收了。
垃圾回收不会发生在永久代，如果永久代满了或者是超过了临界值，会触发完全垃圾回收(Full GC)。如
果你仔细查看垃圾收集器的输出信息，就会发现永久代也是被回收的。这就是为什么正确的永久代大小
对避免Full GC是非常重要的原因。

JVM中的永久代中会发生垃圾回收吗 ？

垃圾回收不会发生在永久代，如果永久代满了或者是超过了临界值，会触发完全垃圾回收(Full GC)。如
果你仔细查看垃圾收集器的输出信息，就会发现永久代也是被回收的。这就是为什么正确的永久代大小
对避免Full GC是非常重要的原因。请参考下Java8：从永久代到元数据区
(译者注：Java8中已经移除了永久代，新加了一个叫做元数据区的native内存区)

Java会存在内存泄漏吗？请简单描述 ？

内存泄漏是指不再被使用的对象或者变量一直被占据在内存中。理论上来说，Java是有GC垃圾回收机制
的，也就是说，不再被使用的对象，会被GC自动回收掉，自动从内存中清除。
但是，即使这样，Java也还是存在着内存泄漏的情况，java导致内存泄露的原因很明确：长生命周期的
对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为
长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。

Finalize 遗言对程序的弊端 ？

最重要的是 Finalize 遗言方法无法保证 finalize（）一定能够正常执行
也无法保证在执行结束之后才回收对象
所以依赖 finalize（）完成核心内容是不现实的

说一下 JVM 有哪些垃圾回收算法 ？

标记-清除算法： 标记无用对象，然后进行清除回收。缺点：效率不高，无法清除垃圾碎片。
标记-整理算法： 标记无用对象，让所有存活的对象都向一端移动，然后直接清除掉端边界以外的 内存。
复制算法： 按照容量划分二个大小相等的内存区域，当一块用完的时候将活着的对象复制到另一块上，然后再把已使用的内存空间一次清理掉。缺点：内存使用率不高，只有原来的一半。
分代算法： 根据对象存活周期的不同将内存划分为几块，一般是新生代和老年代，新生代基本采用 复制算法，老年代采用标记整理算法。

标记-清除算法
标记无用对象，然后进行清除回收。
标记-清除算法（Mark-Sweep）是一种常见的基础垃圾收集算法，它将垃圾收集分为两个阶段：
标记阶段：标记出可以回收的对象。
清除阶段：回收被标记的对象所占用的空间。
标记-清除算法之所以是基础的，是因为后面讲到的垃圾收集算法都是在此算法的基础上进行改进的。
优点：实现简单，不需要对象进行移动。
缺点：标记、清除过程效率低，产生大量不连续的内存碎片，提高了垃圾回收的频率。
标记-清除算法的执行的过程如下图所示

复制算法
为了解决标记-清除算法的效率不高的问题，产生了复制算法。它把内存空间划为两个相等的区域，每
次只使用其中一个区域。垃圾收集时，遍历当前使用的区域，把存活对象复制到另外一个区域中，最后
将当前使用的区域的可回收的对象进行回收。
优点：按顺序分配内存即可，实现简单、运行高效，不用考虑内存碎片。
缺点：可用的内存大小缩小为原来的一半，对象存活率高时会频繁进行复制。
复制算法的执行过程如下图所示

标记-整理算法

在新生代中可以使用复制算法，但是在老年代就不能选择复制算法了，因为老年代的对象存活率会较
高，这样会有较多的复制操作，导致效率变低。标记-清除算法可以应用在老年代中，但是它效率不
高，在内存回收后容易产生大量内存碎片。因此就出现了一种标记-整理算法（Mark-Compact）算法，
与标记-整理算法不同的是，在标记可回收的对象后将所有存活的对象压缩到内存的一端，使他们紧凑
的排列在一起，然后对端边界以外的内存进行回收。回收后，已用和未用的内存都各自一边。
优点：解决了标记-清理算法存在的内存碎片问题。
缺点：仍需要进行局部对象移动，一定程度上降低了效率。
标记-整理算法的执行过程如下图所示

在这里插入图片描述

分代收集算法

当前商业虚拟机都采用分代收集的垃圾收集算法。分代收集算法，顾名思义是根据对象的存活周期将内
存划分为几块。一般包括年轻代、老年代 和 永久代，如图所示：

说一下 JVM 有哪些垃圾回收器 ？

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。下图展示了7种
作用于不同分代的收集器，其中用于回收新生代的收集器包括Serial、PraNew、Parallel Scavenge，回
收老年代的收集器包括Serial Old、Parallel Old、CMS，还有用于回收整个Java堆的G1收集器。不同收
集器之间的连线表示它们可以搭配使用。

Serial收集器（复制算法): 新生代单线程收集器，标记和清理都是单线程，优点是简单高效；
ParNew收集器 (复制算法): 新生代收并行集器，实际上是Serial收集器的多线程版本，在多核CPU
环境下有着比Serial更好的表现；
Parallel Scavenge收集器 (复制算法): 新生代并行收集器，追求高吞吐量，高效利用 CPU。吞吐量
= 用户线程时间/(用户线程时间+GC线程时间)，高吞吐量可以高效率的利用CPU时间，尽快完成程
序的运算任务，适合后台应用等对交互相应要求不高的场景；
Serial Old收集器 (标记-整理算法): 老年代单线程收集器，Serial收集器的老年代版本；
Parallel Old收集器 (标记-整理算法)： 老年代并行收集器，吞吐量优先，Parallel Scavenge收集器
的老年代版本；
CMS(Concurrent Mark Sweep)收集器（标记-清除算法）： 老年代并行收集器，以获取最短回收
停顿时间为目标的收集器，具有高并发、低停顿的特点，追求最短GC回收停顿时间。
G1(Garbage First)收集器 (标记-整理算法)： Java堆并行收集器，G1收集器是JDK1.7提供的一个新
收集器，G1收集器基于“标记-整理”算法实现，也就是说不会产生内存碎片。此外，G1收集器不同
于之前的收集器的一个重要特点是：G1回收的范围是整个Java堆(包括新生代，老年代)，而前六种
收集器回收的范围仅限于新生代或老年代。

详细介绍一下 CMS 垃圾回收器 ？

CMS 是英文 Concurrent Mark-Sweep 的简称，是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾
回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。在启动 JVM 的参数加上“-
XX:+UseConcMarkSweepGC”来指定使用 CMS 垃圾回收器。
CMS 使用的是标记-清除的算法实现的，所以在 gc 的时候回产生大量的内存碎片，当剩余内存不能满足
程序运行要求时，系统将会出现 Concurrent Mode Failure，临时 CMS 会采用 Serial Old 回收器进行
垃圾清除，此时的性能将会被降低。

新生代垃圾回收器和老年代垃圾回收器都有哪些？有什么区别 ？

新生代回收器：Serial、ParNew、Parallel Scavenge
老年代回收器：Serial Old、Parallel Old、CMS
整堆回收器：G1
新生代垃圾回收器一般采用的是复制算法，复制算法的优点是效率高，缺点是内存利用率低；老年代回
收器一般采用的是标记-整理的算法进行垃圾回收。

简述分代垃圾回收器是怎么工作的 ？

分代回收器有两个分区：老生代和新生代，新生代默认的空间占比总空间的 1/3，老生代的默认占比是
2/3。
新生代使用的是复制算法，新生代里有 3 个分区：Eden、To Survivor、From Survivor，它们的默认占
比是 8:1:1，它的执行流程如下：
把 Eden + From Survivor 存活的对象放入 To Survivor 区；
清空 Eden 和 From Survivor 分区；
From Survivor 和 To Survivor 分区交换，From Survivor 变 To Survivor，To Survivor 变 From
Survivor。
每次在 From Survivor 到 To Survivor 移动时都存活的对象，年龄就 +1，当年龄到达 15（默认配置是
15）时，升级为老生代。大对象也会直接进入老生代。
老生代当空间占用到达某个值之后就会触发全局垃圾收回，一般使用标记整理的执行算法。以上这些循
环往复就构成了整个分代垃圾回收的整体执行流程。

⼀个对象从加载到JVM，再到被GC清除，都经历了什么过程 ？

1. ⾸先把字节码⽂件内容加载到⽅法区
2. 然后再根据类信息在堆区创建对象
3. 对象⾸先会分配在堆区中年轻代的Eden区，经过⼀次Minor GC后，对象如果存活，就会进⼊
   Suvivor 区。在后续的每次Minor GC中，如果对象⼀直存活，就会在 Suvivor 区来回拷⻉，每移动
   ⼀次，年龄加1
4. 当年龄超过15后，对象依然存活，对象就会进⼊⽼年代
5. 如果经过Full GC，被标记为垃圾对象，那么就会被GC线程清理掉

简述Java内存分配与回收策率以及Minor GC和Major GC ？

所谓自动内存管理，最终要解决的也就是内存分配和内存回收两个问题。前面我们介绍了内存回收，这
里我们再来聊聊内存分配。
对象的内存分配通常是在 Java 堆上分配（随着虚拟机优化技术的诞生，某些场景下也会在栈上分配，
后面会详细介绍），对象主要分配在新生代的 Eden 区，如果启动了本地线程缓冲，将按照线程优先在
TLAB 上分配。少数情况下也会直接在老年代上分配。总的来说分配规则不是百分百固定的，其细节取
决于哪一种垃圾收集器组合以及虚拟机相关参数有关，但是虚拟机对于内存的分配还是会遵循以下几种
「普世」规则：

对象优先在 Eden 区分配

多数情况，对象都在新生代 Eden 区分配。当 Eden 区分配没有足够的空间进行分配时，虚拟机将会发
起一次 Minor GC。如果本次 GC 后还是没有足够的空间，则将启用分配担保机制在老年代中分配内
存。
这里我们提到 Minor GC，如果你仔细观察过 GC 日常，通常我们还能从日志中发现 Major GC/Full
GC。
Minor GC 是指发生在新生代的 GC，因为 Java 对象大多都是朝生夕死，所有 Minor GC 非常频
繁，一般回收速度也非常快；
Major GC/Full GC 是指发生在老年代的 GC，出现了 Major GC 通常会伴随至少一次 Minor GC。
Major GC 的速度通常会比 Minor GC 慢 10 倍以上。

大对象直接进入老年代

所谓大对象是指需要大量连续内存空间的对象，频繁出现大对象是致命的，会导致在内存还有不少空间
的情况下提前触发 GC 以获取足够的连续空间来安置新对象。
前面我们介绍过新生代使用的是标记-清除算法来处理垃圾回收的，如果大对象直接在新生代分配就会
导致 Eden 区和两个 Survivor 区之间发生大量的内存复制。因此对于大对象都会直接在老年代进行分
配。

长期存活对象将进入老年代

虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须判断哪些对象应该放在新生代，哪些对
象应该放在老年代。因此虚拟机给每个对象定义了一个对象年龄的计数器，如果对象在 Eden 区出生，
并且能够被 Survivor 容纳，将被移动到 Survivor 空间中，这时设置对象年龄为 1。对象在 Survivor 区
中每「熬过」一次 Minor GC 年龄就加 1，当年龄达到一定程度（默认 15） 就会被晋升到老年代。

JVM参数有哪些 ？

JVM参数⼤致可以分为三类：

1. 标注指令： -开头，这些是所有的HotSpot都⽀持的参数。可以⽤java -help 打印出来。
2. ⾮标准指令： -X开头，这些指令通常是跟特定的HotSpot版本对应的。可以⽤java -X 打印出来。
3. 不稳定参数： -XX 开头，这⼀类参数是跟特定HotSpot版本对应的，并且变化⾮常⼤。

常用的 JVM 调优的参数都有哪些 ？

-Xms2g：初始化推大小为 2g；
-Xmx2g：堆最大内存为 2g；
-XX:NewRatio=4：设置年轻的和老年代的内存比例为 1:4；
-XX:SurvivorRatio=8：设置新生代 Eden 和 Survivor 比例为 8:2；
–XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器组合；
-XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器组合；
-XX:+UseConcMarkSweepGC：指定使用 CMS + Serial Old 垃圾回收器组合；
-XX:+PrintGC：开启打印 gc 信息；
-XX:+PrintGCDetails：打印 gc 详细信息。
进行监控；
jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的
变化、gc 变化等。

常用的 JVM 调优的参数都有哪些？

-Xms2g：初始化推大小为 2g；
-Xmx2g：堆最大内存为 2g；
-XX:NewRatio=4：设置年轻的和老年代的内存比例为 1:4；
-XX:SurvivorRatio=8：设置新生代 Eden 和 Survivor 比例为 8:2；
–XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器组合；
-XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器组合；
-XX:+UseConcMarkSweepGC：指定使用 CMS + Serial Old 垃圾回收器组合；
-XX:+PrintGC：开启打印 gc 信息；
-XX:+PrintGCDetails：打印 gc 详细信息。

你们项目如何排查 JVM 问题？

对于还在正常运行的系统

1. 可以使用 jmap 来查看 jvm 各个区域的使用情况
2. 可以使用 jstack 来查看线程的运行情况，比如哪些线程阻塞，是否发生死锁
3. 可以通过 jstat 命令来查看垃圾回收的情况，特别是 fullgc，如果发现 fullgc 比较繁琐
   那么就要进行调优了。
4. 通过各个命令的结果，或者 jvisualvm 等工具来进行分析。
5. 首先,初步猜测频繁发送 fullgc 的原因，如果频繁发生 fullgc 但是又一直没有内存溢出，
   那么表示 fullgc 实际上是回收了很多对象了,所以这些对象最好能在 younggc 的过程就直接
   回收掉,避免这些对象进入老年代,对于这种情况，就要考虑这些存活时间不长的对象是不是
   比较大，导致年轻代放不下，直接进入老年代，尝试加大年轻代的大小，如果改完之后 fullgc
   减小，则证明修改有效。
6. 同时，还可以找到占用 cpu 最多的线程，定位到具体的方法，优化这个方法的执行。
   看是否能避免某些对象的创建。
   对于已经发生 OOM 的系统
   一般生产系统中都会设置当系统发生 OOM 时，生成当时的 dump 文件
7. 我们可以利用 jsisualvm 等工具来分析 dump 文件。
8. 根据 dump 文件找到异常的实例对象，和异常的线程（占用 cpu 高）定位到具体的代码。
   然后再进行详细的分析和调试。
   总之，调优不是一蹴而就的，需要分析、推理、实践、总结、再分析最后定位到具体的问题。

说一下 JVM 调优的工具？

JDK 自带了很多监控工具，都位于 JDK 的 bin 目录下，其中最常用的是 jconsole 和 jvisualvm 这两款视
图监控工具。
jconsole：用于对 JVM 中的内存、线程和类等进行监控；
jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的
变化、gc 变化等。