JVM实战篇

内存调优

内存溢出和内存泄漏

内存泄漏：在java中如果不再使用一个对象，但是该对象依然在GC ROOT的引用链上，这个对象就不会被垃圾回收器回收。

内存泄漏绝大多数情况都是由堆内存泄漏引起的，所以后续没有特别说明则讨论的都是堆内存泄漏。

少量的内存泄漏是可以容忍的，但是如果发生持续的内存泄漏，就像滚雪球一样越滚越大，不管有多大的内存迟早都会被消耗完，最终导致的结果就是内存溢出。但是产生内存溢出的原因并不是只有内存泄漏。 

常见的内存泄漏就是在大型的java后端应用中，在处理用户的请求之后，没有及时将用户的数据删除。随着用户请求数量越来越多，内存泄漏的对象占满了堆内存最终导致内存溢出。

分布式任务调度系统如Elastic-job、Quartz等进行任务调度是，被调度的Java应用在调度任务结束中出现了内存泄漏，最终导致多次调度之后内存溢出。

解决内存溢出的方法

有四个步骤：发现 诊断 修复 验证

发现问题

TOP命令

VisualVM

 Arthas

 使用arthas tunnel管理所有的需要监控的程序

步骤：

 Prometheus+Grafana

 堆内存状况的对比

 正常就是上下上下，不正常就是一直增长

产生内存溢出的原因一：代码中的内存泄漏

1.equals()和hashcode()

 在定义新类的时候没有重写正确的equals()和hashcode()方法。在时候HashMap，如果使用这个类对象作为key，HashMap在判断Key是否已经存在时，会使用这两个方法，如果重写不正确，就会导致相同的数据被保存多份。

 

解决方案

1.在定义新实体的时候，始终重写epuals()和hashcode()方法、

2.重写时一定要确定使用了唯一的标识去区分不同的对象，比如用户的id等。

3.hashmap使用时尽量使用编号id等数据作为key，不要将整个实体类对象作为key存放

2.内部类引用外部类

（1）非静态的内部类默认会持有外部类，尽管代码上不再使用外部类，所以如果有地方引用了这个非静态内部类，会导致外部类也被引用，垃圾回收时无法回收这个外部类。

解决方案：把内部类改成静态的

（2）匿名内部类对象如果在非静态方法中被创建，会持有调用者对象，垃圾回收时无法回收调用者。 

解决方案：吧那个方法变成静态的

 

3.ThreadLocal的使用

如果仅仅使用手动创建的线程，就算没有调用ThreadLocal的remove方法清理数据，也不会产生内存泄漏。因为当线程被回收时，ThreadLocal也照样会被回收。但是如果使用线程池就不一定了。

解决方案：线程方法执行完，一定要调用ThreadLocal中的remove方法清理对象。

4.String的intern方法

JDK6中字符串常量池位于堆内存中的Perm Gen永久代中，如果不同字符串的intern方法被大量调用，字符串常量池会不停的变大超过永久代上限之后就会产生内存溢出问题。

解决方案：

1.注意代码逻辑，尽量不要将随机生成的字符串加入字符串常量池

2.增加永久代空间的大小，根据实际的测试/估算结果进行设置-XX:MaxPermSize=256M

5.通过静态字段保存对象

如果大量的数据在静态变量中被长期引用，数据就不会被释放，如果这些数据不再使用，就成为了内存泄漏。

解决方案：

（1）尽量减少将对象长时间的保存在静态变量中，如果不再使用，必须将对象删除（比如在集合中）或者将静态变量设置成null

（2）使用单例模式时，尽量使用懒加载，而不是立即加载。

（3）Spring的Bean中不要长期存放大对象，如果是缓存用于提升性能，尽量设置过期时间定期失效。

6.资源没有正常关闭

连接和流这些资源会占用内存，如果使用完之后没有关闭，这部分内存不一定会出现内存泄漏（有可能会），但是会导致close方法不被执行

解决方案：

1.为了防止出现这类的资源对象泄漏问题，必须在finally块中关闭不再使用的资源。

2.从Java7开始，使用try-with-resources语法可以用于自动关闭资源

内存溢出原因二：并发请求问题

模拟并发请求

Apache Jmeter 

它支持插件扩展，生成多样化的测试结果

诊断-内存快照

