jvm系列文章|线上服务器内存不断飙升定位 jvm系列文章|jvm调优

前言

线上服务应用，4核8G的配置，在之前没有配置GC参数的时候，默认是jdk8的并发垃圾回收(JDK8中默认使用组合是: Parallel Scavenge GC 、ParallelOld GC),堆的分配参数也不太合理，这里就不细说了，导致重启后两三天，内存就超过80%，就会收到报警，不胜其烦。

优化历程
第一次优化： 【jvm系列文章|线上服务器内存不断飙升定位】先优化jvm参数配置，可以参考如下网址，在上边填写好服务器信息和日志的路径后，就能生成JVM参数，可以一用；：https://account.heapdump.cn/
配置如下：

-Xmx5440M -Xms5440M -XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+ParallelRefProcEnabled -XX:ErrorFile=/data/logs/hs_err_pidp.log -Xloggc:/data/logs/gc.log -XX:HeapDumpPath=/data/logs -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError"

重启后，比之前好了一些，之前三天有的机器内存超过80%，现在基本上一个多星期才超过，也算是比之前强一些，继续吧，内存不断增加，肯定是有泄露呗；
第二次定位优化：该过程主要分三个操作

检查服务线程，会不会有死锁情况
使用工具分析内存快照，定位内存泄露原因
gc的日志只是有助于观察系统的吞吐量和垃圾回收时间，可以根据报告进行参数的细化调优，但这个相对于前边两项不是重点，还是要优先定位系统代码问题

首先针对第一步

先通过JPS查看进程pid
使用命令

jstack -l 16494 > data/logs/jstack.log

dump当前线程快照信息，进行分析，比如这个是我当时执行后的文件，我复制一部分看下问题情况:

不知道大家看到这里有没有发现问题，一个服务的线程池竟然有20多个，并且每个里边的初始化线程数都是20，相当于空闲时候还有400多个线程在等待任务处理，可以参考MyBlockingQueueForCondition代码，在最后。

java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for<0x0000000672429938> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:403) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)

这个明显是有问题的，创建了很多线程池，但是都没关闭，导致线程在没有任务的情况下都得不到释放，随着时间的延续，这个对内存的消耗也是会上升的，可以复用线程池，减少无效的线程占有，这个就是一个优化点;
还有一个原因，我全局搜了下，代码中有用到**future.get()**方法，这个根据一些经验又参考了一些资料（https://www.shangmayuan.com/a/a900378bbb3d42f7b16db619.html），在使用该方法的时候，最好加上等待时间，防止网络或者其他服务问题，导致线程一直释放不掉，等待时间过长。
针对第二步上边查看线程问题能解决一部分内存问题，但还不够，我们使用命令

jmap -dump:live,format=b,file=../data/logs/dump.bin 17

我这边执行了两次，分别是服务重启后执行了一次（dump.bin），然后过了5天又执行了一次(serviceDump.bin)，有两个dump文件，其实根据第一个文件就已经分析到问题代码了，使用mat分析工具（下载地址：https://www.eclipse.org/mat/downloads.php）

重点看标红的地方,大概的含义如下：

Histogram可以列出内存中的对象，对象的个数以及大小。
Dominator Tree可以列出那个线程，以及线程下面的那些对象占用的空间。
Top consumers通过图形列出最大的object。
Leak Suspects通过MA自动分析泄漏的原因。

接下来我们主要看Dominator Tree和Leak Suspects这两个就行，其实已经能定位出代码的大部分内存泄露的问题了。

看Dominator Tree，占用比例最高的，基本上都是ImageUtils所占用，他里边存放的是ConcurrentHashMap，看代码发现确实是不断的向里边添加数据，并且没有过期时间,本地缓存用的不好呀，情况类似的还有AServiceImpl，这个使用的少了些，但是也存在一样内存泄露的情况，只占1点多，但也是要优化。
看Leak Suspects，两次dump文件的对比，点击details
还再不断的增加，也说明了一样的问题，不多说了，抓紧排期优化吧。。。
java.lang.Thread.State: WAITING (parking)错误，简介版代码参考，其实就是线程在wait等待任务来执行，运行后，打印线程栈信息分析，跟上边一样：

public class MyBlockingQueueForCondition {private Queue queue; private int max = 16; private ReentrantLock lock = new ReentrantLock(); private Condition notEmpty = lock.newCondition(); private Condition notFull = lock.newCondition(); public MyBlockingQueueForCondition(int size) {this.max = size; queue = new LinkedList(); }public void put(Object o) throws InterruptedException {lock.lock(); try {while (queue.size() == max) {notFull.await(); } queue.add(o); notEmpty.signalAll(); } finally {lock.unlock(); } }public Object take() throws InterruptedException {lock.lock(); try {while (queue.size() == 0) {notEmpty.await(); } Object item = queue.remove(); notFull.signalAll(); return item; } finally {lock.unlock(); } }public static void main(String[] args) {MyBlockingQueueForCondition myBlockingQueueForCondition = new MyBlockingQueueForCondition(10); Runnable producer = () -> {while (true) {try {myBlockingQueueForCondition.put(new Object()); } catch (InterruptedException e) {e.printStackTrace(); } } }; new Thread(producer).start(); new Thread(producer).start(); Runnable consumer = () -> {while (true) {try {myBlockingQueueForCondition.take(); } catch (InterruptedException e) {e.printStackTrace(); } } }; new Thread(consumer).start(); new Thread(consumer).start(); } }

参考文章
https://www.cnblogs.com/duanxz/p/6046055.html
https://www.cnblogs.com/duanxz/p/3958504.html