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