JVM调优实战

JVM调优好文章，全面

-Xms 参数用于设置JVM启动时的初始堆大小。
-Xmx 参数用于设置JVM可以使用的最大堆内存大小。
这样的设置有助于避免应用在运行过程中频繁地进行内存分配。

垃圾回收器选择和调优

线程堆栈大小调优
Xss1m # 设置每个线程的堆栈大小为1MB 线程堆栈大小应根据应用的实际需求调整，避免过大消耗过多内存，或过小导致栈溢出。

调整年轻代和老年代的比例
-XX:NewRatio 参数用于设置老年代和年轻代的大小比例。

设置Survivor区比例
使用场景：在年轻代中，Eden区和Survivor区的比例会影响对象晋升老年代的速度。根据应用的对象生命周期调整这个比例，可以优化内存管理。
-XX:SurvivorRatio=8 # 设置Eden区与一个Survivor区的大小比例为8，即Eden是Survivor的8倍
适当调整这个比例可以优化对象在年轻代的存活时间，减少老年代的压力。

启用GC日志和调试
使用场景：启用GC日志可以帮助你监控垃圾回收过程，并对性能问题进行诊断。
-XX:+PrintGCDetails # 打印详细的GC日志
-XX:+PrintGCDateStamps # 在GC日志中包含时间戳
-Xloggc:gc.log # 指定GC日志输出文件

设置最大停顿时间目标
使用场景：当应用需要低延迟时，可以设置JVM的最大停顿时间目标，这有助于减少垃圾回收造成的延迟。
-XX:MaxGCPauseMillis 参数用于告诉垃圾回收器尽量在指定的时间内完成垃圾回收。

调整大对象直接进入老年代的阈值
使用场景：对于那些创建了大量大对象的应用，调整这些大对象直接晋升到老年代的阈值，可以减少年轻代垃圾回收的次数。
-XX:PretenureSizeThreshold 参数用于设置一个大小阈值，超过这个大小的对象将直接在老年代分配内存。
这有助于减少大对象在年轻代中的分配和复制，特别是对于那些频繁创建和销毁大对象的应用。

调整GC日志文件的回滚和大小限制
使用场景：当需要长时间收集GC日志进行分析时，管理日志文件的大小和回滚非常重要，以避免消耗过多磁盘空间。
-Xloggc:gc.log # 指定GC日志输出文件
-XX:+UseGCLogFileRotation # 启用GC日志文件的回滚
-XX:NumberOfGCLogFiles=5 # 保留最近的5个GC日志文件
-XX:GCLogFileSize=10M # 每个GC日志文件的最大大小为10MB

使用并行垃圾回收器
使用场景：对于需要高吞吐量的应用，如批处理或后台处理系统，使用并行垃圾回收器可以提高效率。
-XX:+UseParallelGC # 启用并行垃圾回收器
-XX:ParallelGCThreads=4 # 设置垃圾回收时使用的线程数为4

常用命令总结
jps：查看正在运行的 Java 进程
jstat：查看 JVM 统计信息
类装载相关的：
-class：显示 ClassLoader 的相关信息：类的装载、卸载数量、总空间、类装载所消耗的时间等
垃圾回收相关的：

jstat -class 86517
Loaded  Bytes  Unloaded  Bytes     Time
 18051 32345.3        0     0.0     112.14

-gc：显示堆各分区大小、YGC,FGC次数和时长。包括 Eden 区、两个 Survivor 区、老年代、永久代等的容量、已用空间、GC 时间合计等信息

-gccapacity：显示内容与 -gc 基本相同，但输出主要关注 Java 堆各个区域使用到的最大、最小空间
-gcutil：显示内容与 -gc 基本相同，但输出主要关注已使用空间占总空间的百分比

-gccause：与 -gcutil 功能一样，但是会额外输出导致最后一次或当前正在发生的 GC 产生的原因
-gcnew：显示新生代 GC 状况

-gcnewcapacity：显示内容与 -gcnew 基本相同，输出主要关注使用到的最大、最小空间
-gcold：显示老年代 GC 状况

-gcoldcapacity：显示内容与 -gcold 基本相同，输出主要关注使用到的最大、最小空间
-gcpermcapacity：显示永久代使用到的最大、最小空间

JIT 相关的：
-compiler：显示 JIT 编译器编译过的方法、耗时等信息

