了解：Java底层深入-JVM调优

Java底层深入-JVM调优笔记：

说一说JVM中的内存泄露和内存溢出?

        JVM内存调优的参数的类型？

        说一说常见的JVM内存调优的参数?

        说一说JVM内存调优的工具?

JVM的性能指标有哪些?

GC日志工具用过吗?

说说常见的JVM调优的问题和对应的原因?

有没有进行过JVM的调优?

以上这些面试题是否在面试过程中有被问到呢? 

一. JVM中的内存泄露和内存溢出

- 内存泄露：

      内存泄漏是指本应该被GC回收的无用对象没有被回收，导致的内存空间的浪费 。当内存泄露严重时会导致OOM。

- 内存溢出：

    就是通常遇到的OutOfMemoryError异常,它俗理解就是内存不够，通常在运行大型程序时发生，当程序所需要的内存远远超出了JVM内存所承受大小，就会报出OutOfMemoryError异常。

二.JVM的参数类型

1.标准参数（-），所有的JVM实现都必须实现这些参数的功能，而且向后兼容；

2.非标准参数（-X），默认JVM实现这些参数的功能，但是并不保证所有jvm实现都满足，且不保证向后兼容；

3.非Stable参数（-XX），此类参数各个jvm实现会有所不同，将来可能会随时取消，需要慎重使用

   -XX:+ 启用选项  

    -XX:- 不启用选项

  -XX:选项名= 给选项设置一个数字类型值，可跟单位，例如 -XX:MaxPermSize=64m方法区所能占用的最大内存

    -XX:选项名= 给选项设置一个字符串值，例如-XX:HeapDumpPath=./dump.core

三.JVM标准参数

-client 设置jvm使用client模式，使用于一般PC

-server 使用server模式，启动速度虽然慢 但效率高 适用于服务器 

-verbose:class 输出jvm载入类的相关信息，当jvm报告说找不到类或者类冲突时进行诊断。

-verbose:gc 输出每次GC的相关情况。

-verbose:jni 输出native方法调用的相关情况，一般用于诊断jni调用错误信息

四. JVM非标准参数

-Xmn 新生代内存大小的最大值，包括E区和两个S区的总和 可以指定值的单位 如 k m g

-Xms 初始堆的大小，也是堆大小的最小值，默认值是总共的物理内存/64（且小于1G）

-Xmx 堆的最大值，如果Xms和Xmx都不设置，则两者大小会相同，默认情况下，当堆中可用内存大于70%时，堆内存会开始减少，一直减小到-Xms的大小；

-Xss 这个参数用于设置每个线程的栈内存，默认1M，一般来说是不需要改的

-Xloggc:file 与-verbose:gc功能类似，只是将每次GC事件的相关情况记录到一个文件中

五.JVM非Stable参数

性能参数（ Performance Options）：用于JVM的性能调优和内存分配控制，如初始化内存大小的设置；

-XX:MaxNewSize=size新生成对象能占用内存的最大值      

-XX:MaxPermSize=64m方法区所能占用的最大内存（非堆内存）

-XX:PermSize=64m方法区分配的初始内存    

-XX:MaxTenuringThreshold=15 对象在新生代存活区切换的次数，大于该值会进入老年代

-XX:MaxHeapFreeRatio=70 GC后java堆中空闲量占的最大比例，大于该值，则堆内存会减少

-XX:MaxMetaspaceSize=256m 最大元空间大小  

–XX:NewRatio=4 设置年轻代和老年代所占的比例   

行为参数（Behavioral Options）：用于改变JVM的基础行为，如GC的方式和算法的选择；

-XX:+UseSerialGC 启用串行GC，即采用Serial+Serial Old模式

-XX:+UseParallelGC 启用并行GC，即采用Parallel Scavenge+Serial Old收集器组合（-Server模式下的默认组合）

-XX:GCTimeRatio=99设置用户执行时间占总时间的比例（默认值99，即1%的时间用于GC）

-XX:MaxGCPauseMillis=time设置GC的最大停顿时间（这个参数只对Parallel Scavenge有效）-XX:+UseParNewGC使用ParNew+Serial Old收集器组合

调试参数（Debugging Options）：用于监控、打印、输出等jvm参数，用于显示jvm更加详细的信息；

        -XX:-CITime打印消耗在JIT编译的时间

-XX:ErrorFile=./hs_err_pid.log保存错误日志或者数据到文件中

-XX:HeapDumpPath=./java_pid.hprof 指定导出堆信息时的路径或文件名

-XX:-HeapDumpOnOutOfMemoryError 当首次遭遇OOM时导出此时堆中相关信息

六. 常见的JVM调优工具-JVM命令

 1.jps命令:jps主要用来输出JVM中运行的进程状态信息 2.jstat命令:jstat 它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据

3.jstack命令:jstack主要用来查看某个Java进程内的线程堆栈信息，jstack可以定位到线程堆栈，根据堆栈信息我们可以定位到具体代码，所以它在JVM性能调优中使用得非常多。

 4.jinfo是用来查看JVM参数和动态修改部分JVM参数的命令

 5.jmap:常用情况，jmap可以生成 java 程序的 dump 文件， 也可以查看堆内对象示例的统计信息、查看 ClassLoader 的信息以及 finalizer 队列 ,用jmap把进程内存使用情况dump到文件中，再用jhat分析查看

