码迷,mamicode.com
首页 > 其他好文 > 详细

NonRegisteringDriver造成的内存频繁FullGc

时间:2020-04-16 00:24:58      阅读:254      评论:0      收藏:0      [点我收藏+]

标签:并且   except   get   rup   timeout   interrupt   使用   dump   时间   

技术图片

 

 

 某天上服务器看了下gc情况,发现状况不对,启动了才2天的服务器发生了360次fullgc,这个频率肯定高了

 

说明

S0C、S1C、S0U、S1U:Survivor 0/1区容量(Capacity)和使用量(Used)
EC、EU:Eden区容量和使用量
OC、OU:年老代容量和使用量
PC、PU:永久代容量和使用量
YGC、YGT:年轻代GC次数和GC耗时
FGC、FGCT:Full GC次数和Full GC耗时
GCT:GC总耗时<br><br>

 

jmap下载下内存看下

 

jmap -dump:format=b,file=文件名 [pid]

 

用eclipse的mat工具打开,很明显的就能发现NonRegisteringDriver里的ConcurrentHashMap占用了大量内存

技术图片

 

 

 

去NonRegisteringDriver的源码看看,发现该类只有一个ConcurrentHashMap,也就是connectionPhantomRefs,里面存放了ConnectionImpl的虚引用

技术图片

 

 

 

 

继续往下找,发现在这个位置会放入该map

技术图片

 

 

看下调用链路,猜测是获取数据库链接的时候丢了个jdbcConnection的虚引用进这个map

技术图片

 

 

 

继续找找看看这个存放了虚引用的map在哪会被使用,发现 AbandonedConnectionCleanupThread里起了个线程去遍历虚引用的队列,在虚引用被回收后会进入这个队列,在这边获取后进行链接的cleanup操作

技术图片

 

 

 至此已经清楚ConnectionPhantomReference的作用就是在gc回收之后,能让代码从队列里获取实例再进行相关资源的回收

 

那么问题来了:

1:为什么会造成那么频繁的fullgc

2:connectionPhantomRefs这个map的作用是什么

 

1.1:java的堆内存对象的ygc次数过多后将会进入老年代

一、对象何时进入老年代
(1)当对象首次创建时, 会放在新生代的eden区, 若没有GC的介入,会一直在eden区, GC后,是可能进入survivor区或者年老代

(2)当对象年龄达到一定的大小 ,就会离开年轻代, 进入老年代。 而对象的年龄是由GC的次数决定的

-XX:MaxTenuringThreshold=n  新生代的对象最多经历n次GC, 就能晋升到老年代, 但不是必要条件   

-XX:TargetSurvivorRatio=n  用于设置Survivor区的目标使用率,即当survivor区GC后使用率超过这个值, 就可能会使用较小的年龄作为晋升年龄

(3)除年龄外, 对象体积也会影响对象的晋升的, 若对象体积太大, 新生代无法容纳这个对象

-XX:PretenureSizeThreshold  即对象的大小大于此值, 就会绕过新生代, 直接在老年代分配, 此参数只对串行回收器以及ParNew回收有效, 而对ParallelGC回收器无效

1.2:代码使用的为HikariCP连接池,而HikariCP有几个参数

idleTimeout (连接空闲超时时间,默认 10 分钟)
maxLifetime(连接最大生存时间,默认 30 分钟)
maxPoolSize (连接池最大连接数)
minIdle(最小空闲连接数,默认等于 maxPoolSize)

可以看出当数据库连接空闲时间超过了 idleTimeout,那么将会关闭,直到数量为 minIdle。还有当数据库连接存活时间达到了 maxLifetime ,那么连接也会关闭,然后再创建新的连接,而每次创建新的连接都将重复上述步骤

1.3:而我的系统默认配置了500个连接数(minIdle=maxPoolSize=500),而查看阿里云的监控可以得知活跃的连接数基本就十几个,导致jdbc连接疯狂的在关闭打开,而在10分钟之内经过多次ygc之后,ConnectionImpl都进入了老年代,而老年代的gc间隔很长,就导致connectionPhantomRefs里堆积了一大堆虚引用的对象,而触发一次gc后会释放

 

 

2:为了验证这个map的作用,我建了个类

public class Test  {
    public static ReferenceQueue<Object> refQueue = new ReferenceQueue<Object>();
    public static Map<PhantomReference, PhantomReference> map = new HashMap<>();
    public PhantomReference<Object> phanRef;

    public void test() throws InterruptedException {
        Object obj = new Object();

        phanRef = new PhantomReference<Object>(obj, refQueue);

        //   map.put(phanRef, phanRef);

} }

 

然后在另外一个类里面执行以下方法

 public static void main(String[] args) throws InterruptedException {
        Test test = new Test();
        test.test();
        //PhantomReference<Object> s = drugTest.phanRef;
        //System.out.println(s);
        test = null;
        System.gc();
        System.gc();
        System.gc();
        System.out.println(test.refQueue.poll());
        //System.out.println(s);
        //s = null;
        System.out.println(test.refQueue.poll());
    }

 

当map.put(phanRef, phanRef);这行代码被注释时,输出

null
null

 

当map.put(phanRef, phanRef);这行代码存在时,输出

null
java.lang.ref.PhantomReference@4d591d15

 

当map.put(phanRef, phanRef);这行代码存在时,并且取消PhantomReference<Object> s = drugTest.phanRef; s = null;的注释时输出

null
java.lang.ref.PhantomReference@4d591d15

 

从这个实验可以看出,当phanRef没有被其他地方引用时,当他所属的实例类被回收后他并不会进入到弱引用的队列中(可能和gc机制有关吧)

 

解决方案:

1:调整HikariCP连接池的参数

2:调整jvm堆内存的参数

3:手动删除connectionPhantomRefs这个ConcurrentHashMap中的数据

4:手动调system.gc(我觉得这个方法很扯淡,手动掉还不如让jvm自己判断调呢,反正不会内存溢出)

 

参考文章

https://www.jianshu.com/p/6d37afd1f072

https://www.cnblogs.com/newcj/archive/2011/05/15/2046882.html

https://www.cnblogs.com/yaowen/p/10975241.html

https://blog.csdn.net/u010657094/article/details/104042326/

NonRegisteringDriver造成的内存频繁FullGc

标签:并且   except   get   rup   timeout   interrupt   使用   dump   时间   

原文地址:https://www.cnblogs.com/MRLL/p/12709678.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!