内存很空却频繁gc_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总耗时

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 classTest {

public static ReferenceQueue refQueue = new ReferenceQueue();

public static Map map = new HashMap<>();

public PhantomReferencephanRef;

public voidtest() throws InterruptedException {

Object obj = newObject();

phanRef = new PhantomReference(obj, refQueue);

// map.put(phanRef, phanRef);

}

}

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

public static voidmain(String[] args) throws InterruptedException {

Test test = newTest();

test.test();

//PhantomReference 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);这行代码存在时,输出

nulljava.lang.ref.PhantomReference@4d591d15

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

nulljava.lang.ref.PhantomReference@4d591d15

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

解决方案:

1:调整HikariCP连接池的参数

2:调整jvm堆内存的参数

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

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

参考文章