6.jhat是用来分析jmap生成dump文件的命令，jhat内置了应用服务器，可以通过网页查看dump文件分析结果，jhat一般是用在离线分析上。

 

七. 常见的JVM调优工具--可视化工具

jconsole：用于对 JVM 中的内存、线程和类等进行监控；

jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化。

 

八.JVM性能指标

吞吐量：即CPU用于运行用户代码的时间与CPU总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )）。

暂停时间：执行垃圾回收时，程序的工作线程被暂停的时间

内存占用：java堆所占内存的大小

收集频率：垃圾收集的频次

九.GC日志工具

GC日志可视化分析工具GCeasy和GCviewer。通过GC日志可视化分析工具，我们可以很方便的看到JVM各个分代的内存使用情况、垃圾回收次数、垃圾回收的原因、垃圾回收占用的时间、吞吐量等，这些指标在我们进行JVM调优的时候是很有用的。 

- GCeasy是一款在线的GC日志分析器，可以通过GC日志分析进行内存泄露检测、GC暂停原因分析、JVM配置建议优化等功能，而且是可以免费使用 。在线分析工具 https://gceasy.io/index.jsp

- GCViewer是一款实用的GC日志分析软件，免费开源使用，你需要安装jdk或者java环境才可以使用。软件为GC日志分析人员提供了强大的功能支持，有利于大大提高分析效率 

 

 

十.GC日志工具-GCviewer

 

十一.调优常见问题和原因

部分开发测试机器出现异常：java.lang.OutOfMemoryError: GC overhead limit exceeded

这个异常代表：GC为了释放很小的空间却耗费了太多的时间。

其原因一般有两个：

1，堆太小

2，有死循环或大对象

一个服务系统，经常出现卡顿，Full GC时间太长可能的原因:

1，新生代太小，导致对象提前进入老年代，触发老年代发生Full GC；

2，老年代较大，进行Full GC时耗时较大；

3，Metaspace 扩容导致

十二.调优案例

机器是 4C8GB 的，分配给了 JVM 1024*8GB/3*2= 5460MB 堆的空间，年轻代大小就有 5460MB/3=1820MBEden 区的大小约 1456MB， Survivor 区大小，大约是 182MB 左右每 12 秒，就会发生一次 Minor GC 执行时间100ms；每隔半个小时，会发生一次 Major GC, 执行时间800ms。

问题：

不管是年轻代还是老年代，这个 GC 频率都有点频繁了 执行时间还可以接受 但也不够完美。

原因：

survivor 区就已经装不下 Minor GC 后的内容了。总有一部分超出的容量，需要老年代来补齐。这些垃圾信息就要保存更长时间，直到老年代空间不足。

大多数都在年轻代就销毁了。如果我们加大年轻代的大小，由于 GC 的时间受到活跃对象数的影响，回收时间并不会增加太多。我们把一半空间给年轻代。也就是下面的配置：

-XX:+UseConcMarkSweepGC -Xmx5460M -Xms5460M -Xmn2730M

GCEasy查看，发现 Minor GC 的间隔，由 12 秒提高到了 18 秒 执行时间70ms。

Minor GC 有所改善，但是并没有显著的提升。相比较而言，Major GC 的间隔增加到了 3 小时,执行时间400ms ，是一个非常大的性能优化。这就是在容量限制下的初步调优方案。

此种场景，我们可以更加激进一些，调大年轻代（顺便调大了幸存区），让对象在年轻代停留的时间更长一些，有更多的 buffer 空间。这样 Minor GC 间隔又可以提高到 23 秒 执行时间50ms。

参数配置：

       -XX:+UseConcMarkSweepGC -Xmx5460M -Xms5460M -Xmn3460M

新的问题 :

由于每秒的请求都非常大，如果应用重启或者更新，流量瞬间打过来，JVM 还没预热完毕，这时候就会有大量的用户请求超时、失败  

为了解决这种问题，通常会逐步的把新发布的机器进行放量预热。比如第一秒 100 请求，第二秒 200 请求，第三秒 500 请求。大型的应用都会有这个预热过程。

如图所示，负载均衡器负责服务的放量，server4 将在 6 秒之后流量正常流通。但是奇怪的是，每次重启大约 20 多秒以后，就会发生一次诡异的 Full GC。

 

一般，Full GC 都是在老年代空间不足的时候执行。但不要忘了，我们还有一个区域叫作 Metaspace，它的容量是没有上限的，超过MaxMetaspaceSize并扩容时，就会发生 Full GC。按照经验，一般调整成 256MB 就足够了。同时，为了避免无限制使用造成操作系统内存溢出，我们同时设置它的上限。配置参数如下：

-XX:+UseConcMarkSweepGC -Xmx5460M -Xms5460M -Xmn3460M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M

经观察，启动后停顿消失。