-printcompilation：输出已经被 JIT 编译的方法

【OOM案例】jstat判断内存溢出（OOM）：比较GC时长占运行时长的比例
我们可以比较 Java 进程的启动时长以及总 GC 时长 (GCT 列)，或者两次测量的间隔时长以及总 GC 时长的增量，来得出 GC 时长占运行时长的比例。

如果该比例超过 20%，则说明目前堆的压力较大;
如果该比例超过 98%，则说明这段时期内几乎一直在GC，堆里几乎没有可用空间，随时都可能抛出 OOM 异常。

示例：统计两次测量的时间间隔内，GC 时长占运行时长的比例：
使用jstat统计GC信息，并显示进程启动时间、统计间隔1000ms、统计20次

【内存泄漏案例】比较老年代内存量上涨速度
每隔一段较长的时间采样多组 OU（老年代内存量） 的最小值，如果这些最小值在上涨，说明无法回收对象在不断增加，可能是内存泄漏导致的。

在长时间运行的 Java 程序中，我们可以运行 jstat 命令连续获取多行性能数据，并取这几行数据中 OU 列（Old Used，已占用的老年代内存）的最小值

然后，我们每隔一段较长的时间重复一次上述操作，来获得多组 OU 最小值。如果这些值呈上涨趋势，则说明该 Java 程序的老年代内存已使用量在不断上涨，这意味着无法回收的对象在不断增加，因此很有可能存在内存泄漏（不再使用的对象仍然被引用，导致GC无法回收）。

jstack：打印指定进程此刻的线程快照
线程快照：该进程内每条线程正在执行的方法堆栈的集合。
生成线程快照的作用：可用于定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等问题。这些都是导致线程长时间停顿的常见原因。当线程出现停顿时，就可以用 jstack 显示各个线程调用的堆栈情况。

在 thread dump 中，要留意下面几种状态

死锁，Deadlock（重点关注）
等待资源，Waiting on condition（重点关注）
等待获取监视器，Waiting on monitor entry（重点关注）
阻塞，Blocked（重点关注）
执行中，Runnable
暂停，Suspended
对象等待中，Object.wait() 或 TIMED＿WAITING
停止，Parked

一次完整的GC流程
1.首先，任何新对象都分配到 eden 空间。两个幸存者空间开始时都是空的。
2.当 eden 空间填满时，将触发一个Minor GC(年轻代的垃圾回收，也称为Young GC)，删除所有未引用的对象，大对象（需要大量连续内存空间的Java对象，如那种很长的字符串）直接进入老年代。
3.所有被引用的对象作为存活对象，将移动到第一个幸存者空间S0，并标记年龄为1，即经历过一次Minor GC。之后每经过一次Minor GC，年龄+1。GC分代年龄存储在对象头的Mark Word里。
4.当 eden 空间再次被填满时，会执行第二次Minor GC，将Eden和S0区中所有垃圾对象清除，并将存活对象复制到S1并年龄加1，此时S0变为空。
5.如此反复在S0和S1之间切换几次之后，还存活的年龄等于15的对象（JDK8默认15，JDK9默认7，-XX:InitialTenuringThreshold=7）在下一次Minor GC时将放到老年代中。
6.当老年代满了时会触发Major GC（也称为Full GC），Major GC 清理整个堆 – 包括年轻代和老年代。

调整GC的触发条件
CMS调整老年代触发回收比例
CMS的并发标记和并发清除阶段是用户线程和回收线程并发执行，如果老年代满了再回收会导致用户线程被强制暂停。所以我们修改回收条件为老年代的60%，保证回收时预留足够空间放新对象。CMS默认是老年代68%时触发回收机制。

//使用多少比例的老年代后开始CMS收集，默认是68%，如果频繁发生SerialOld卡顿，应该调小
-XX:CMSInitiatingOccupancyFraction

G1调整存活阈值
超过存活阈值的Region，其内对象会被混合回收到老年代。G1回收时也要预留空间给新对象。存活阈值默认85%，即当一个内存区块中存活对象所占比例超过 85% 时，这些对象就会通过 Mixed GC 内存整理并晋升至老年代内存区域。
//G1混合垃圾回收周期中要包括的旧区域设置占用率阈值。默认占用率为 65%
-XX:G1MixedGCLiveThresholdPercent=65

