共计 6928 个字符,预计需要花费 18 分钟才能阅读完成。
本文要点:
- 一种优雅解决 MySQL 驱动中虚援用导致 GC 耗时较长问题的解决办法
- 虚援用的作用与应用场景
- MySQL 驱动源码中的虚援用剖析
背景
在之前文章中写过 MySQL JDBC 驱动中的虚援用导致 JVM GC 耗时较长的问题 (能够看这里),在驱动代码(mysql-connector-java 5.1.38 版本)中 NonRegisteringDriver 类有个虚援用汇合 connectionPhantomRefs 用于存储所有的数据库连贯,NonRegisteringDriver.trackConnection 办法负责把新创建的连贯放入汇合,虚援用随着工夫积攒越来越多,导致 GC 时解决虚援用的耗时较长,影响了服务的吞吐量:
public ConnectionImpl(String hostToConnectTo, int portToConnectTo, Properties info, String databaseToConnectTo, String url) throws SQLException {
...
NonRegisteringDriver.trackConnection(this);
...
}
public class NonRegisteringDriver implements Driver {
...
protected static final ConcurrentHashMap<ConnectionPhantomReference, ConnectionPhantomReference> connectionPhantomRefs = new ConcurrentHashMap();
protected static void trackConnection(com.mysql.jdbc.Connection newConn) {ConnectionPhantomReference phantomRef = new ConnectionPhantomReference((ConnectionImpl)newConn, refQueue);
connectionPhantomRefs.put(phantomRef, phantomRef);
}
...
}
尝试缩小数据库连贯的生成速度,来升高虚援用的数量,然而成果并不现实。最终的解决方案是通过反射获取虚援用汇合,利用定时工作来定期清理汇合,防止 GC 解决虚援用耗时较长。
// 每两小时清理 connectionPhantomRefs,缩小对 mixed GC 的影响
SCHEDULED_EXECUTOR.scheduleAtFixedRate(() -> {
try {Field connectionPhantomRefs = NonRegisteringDriver.class.getDeclaredField("connectionPhantomRefs");
connectionPhantomRefs.setAccessible(true);
Map map = (Map) connectionPhantomRefs.get(NonRegisteringDriver.class);
if (map.size() > 50) {map.clear();
}
} catch (Exception e) {log.error("connectionPhantomRefs clear error!", e);
}
}, 2, 2, TimeUnit.HOURS);
利用定时工作清理虚援用成果空谷传声,每日几亿申请的服务 mixed GC 耗时只有 10 – 30 毫秒左右,零碎也很稳固,线上运行将近一年没有任何问题。
优化——由暴力破解到优雅配置
最近又有共事遇到雷同的问题,应用的 mysql-connector-java 版本与咱们应用的版本统一,查看最新版本(8.0.32)的代码发现对数据库连贯的虚援用有新的解决形式,不像老版本(5.1.38)中每一个连贯都会生成虚援用,而是能够通过参数来管制是否须要生成。类 AbandonedConnectionCleanupThread
的相干代码如下:
// 动态变量通过 System.getProperty 获取配置
private static boolean abandonedConnectionCleanupDisabled = Boolean.getBoolean("com.mysql.cj.disableAbandonedConnectionCleanup");
public static boolean getBoolean(String name) {return parseBoolean(System.getProperty(name));
}
protected static void trackConnection(MysqlConnection conn, NetworkResources io) {
// 判断配置的属性值来决定是否须要生成虚援用
if (!abandonedConnectionCleanupDisabled) {
···
ConnectionFinalizerPhantomReference reference = new ConnectionFinalizerPhantomReference(conn, io, referenceQueue);
connectionFinalizerPhantomRefs.add(reference);
···
}
}
mysql-connector-java 的维护者应该是留神到了虚援用对 GC 的影响,所以优化了代码,让用户能够自定义虚援用的生成。
有了这个配置,就能够在启动参数上设置属性:
java -jar app.jar -Dcom.mysql.cj.disableAbandonedConnectionCleanup=true
或者在代码里设置属性:
System.setProperty(PropertyDefinitions.SYSP_disableAbandonedConnectionCleanup,"true");
当 com.mysql.cj.disableAbandonedConnectionCleanup=true 时,生成数据库连贯时就不会生成虚援用,对 GC 就没有任何影响了。
倡议还是应用第一种形式,通过启动参数配置更灵便一点。
什么是虚援用
有些读者看到这里晓得 mysql-connector-java 生成的虚援用对 GC 有一些副作用,然而还不太理解虚援用到底是什么,有什么作用,这里咱们在虚援用上做一点点拓展。
Java 虚援用(Phantom Reference)是 Java 中一种非凡的援用类型,它是最弱的一种援用。与其余援用不同,虚援用并不会影响对象的生命周期,也不会影响对象的垃圾回收。虚援用次要用于在对象被回收时收到零碎告诉,以便在回收时执行一些必要的清理工作。
上述虚援用的定义还是比拟难了解,咱们用代码来辅助了解:
先来生成一个虚援用:
// 虚援用队列
ReferenceQueue<Object> queue = new ReferenceQueue<>();
// 关联对象
Object o = new Object();
// 调用构造方法生成一个虚援用 第一个参数就是关联对象 第二个参数是关联队列
PhantomReference<Object> phantomReference = new PhantomReference<>(o, queue);
// 执行垃圾回收
System.gc();
// 延时确保回收结束
Thread.sleep(300L);
// 当 Object o 被回收时能够从虚援用队列里获取到与之关联的虚援用 这里就是 phantomReference 这个对象
Reference<?> poll = queue.poll();
虚援用的构造方法须要两个入参,第一个就是关联的对象、第二个是虚援用队列 ReferenceQueue。虚援用须要和 ReferenceQueue 配合应用,当对象 Object o 被垃圾回收时,与 Object o 关联的虚援用就会被放入到 ReferenceQueue 中。通过从 ReferenceQueue 中是否存在虚援用来判断对象是否被回收。
咱们再来了解上面对虚援用的定义,虚援用不会影响对象的生命周期,也不会影响对象的垃圾回收。如果上述代码里的 phantomReference 是一个一般的对象,那么在执行 System.gc() 时 Object o 肯定不会被回收掉,因为一般对象持有 Object o 的强援用,还不会被作为垃圾。这里的 phantomReference 是一个虚援用的话 Object o 就会被间接回收掉。而后会将关联的虚援用放到队列里,这就是虚援用关联对象被回收时会收到零碎告诉的机制。
一些实际能力很强的读者会复制上述代码去运行,发现垃圾回收之后队列里并没有虚援用。这是因为 Object o 还在栈里,属于是 GC Root 的一种,不会被垃圾回收。咱们能够这样改写:
static ReferenceQueue<Object> queue = new ReferenceQueue<>();
public static void main(String[] args) throws InterruptedException {PhantomReference<Object> phantomReference = buildReference();
System.gc();Thread.sleep(100);
System.out.println(queue.poll());
}
public static PhantomReference<Object> buildReference() {Object o = new Object();
return new PhantomReference<>(o, queue);
}
不在 main 办法里实例化关联对象 Object o,而是利用一个 buildReference 办法来实例化,这样在执行垃圾回收的时候,Object o 曾经出栈了,不再是 GC Root,会被当做垃圾来回收。这样就能从虚援用队列里取出关联的虚援用进行后续解决。
关联对象真的被回收了吗
执行完垃圾回收之后,咱们的确能从虚援用队列里获取到虚援用了,咱们能够思考一下,与该虚援用关联的对象真的曾经被回收了吗?
应用一个小试验来摸索答案:
public static void main(String[] args) {ReferenceQueue<byte[]> queue = new ReferenceQueue<>();
PhantomReference<byte[]> phantomReference = new PhantomReference<>(new byte[1024 * 1024 * 2], queue);
System.gc();Thread.sleep(100L);
System.out.println(queue.poll());
byte[] bytes = new byte[1024 * 1024 * 4];
}
代码里生成一个虚援用,关联对象是一个大小为 2M 的数组,执行垃圾回收之后尝试再实例化一个大小为 4M 的数组。如果咱们从虚援用队列里获取到虚援用的时候关联对象曾经被回收,那么就能失常申请到 4M 的数组。(设置堆内存大小为 5M -Xmx5m -Xms5m)
执行代码输入如下:
java.lang.ref.PhantomReference@533ddba
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.ppphuang.demo.phantomReference.PhantomReferenceDemo.main(PhantomReferenceDemo.java:15)
从输入能够看到,申请 4M 内存的时候内存溢出,那么问题的答案就很显著了,关联对象并没有被真正的回收,内存也没有被开释。
再做一点小小的革新,实例化新数组的之前将虚援用间接置为 null,这样关联对象就能被真正的回收掉,也能申请足够的内存:
public static void main(String[] args) {ReferenceQueue<byte[]> queue = new ReferenceQueue<>();
PhantomReference<byte[]> phantomReference = new PhantomReference<>(new byte[1024 * 1024 * 2], queue);
System.gc();Thread.sleep(100L);
System.out.println(queue.poll());
// 虚援用间接置为 null
phantomReference = null;
byte[] bytes = new byte[1024 * 1024 * 4];
}
如果咱们应用了虚援用,然而没有及时清理虚援用的话可能会导致内存泄露 。
虚援用的应用场景——mysql-connector-java 虚援用源码剖析
读到这里置信你曾经理解了虚援用的一些根本状况,那么它的应用场景在哪里呢?
最典型的场景就是最开始写到的 mysql-connector-java 里解决 MySQL 连贯的兜底逻辑。用虚援用来包装 MySQL 连贯,如果一个连贯对象被回收的时候,会从虚援用队列里收到告诉,如果有些连贯没有被正确敞开的话,就会在回收之前进行连贯敞开的操作。
从 mysql-connector-java 的 AbandonedConnectionCleanupThread 类代码中能够发现并没有应用原生的 PhantomReference 对象,而是应用的是包装过的 ConnectionFinalizerPhantomReference,减少了一个属性 NetworkResources,这是为了不便从虚援用队列中的虚援用上获取到须要解决的资源。包装类中还有一个 finalizeResources 办法,用来敞开网络连接:
private static class ConnectionFinalizerPhantomReference extends PhantomReference<MysqlConnection> {
// 搁置须要 GC 后后置解决的网络资源
private NetworkResources networkResources;
ConnectionFinalizerPhantomReference(MysqlConnection conn, NetworkResources networkResources, ReferenceQueue<? super MysqlConnection> refQueue) {super(conn, refQueue);
this.networkResources = networkResources;
}
void finalizeResources() {if (this.networkResources != null) {
try {this.networkResources.forceClose();
} finally {this.networkResources = null;}
}
}
}
AbandonedConnectionCleanupThread 实现了 Runnable 接口,在 run 办法里循环读取虚援用队列 referenceQueue 里的虚援用,而后调用 finalizeResource 办法来进行后置的解决,防止连贯泄露:
public void run() {while(true) {
try {
...
Reference<? extends MysqlConnection> reference = referenceQueue.remove(5000L);
if (reference != null) {
// 强转为 ConnectionFinalizerPhantomReference
finalizeResource((ConnectionFinalizerPhantomReference)reference);
}
...
}
}
}
private static void finalizeResource(ConnectionFinalizerPhantomReference reference) {
try {
// 兜底解决网络资源
reference.finalizeResources();
reference.clear();} finally {
// 移除虚援用 防止可能造成的内存溢出
connectionFinalizerPhantomRefs.remove(reference);
}
}
如果你心愿在某些对象被回收的时候做一些后置工作,能够参考 mysql-connector-java 中的一些实现逻辑。
总结
本文简述了一种优雅解决 MySQL 驱动中虚援用导致 GC 耗时较长问题的解决办法、也依据本人的了解讲述了虚援用的作用、联合 MySQL 驱动的源码形容了虚援用的应用场景,心愿对你能有所帮忙。
公众号:DailyHappy
一位后端写码师,一位光明操持制造者。