当堆内存溢出的时候，需要在堆内存溢出的时候将整个堆内存保存下来，生成内存快照文件。

使用MAT打开hprof文件，并选择内存泄漏检测功能，MAT会自行根据内存快照中保存的数据分析内存泄漏的根源。

 

MAT内存泄漏检测的原理---支配树

MAT提供了称为支配树的对象图。支配树展示的是对象实例间的支配关系。在对象引用图中，所有指向对象B的路径都经过对象A则认为对象A支配对象B

浅堆：支配树中对象本身占用的空间（自己的节点）

深堆：支配树中对象的子树就是所有被该对象支配的内容，这些内容组成了对象的深堆，也叫保留集。深堆的大小表示该对象如果可以被回收，能释放多大的内存空间。（自己的节点+子树的节点）

导出运行中系统的内存快照并进行分析

分析超大堆的内存快照

 

修复问题

修复代码中的问题

问题总共可以分为三类

案例1-分页查询文章接口的内存溢出

 解决思路：

1.服务出现OOM内存溢出时，生成内存快照

2.使用MAT分析内存快照，找到内存溢出的对象

3.尝试在开发环境中重现问题，分析代码中问题产生的原因

4.修改代码

5.测试并验证结果

上面案例的解决方案

案例2：mybatis导致的内存溢出

案例3：导出大文件内存溢出

k8s容器

 

 案例4：ThreadLocal使用时占用了大量内存

 

案例5：文章内容审核接口的内存问题

设计1：

 

用MQ是最好的

 诊断方法二 在线定位问题

在线定位问题的步骤

GC调优

就是对垃圾回收进行调优。GC调优的主要目标是避免由垃圾回收引起程序性能下降。

GC调优分为三部分：
1.通过JVM参数设置。

2.特定垃圾回收器的JVM参数设置

3.解决由频繁的FULLGC引起的程序性能问题。

GC调优的核心指标

1.吞吐量

垃圾回收吞吐量：指CPU用于执行用户代码的时间与CPU总执行时间的比值。吞吐量=执行用户代码的时间/（执行用户代码的时间+GC时间）。吞吐量越高垃圾回收效率就越高。允许更多的CPU时间去处理用户的业务，相应的业务吞吐量也就越高。

2.延迟

延迟是指从用户发起一个请求到收到响应这其中经历的时间。

3.内存的使用量

内存使用量指的是Java应用占系统内存的最大值，一般tongguoJVM参数调整，在满足上述两个指标的前提下，这个值越小越好。

GC调优的方法

和内存调优差不多

发现问题

jstat工具

 visualvm

Prometheus+Grafana

GC日志文件

GC Viewer

GCeasy

常见的GC模式

持续的FULLGC是主要解决的问题

诊断问题

选择前三个为主。

优化基础JVM参数

减少对象的产生

就是根据内存调优的方案进行，修改代码

更换垃圾回收器

优化垃圾回收器参数

 

解决思路

实现 GC调优和内存调优

核心流程

性能调优

性能调优共分为4个步骤，其中修复部分要具体问题具体分析且处理方式各不相同

本章着重学习发现问题和诊断问题的方法，目标是准确定位到性能问题的根源

性能调优解决的问题

应用程序在运行过程中经常会出现性能问题，比较常见的性能问题现象是：

1.通过top命令查看CPU占用率高，接近100甚至多核CPU下超过100都是有可能的

2.请求单个服务处理时间特别长，多服务使用skywalking等监控系统来判断是哪个环节性能低下。

3.程序启动之后运行正常，但是在运行一段时间之后无法处理任务的请求（内存和GC正常）

性能调优的核心方法

线程转储的查看方式

 解决CPU占用率高的问题

案例2：接口响应的时间很长的问题

Arthas的trace命令

watch命令

案例3：定位偏底层的性能问题

案例4：线程被耗尽问题

更精细化的性能测试

JIT对程序性能的影响

java程序在运行过程中，JIT即时编译器会实时对代码进行性能优化，所以仅凭少量的测试是无法真实反应运行系统最终给用户提供的性能。如下图，随着执行次数的增加，程序性能会逐渐优化

jmh在使用过程的问题

案例：日期格式化方法性能测试

案例实战部分

问题：小李的项目中有一个获得用户信息的接口性能比较差，他希望能对这个接口在代码中进行彻底的优化，提升性能。

总结

总结