NonRegisteringDriver造成的内存频繁FullGc

某天上服务器看了下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连接疯狂的在关闭打开,而在30分钟之内经过多次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.cnblogs.com/MRLL/p/12721295.html

参考文章

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/