【最有效】选择合适的垃圾回收器
JVM调优最实用、最有效的方式是升级垃圾回收器，根据CPU核数，升级当前版本支持的最新回收器。

CPU单核，那么毫无疑问Serial 垃圾收集器是你唯一的选择。
CPU多核，关注吞吐量 ，那么选择Parallel Scavenge+Parallel Old组合（JDK8默认）。
CPU多核，关注用户停顿时间，JDK版本1.6或者1.7，那么选择ParNew+CMS，吞吐量降低但是低停顿。
CPU多核，关注用户停顿时间，JDK1.8及以上，JVM可用内存6G以上，那么选择G1。

内存泄露的9种情况：

1 静态容器里的对象：静态集合类的生命周期与 JVM 程序一致，容器里的对象引用也将一直被引用得不到GC；Java里不准静态方法引用非静态方法也是防止内存泄漏。
2 单例对象引用的外部对象：单例模式里，如果单例对象如果持有外部对象的引用，因为单例对象不会被回收，那么这个外部对象也不会被回收
3 外部类跟随内部类被引用：内部类持有外部类，这个内部类对象被长期引用了，即使那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象将不会被垃圾回收，这也会造成内存泄漏。
4 数据库、网络、IO等连接忘记关闭：在对数据库进行操作的过程中，首先需要建立与数据库的连接，当不再使用时，需要调用 close 方法来释放与数据库的连接。如果对 Connection、Statement 或 ResultSet 不显性地关闭，将会造成大量的对象无法被回收，从而引起内存泄漏。
5 变量作用域不合理：例如一个变量只会在某个方法中使用，却声明为成员变量，并且被使用后没有被赋值为null，将会导致这个变量明明已经没用了，生命周期却还跟对象一致。
6 HashSet中对象改变哈希值：当一个对象被存储进 HashSet 集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了。否则对象哈希值改变，找不到对应的value。
7 缓存引用忘删除：一旦你把对象引用放入到缓存中，他就很容易遗忘，缓存忘了删除，将导致引用一直存在。
8 逻辑删除而不是真实删除：监听器和其他回调：如果客户端在你实现的 API 中注册回调，却没有显示的取消，那么就会积聚。需要确保回调立即被当作垃圾回收的最佳方法是只保存它的弱引用，例如将他们保存成为 软WeakHashMap 中的键。例如出栈只是移动了指针，而没有将出栈的位置赋值null，导致已出栈的位置还存在引用。
9 线程池时，ThreadLocal忘记remove()：使用线程池的时候，ThreadLocal 需要在使用完线程中的线程变量手动 remove()，否则会内存泄漏。因为线程执行完后没有销毁而是被线程池回收，导致ThreadLocal中的对象不能被自动垃圾回收。

CPU飙升
原因
CPU利用率过高，大量线程并发执行任务导致CPU飙升。例如锁等待（例如CAS不断自旋）、多线程都陷入死循环、Redis被攻击、网站被攻击、文件IO、网络IO。

定位步骤
定位进程ID：通过top命令查看当前服务CPU使用最高的进程，获取到对应的pid（进程ID）
定位线程ID：使用top -Hp pid，显示指定进程下面的线程信息，找到消耗CPU最高的线程id
线程ID转十六进制：转十六进制是因为下一步jstack打印的线程快照（线程正在执行方法的堆栈集合）里线程id是十六进制。
定位代码：使用jstack pid | grep tid（十六进制），打印线程快照，找到线程执行的代码。一般如果有死锁的话就会显示线程互相占用情况。
解决问题：优化代码、增加系统资源（增多服务器、增大内存）。

GC调优
GC频率的合理范围
jvm.gc.time：每分钟的GC耗时在1s以内，500ms以内尤佳

jvm.gc.meantime：每次YGC耗时在100ms以内，50ms以内尤佳

jvm.fullgc.count：最多几小时FGC一次，1天不到1次尤佳

jvm.fullgc.time：每次FGC耗时在1s以内，500ms以内尤佳
最差情况下能接受的GC频率：Young GC频率10s一次，每次500ms以内。Full GC频率10min一次，每次1s以内。
其实一小时一次Full GC已经算频繁了，一个不错的应用起码得控制一天一次Full GC。

OOM
1数据量一次性申请的内存过多，比如数据库查询返回值大多，所以做个分页
2.并发过高的情况下，一些连接未释放
3.堆内存不够