面试连环炮之JVM

本文主要是介绍面试连环炮之JVM，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

面试连环炮系列专栏，暂不想换工作的同学可补充知识盲点查缺补漏，准备换工作的同学可针对性突击训练，不打无准备之战。面试战场所向披靡，成为offer收割机，找到心仪的工作。

楼主努力更新，争取每日多更。有想关注的方向可留言，楼主针对性更新。已更新的内容也会不断更新完善增加更多的"炮弹"，祝大家面试时可以吊打面试官。

1、JAVA类的生命周期？

2、类装载器分类？

3、什么是双亲委派机制有什么作用？

4、JVM内存模型

5、JVM常用调优参数？

6、对象销毁算法？

7、垃圾回收算法及使用场景？

8、JVM中都有哪些常见的垃圾回收器，各自的特点是什么？

9、JVM监控工具、分析工具？

10、Young GC和Full GC，分别在什么情况下会发生？日志应该怎么看？

11、GC问题定位排查、OOM分析解决？

12、JVM调优目标？生产环境调优经验？

1、JAVA类的生命周期？

加载机制分为装载、验证、准备、解析、初始化、使用、卸载。

连接分为（验证、准备、解析）

2、类装载器分类？

（1）启动类加载器（Bootstrap ClassLoader）用来加载java核心类库，加载$JAVA_HOME中 jre/lib/rt.jar里所有的class或Xbootclassoath选项指定的jar，无法被java程序直接引用。
（2）扩展类加载器（extensions class loader）：它用来加载Java的扩展库。Java虚拟机的实现会提供一个扩展库目录。
该类加载器在此目录里面查找并加载 Java类。包括$JAVA_HOME中jre/lib/*.jar或 -Djava.ext.dirs指定目录下的jar包。
（3）系统类加载器（system class loader）也叫应用类加载器：它根据Java应用的类路径（CLASSPATH）来加载Java类。一般来说，Java应用的类都是由它来完成加载的。可以通过ClassLoader.getSystemClassLoader0来获取它。加载classpath中指定的jar包及 Djava.class.path所指定目录下的类和jar包。
（4）用户自定义类加载器，通过继承 java.lang.ClassLoader类的方式实现。通过java.lang.ClassLoader的子类自定义加载class，属于应用程序根据自身需要自定义的ClassLoader，如tomcat、jboss都会根据j2ee规范自行实现ClassLoader。如何自定义类加载器，继承ClassLoader类,覆盖findClass(String className)方法

3、什么是双亲委派机制有什么作用？

如果一个类加载器在接到加载类的请求时，先查找是否已经加载过，如果没有被加载过，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。

Java类随着加载它的类加载器一起具备了一种带有优先级的层次关系。
比如，Java中的Object类，它存放在rt.jar之中,无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object在各种类加载环境中都是同一个类。
如果不采用双亲委派模型，那么由各个类加载器自己取加载的话，那么系统中会存在多种不同的Object类。
打破双亲委派模型案例
Tomcat WebAppClassLoader 类加载器，目的为了隔离不同应用之间的影响。

4、JVM内存模型

JVM内存结构共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。

堆内存	存放对象实例，几乎所有的对象实例都在这里分配内存	线程共享
方法区	储类信息、常量、静态变量等数据	线程共享
栈内存	存储局部变量表、操作栈、动态链接、方法出口等信息	线程私有
本地方法栈	本地方法栈则是为虚拟机使用到的Native方法服务	线程私有
程序计数器	当前线程所执行的字节码的行号指示器	线程私有

方法区又称非堆内存，很多人愿意把方法区称为“永久代”，本质上两者并不等价，使用永久代来实现方法区而已。jdk7及以前永久代，jdk8及以后元空间。元空间不在虚拟机设置的内存中，而是使用本地内存

堆内存

堆内存是虚拟机所管理的内存中最大的一块。Java堆划分为新生代和老年代两个区域默认比例为1:2。而年轻代又被分成Eden区、From Survivor区、To Survivor区三部分，默认情况下年轻代按照8:1:1的比例来分配；
新生代：所有新生成的对象都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个 Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，复制次数达到一定数量或大对象新生代Eden区无法装入时将被装入年老代。复制算法垃圾回收。

老年代：在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。可年老代中存放的是一些生命周期较长的对象。标记压缩法垃圾回收。
java堆和非堆内存是日后jvm调优的主战场。

5、JVM常用调优参数？

java -X 命令可以查看参数提示。

准表化参数不会变，非标准化参数可能在每个JDK版本中有所变化，但是就目前来看X开头的非标准化的参数改变的也是非常少。
格式：-XX:[+-]<name> 表示启用或者禁用name属性。
例子：-XX:+UseG1GC（表示启用G1垃圾收集器）
堆设置-Xms 初始堆大小，ms是memory start的简称 ，等价于-XX:InitialHeapSize-Xmx 最大堆大小，mx是memory max的简称 ，等价于参数-XX:MaxHeapSize
注意：在通常情况下，服务器项目在运行过程中，堆空间会不断的收缩与扩张，势必会造成不必要的系统压力。所以在生产环境中，JVM的Xms和Xmx要设置成一样的，能够避免GC在调整堆大小带来的不必要的压力。-XX:NewSize=n 设置年轻代大小-XX:NewRatio=n 设置年轻代和年老代的比值。如:-XX:NewRatio=3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4，默认新生代和老年代的比例=1:2。-XX:SurvivorRatio=n 年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个，默认是8，表示
Eden:S0:S1=8:1:1
如：-XX:SurvivorRatio=3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5。-XX:MaxPermSize=n 设置持久代大小-XX:MetaspaceSize  设置元空间大小
收集器设置-XX:+UseSerialGC 设置串行收集器-XX:+UseParallelGC 设置并行收集器-XX:+UseParalledlOldGC 设置并行年老代收集器-XX:+UseConcMarkSweepGC 设置并发收集器
垃圾回收统计信息-XX:+PrintGC-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-Xloggc:filenameGC日志输出到文件里filename，比如：-Xloggc:/gc.log
并行收集器设置-XX:ParallelGCThreads=n 设置并行收集器收集时使用的CPU数。并行收集线程数。-XX:MaxGCPauseMillis=n 设置并行收集最大暂停时间-XX:GCTimeRatio=n 设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)-XX:MaxGCPauseMillis=n设置并行收集最大暂停时间
并发收集器设置-XX:+CMSIncrementalMode 设置为增量模式。适用于单CPU情况。-XX:ParallelGCThreads=n 设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。
其他
-XX:+PrintCommandLineFlags查看当前JVM设置过的相关参数Dump异常快照-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath
堆内存出现OOM的概率是所有内存耗尽异常中最高的，出错时的堆内信息对解决问题非常有帮助，所以给JVM设置这个参数(-XX:+HeapDumpOnOutOfMemoryError)，让JVM遇到OOM异常时能输出堆内信息，并通过（-XX:+HeapDumpPath）参数设置堆内存溢出快照输出的文件地址，这对于特别是对相隔数月才出现的OOM异常尤为重要。
-Xms10M -Xmx10M -Xmn2M -XX:SurvivorRatio=8 -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=D:\study\log_hprof\gc.hprof
-XX:OnOutOfMemoryError
表示发生OOM后，运行jconsole.exe程序。这里可以不用加“”，因为jconsole.exe路径Program Files含有空格。利用这个参数，我们可以在系统OOM后，自定义一个脚本，可以用来发送邮件告警信息，可以用来重启系统等等。
-XX:OnOutOfMemoryError="C:\Program Files\Java\jdk1.8.0_151\bin\jconsole.exe"
配置： -Xmx4g –Xms4g –Xmn1200m –Xss512k -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:PermSize=100m
-XX:MaxPermSize=256m -XX:MaxTenuringThreshold=15
解析：
-Xmx4g：堆内存最大值为4GB。
-Xms4g：初始化堆内存大小为4GB 。
-Xmn1200m：设置年轻代大小为1200MB。增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss512k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1MB，以前每个线程堆栈大小为256K。应根据应用线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。
-XX:NewRatio=4：设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=8：设置年轻代中Eden区与Survivor区的大小比值。设置为8，则两个Survivor区与一个Eden区的比值为2:8，一个Survivor区占整个年轻代的1/10
-XX:PermSize=100m：初始化永久代大小为100MB。
-XX:MaxPermSize=256m：设置持久代大小为256MB。    1.8后为：元空间 -XX:MetaspaceSize和-XX:MaxMetaspaceSize
-XX:MaxTenuringThreshold=15：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

6、对象销毁算法？

1、引用计数器
给对象添加一个引用计数器，每当有一个地方引用它时计数器就+1，当引用失效时计数器就-1,。只要计数器等于0的对象就是不可能再被使用的。

此算法在大部分情况下都是一个不错的选择，也有一些著名的应用案例。但是Java虚拟机中是没有使用的。

优点：实现简单、判断效率高。

缺点：很难解决对象之间循环引用的问题。

2、可达分析算法

通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有使用任何引用链时，则说明该对象是不可用的。

优点：更加精确和严谨，可以分析出循环数据结构相互引用的情况；

缺点：实现比较复杂、需要分析大量数据，消耗大量时间、分析过程需要GC停顿（引用关系不能发生变化），即停顿所有Java执行线程（称为"Stop The World"，是垃圾回收重点关注的问题）。

7、垃圾回收算法及使用场景？

标记清除法
两次标记后，还在“ 即将回收 ”集合的对象进行回收。
　　执行过程如下：

　优点：基础的可达性算法，后续的收集算法都是基于这种思想实现的
　　缺点：标记和清除效率不高，产生大量不连续的内存碎片，导致创建大对象时找不到连续的空间，不得不提前触发另一次的垃圾回收。
复制算法
将可用内存按容量分为大小相等的两块，每次只使用其中一块，当这一块的内存用完了，就将还存活的对象复制到另外一块内存上，然后再把已使用过的内存空间一次清理掉。
　　复制算法执行过程如下：

优点：实现简单，效率高。解决了标记-清除算法导致的内存碎片问题。
缺点：代价太大，将内存缩小了一半。效率随对象的存活率升高而降低。
现在的商业虚拟机都采用这种算法（需要改良1:1的缺点）来回收新生代。
标记整理
标记过程和标记-清理算法一致（也是基于可达性分析算法）。整理和标记-清理不同的是，该算法不是针对可回收对象进行清理，而是根据存活对象进行整理。让存活对象都向一端移动，然后直接清理掉边界以外的内存。
标记-整理算法示意图

优点：不会像复制算法那样随着存活对象的升高而降低效率，不像标记-清除算法那样产生不连续的内存碎片
缺点：效率不高，除了像标记-清除算法的标记过程外，还多了一步整理过程，效率更低。

分代收集算法

当前商业虚拟机的垃圾收集都是采用“ 分代收集 ”算法。

根据对象存活周期的不同将内存划分为几块。一般把java堆分为新生代和老年代。JVM根据各个年代的特点采用不同的收集算法。

新生代中，每次进行垃圾回收都会发现大量对象死去，只有少量存活，因此比较适合复制算法。只需要付出少量存活对象的复制成本就可以完成收集。

老年代中，因为对象存活率较高，没有额外的空间进行分配担保，所以适合标记-清理、标记-整理算法来进行回收。

8、JVM中都有哪些常见的垃圾回收器，各自的特点是什么？

新生代收集器：Serial、ParNew、Parallel Scavenge

老年代收集器：CMS、Serial Old、Parallel Old

整堆收集器： G1

并行收集：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。

并发收集：指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。用户程序在继续运行，而垃圾收集程序运行在另一个CPU上。

吞吐量：即CPU用于运行用户代码的时间与CPU总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )）。例如：虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%

一：Serial 收集器
Serial收集器是最基本的、发展历史最悠久的收集器。

特点：单线程、简单高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程手机效率。收集器进行垃圾回收时，必须暂停其他所有的工作线程，直到它结束（Stop The World）。

应用场景：适用于Client模式下的虚拟机。

Serial / Serial Old收集器运行示意图

二：ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本。

除了使用多线程外其余行为均和Serial收集器一模一样（参数控制、收集算法、Stop The World、对象分配规则、回收策略等）。

特点：多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

和Serial收集器一样存在Stop The World问题

应用场景：ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了Serial收集器外，唯一一个能与CMS收集器配合工作的。

ParNew/Serial Old组合收集器运行示意图如下：

三：Parallel Scavenge 收集器
与吞吐量关系密切，故也称为吞吐量优先收集器。

特点：属于新生代收集器也是采用复制算法的收集器，又是并行的多线程收集器（与ParNew收集器类似）。

该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：GC自适应调节策略（与ParNew收集器最重要的一个区别）

GC自适应调节策略：Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。

Parallel Scavenge收集器使用两个参数控制吞吐量：

XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间

XX:GCRatio 直接设置吞吐量的大小。

四：Serial Old 收集器
Serial Old是Serial收集器的老年代版本。

特点：同样是单线程收集器，采用标记-整理算法。

应用场景：主要也是使用在Client模式下的虚拟机中。也可在Server模式下使用。

Server模式下主要的两大用途（在后续中详细讲解···）：

在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用。
作为CMS收集器的后备方案，在并发收集Concurent Mode Failure时使用。
Serial / Serial Old收集器工作过程图（Serial收集器图示相同）：

五：Parallel Old 收集器
是Parallel Scavenge收集器的老年代版本。

特点：多线程，采用标记-整理算法。

应用场景：注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old 收集器。

Parallel Scavenge/Parallel Old收集器工作过程图：

六：CMS收集器
一种以获取最短回收停顿时间为目标的收集器。

特点：基于标记-清除算法实现。并发收集、低停顿。

应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务。

CMS收集器的运行过程分为下列4步：

初始标记：标记GC Roots能直接到的对象。速度很快但是仍存在Stop The World问题。

并发标记：进行GC Roots Tracing 的过程，找出存活对象且用户线程可并发执行。

重新标记：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题。

并发清除：对标记的对象进行清除回收。

CMS收集器的内存回收过程是与用户线程一起并发执行的。

CMS收集器的工作过程图：

CMS收集器的缺点：

对CPU资源非常敏感。
无法处理浮动垃圾，可能出现Concurrent Model Failure失败而导致另一次Full GC的产生。
因为采用标记-清除算法所以会存在空间碎片的问题，导致大对象无法分配空间，不得不提前触发一次Full GC。
七：G1收集器
一款面向服务端应用的垃圾收集器。

特点如下：

并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿时间。部分收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让Java程序继续运行。

分代收集：G1能够独自管理整个Java堆，并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

空间整合：G1运作期间不会产生空间碎片，收集后能提供规整的可用内存。

可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。

G1为什么能建立可预测的停顿时间模型？

因为它有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这样就保证了在有限的时间内可以获取尽可能高的收集效率。

G1与其他收集器的区别：

其他收集器的工作范围是整个新生代或者老年代、G1收集器的工作范围是整个Java堆。在使用G1收集器时，它将整个Java堆划分为多个大小相等的独立区域（Region）。虽然也保留了新生代、老年代的概念，但新生代和老年代不再是相互隔离的，他们都是一部分Region（不需要连续）的集合。

G1收集器存在的问题：

Region不可能是孤立的，分配在Region中的对象可以与Java堆中的任意对象发生引用关系。在采用可达性分析算法来判断对象是否存活时，得扫描整个Java堆才能保证准确性。其他收集器也存在这种问题（G1更加突出而已）。会导致Minor GC效率下降。

G1收集器是如何解决上述问题的？

采用Remembered Set来避免整堆扫描。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用对象是否处于多个Region中（即检查老年代中是否引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆进行扫描也不会有遗漏。

如果不计算维护 Remembered Set 的操作，G1收集器大致可分为如下步骤：

初始标记：仅标记GC Roots能直接到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象。（需要线程停顿，但耗时很短。）

并发标记：从GC Roots开始对堆中对象进行可达性分析，找出存活对象。（耗时较长，但可与用户程序并发执行）

最终标记：为了修正在并发标记期间因用户程序执行而导致标记产生变化的那一部分标记记录。且对象的变化记录在线程Remembered Set Logs里面，把Remembered Set Logs里面的数据合并到Remembered Set中。（需要线程停顿，但可并行执行。）

筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。（可并发执行）

9、JVM监控工具、分析工具？

JPS
用 jps（JVM process Status）可以查看虚拟机启动的所有进程、执行主类的全名、JVM启动参数，比如当执行了 JPSTest 类中的 main 方法后（main 方法持续执行），执行 jps -l可看到下面的JPSTest类的 pid 为 31354，加上 -v 参数还可以看到JVM启动参数。
jstat
用 jstat（JVM Statistics Monitoring Tool）监视虚拟机信息 jstat -gc pid 500 10：每 500 毫秒打印一次 Java 堆状况（各个区的容量、使用容量、gc 时间等信息），打印 10 次。jstat 还可以以其他角度监视各区内存大小、监视类装载信息等，具体可以 google jstat 的详细用法。
jmap
用 jmap（Memory Map for Java）查看堆内存信息执行 jmap -histo pid 可以打印出当前堆中所有每个类的实例数量和内存占用，如下，class name 是每个类的类名（[B 是 byte 类型，[C是 char 类型，[I 是 int 类型），bytes 是这个类的所有示例占用内存大小，instances 是这个类的实例数量。
执行 jmap -dump 可以转储堆内存快照到指定文件，比如执行：
jmap -dump:format=b,file=/data/jvm/dumpfile_jmap.hprof 3361
可以把当前堆内存的快照转储到 dumpfile_jmap.hprof 文件中，然后可以对内存快照进行分析。
jconsole、jvisualvm
利用 jconsole、jvisualvm 分析内存信息（各个区如 Eden、Survivor、Old 等内存变化情况），如果查看的是远程服务器的 JVM，程序启动需要加上如下参数：
"-Dcom.sun.management.jmxremote=true"
"-Djava.rmi.server.hostname=12.34.56.78"
"-Dcom.sun.management.jmxremote.port=18181"
"-Dcom.sun.management.jmxremote.authenticate=false"
"-Dcom.sun.management.jmxremote.ssl=false"
下图是 jconsole 界面，概览选项可以观测堆内存使用量、线程数、类加载数和 CPU 占用率；内存选项可以查看堆中各个区域的内存使用量和左下角的详细描述（内存大小、GC 情况等）；线程选项可以查看当前 JVM 加载的线程，查看每个线程的堆栈信息，还可以检测死锁；VM 概要描述了虚拟机的各种详细参数。
jps，JVM Process Status Tool,显示指定系统内所有的HotSpot虚拟机进程。
jstat，JVM statistics Monitoring是用于监视虚拟机运行时状态信息的命令，它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。
jmap，JVM Memory Map命令用于生成heap dump文件
jhat，JVM Heap Analysis Tool命令是与jmap搭配使用，用来分析jmap生成的dump，jhat内置了一个微型的HTTP/HTML服务器，生成dump的分析结果后，可以在浏览器中查看
jstack，用于生成java虚拟机当前时刻的线程快照。
jinfo，JVM Conﬁguration info 这个命令作用是实时查看和调整虚拟机运行参数

第三方工具
MAT、GChisto、GCViewer、JProfiler、arthas、async-profile。

10、Young GC和Full GC，分别在什么情况下会发生？日志应该怎么看？

调用 System.gc()只是建议虚拟机执行 Full GC，但是虚拟机不一定真正去执行。不建议使用这种方式，而是让虚拟机管理内存。
2. 未指定老年代和新生代大小，堆伸缩时会产生fullgc,所以一定要配置-Xmx、-Xms
3. 老年代空间不足
老年代空间不足的常见场景比如大对象、大数组直接进入老年代、长期存活的对象进入老年代等。
为了避免以上原因引起的 Full GC，应当尽量不要创建过大的对象以及数组。
除此之外，可以通过 -Xmn 虚拟机参数调大新生代的大小，让对象尽量在新生代被回收掉，不进入老年代。
还可以通过 -XX:MaxTenuringThreshold 调大对象进入老年代的年龄，让对象在新生代多存活一段时间。
在执行Full GC后空间仍然不足，则抛出错误：java.lang.OutOfMemoryError: Java heap space
分析一把你们线上系统的JVM GC日志，

新生代内存不够用时候发生MGC也叫YGC
-XX:+PrintGC 输出GC日志
-XX:+PrintGCDetails 输出GC的详细日志
-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）
-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
-Xloggc:../logs/gc.log 日志文件的输出路径
在我做了如下的设置

-XX:+PrintGCDetails
-XX:+PrintHeapAtGC
-XX:+PrintGCDateStamps
-XX:+PrintTenuringDistribution
-verbose:gc
-Xloggc:gc.log
-XX:+PrintGCDetails 启用日志
-XX:-UseAdaptiveSizePolicy 禁用动态调整，使SurvivorRatio可以起作用
-XX:SurvivorRatio=8 设置Eden:Survivior=8
-XX:NewSize=10M -XX:MaxNewSize=10M 设置整个新生代的大小为10M
默认垃圾收集器为：Parallel Scavenge
GC日志的离线分析
GCView、GCeasy查看

11、GC问题定位排查、OOM分析解决？

1. 调用 System.gc()只是建议虚拟机执行 Full GC，但是虚拟机不一定真正去执行。不建议使用这种方式，而是让虚拟机管理内存。
2. 未指定老年代和新生代大小，堆伸缩时会产生fullgc,所以一定要配置-Xmx、-Xms
3. 老年代空间不足
老年代空间不足的常见场景比如大对象、大数组直接进入老年代、长期存活的对象进入老年代等。
为了避免以上原因引起的 Full GC，应当尽量不要创建过大的对象以及数组。
除此之外，可以通过 -Xmn 虚拟机参数调大新生代的大小，让对象尽量在新生代被回收掉，不进入老年代。
还可以通过 -XX:MaxTenuringThreshold 调大对象进入老年代的年龄，让对象在新生代多存活一段时间。
在执行Full GC后空间仍然不足，则抛出错误：java.lang.OutOfMemoryError: Java heap space
分析一把你们线上系统的JVM GC日志，

12、JVM调优目标？生产环境调优经验？

JVM 调优目标：使用较小的内存占用来获得较高的吞吐量或者较低的延迟。
程序在上线前的测试或运行中有时会出现一些大大小小的 JVM 问题，比如 cpu load 过高、请求延迟、tps 降低等，甚至出现内存泄漏（每次垃圾收集使用的时间越来越长，垃圾收集频率越来越高，每次垃圾收集清理掉的垃圾数据越来越少）、内存溢出导致系统崩溃，因此需要对 JVM 进行调优，使得程序在正常运行的前提下，获得更高的用户体验和运行效率。
这里有几个比较重要的指标：
        内存占用：程序正常运行需要的内存大小。
        延迟：由于垃圾收集而引起的程序停顿时间。
        吞吐量：用户程序运行时间占用户程序和垃圾收集占用总时间的比值。
当然，和 CAP 原则一样，同时满足一个程序内存占用小、延迟低、高吞吐量是不可能的，程序的目标不同，调优时所考虑的方向也不同，在调优之前，必须要结合实际场景，有明确的的优化目标，找到性能瓶颈，对瓶颈有针对性的优化，最后进行测试，通过各种监控工具确认调优后的结果是否符合目标。
JVM 配置方面，一般情况可以先用默认配置（基本的一些初始参数可以保证一般的应用跑的比较稳定了），在测试中根据系统运行状况（会话并发情况、会话时间等），结合 gc 日志、内存监控、使用的垃圾收集器等进行合理的调整，当老年代内存过小时可能引起频繁 Full GC，当内存过大时 Full GC 时间会特别长。
那么 JVM 的配置比如新生代、老年代应该配置多大最合适呢？答案是不一定，调优就是找答案的过程，物理内存一定的情况下，新生代设置越大，老年代就越小，Full GC 频率就越高，但 Full GC 时间越短；相反新生代设置越小，老年代就越大，Full GC 频率就越低，但每次 Full GC 消耗的时间越大。
建议如下：
-Xms 和 -Xmx 的值设置成相等，堆大小默认为 -Xms 指定的大小，默认空闲堆内存小于 40% 时，JVM 会扩大堆到 -Xmx 指定的大小；空闲堆内存大于 70% 时，JVM 会减小堆到 -Xms 指定的大小。如果在 Full GC 后满足不了内存需求会动态调整，这个阶段比较耗费资源。
新生代尽量设置大一些，让对象在新生代多存活一段时间，每次 Minor GC 都要尽可能多的收集垃圾对象，防止或延迟对象进入老年代的机会，以减少应用程序发生 Full GC 的频率。
老年代如果使用 CMS 收集器，新生代可以不用太大，因为 CMS 的并行收集速度也很快，收集过程比较耗时的并发标记和并发清除阶段都可以与用户线程并发执行。
方法区大小的设置，1.6 之前的需要考虑系统运行时动态增加的常量、静态变量等，1.7 只要差不多能装下启动时和后期动态加载的类信息就行。
代码实现方面，性能出现问题比如程序等待、内存泄漏除了 JVM 配置可能存在问题，代码实现上也有很大关系：
避免创建过大的对象及数组：过大的对象或数组在新生代没有足够空间容纳时会直接进入老年代，如果是短命的大对象，会提前出发 Full GC。
避免同时加载大量数据，如一次从数据库中取出大量数据，或者一次从 Excel 中读取大量记录，可以分批读取，用完尽快清空引用。
当集合中有对象的引用，这些对象使用完之后要尽快把集合中的引用清空，这些无用对象尽快回收避免进入老年代。
可以在合适的场景（如实现缓存）采用软引用、弱引用，比如用软引用来为 ObjectA 分配实例：SoftReferenceobjectA=new SoftReference(); 在发生内存溢出前，会将 objectA 列入回收范围进行二次回收，如果这次回收还没有足够内存，才会抛出内存溢出的异常。
避免产生死循环，产生死循环后，循环体内可能重复产生大量实例，导致内存空间被迅速占满。
尽量避免长时间等待外部资源（数据库、网络、设备资源等）的情况，缩小对象的生命周期，避免进入老年代，如果不能及时返回结果可以适当采用异步处理的方式等。