JVM Finalizer线程踩坑记录
一、finalize方法是对象回收前的唯一自我救赎机会
JVM进行GC时，首先使用可达性分析算法，找出不在GC Roots引用链上的对象，这时进行一次标记（标记出需要回收的对象）并筛选（对需要回收对象进行筛选），筛选条件就是是否有必要执行finalize方法。当对象没有覆盖或已执行过finalize方法，则没有必要执行；否则，将对象放到由JVM创建的Finalizer线程维护的F-Queue（java.lang.ref.Finalizer.ReferenceQueue）队列中，Finalizer线程会遍历执行队列中对象的finalize方法，只有当F-Queue中对象finalize执行完成后，并且下次GC时可达性分析不再GC Roots的引用链上，则这些对象占用的内存才能被真正回收。重写finalize方法可以方便我们去重新建立对象的引用关系，避免被回收。
二、多线程环境重写对象的finalize方法
由于Finalizer线程优先级相较于普通线程优先级要低，而根据Java的抢占式线程调度策略，优先级越低的线程，分配CPU的机会越少，因此当多线程创建重写finalize方法的对象时，Finalizer可能无法及时执行finalize方法，Finalizer线程处理对象的速度小于创建对象的速度时，会造成F-Queue越来越大，JVM内存无法及时释放，造成频繁的Young GC，然后是Full GC，乃至最终的OutOfMemoryError。
三、代理池项目Finalizer线程踩坑记录
我的个人爬虫代理池项目中使用多线程+Socket进行代理的有效性检测，代码如下：
protected static boolean proxyAvailable(Proxy proxy) {
Socket socket = null;
if (proxy != null) {
try {
if (ProxyUtil.isBasedHttp(proxy)) {
socket = new Socket();
} else {
socket = (SSLSocket) ((SSLSocketFactory)SSLSocketFactory.getDefault()).createSocket();
}
socket.connect(new InetSocketAddress(proxy.getHost(), proxy.getPort()), 3000);
return true;
} catch (IOException e) {
// do nothing.
} finally {
try {
socket.close();
} catch (IOException e) {
}
}
}
return false;
}
代理池跑了一段时间，发现可用代理越来越少，看了下GC情况，发现JVM进行了上千次的Full GC，而且堆内存基本上占满了，于是就导出了Javacore和dump分析，在dump里发现Finalizer线程持有的java.lang.ref.Finalizer.ReferenceQueue里全是java.net.SocksSocketImpl的对象，所以就把目光投在了上面这一段代码，跟踪Socket的源代码，发现在创建Socket实例的时候，会调用这个方法
/**
* Sets impl to the system-default type of SocketImpl.
* @since 1.4
*/
void setImpl() {
if (factory != null) {
impl = factory.createSocketImpl();
checkOldImpl();
} else {
// No need to do a checkOldImpl() here, we know it's an up to date
// SocketImpl!
impl = new SocksSocketImpl();
}
if (impl != null)
impl.setSocket(this);
}
这里创建了SocksSocketImpl对象，是系统默认的SocketImpl实现类，而SocksSocketImpl的父类java.net.PlainSocketImpl.PlainSocketImpl的父类java.net.AbstractPlainSocketImpl重写了finalize方法，在方法里调用close方法：
/**
* Cleans up if the user forgets to close it.
*/
protected void finalize() throws IOException {
close();
}
所以，到这里，问题就可以定位了，多线程环境下，代理检测代码执行完成后，Socket对象被回收，但是，因为JVM在回收对象之前，需要对象的父类的终止逻辑也要被执行，因此，在回收SocksSocketImpl对象时需要先执行AbstractPlainSocketImpl的finalize方法，我们上面也说了，Finalizer线程执行优先级低于普通线程，而代理池工程有140个有效性检测线程，对象销毁速度赶不上对象的创建速度，因此，F-Queue越来越大，JVM疯狂GC，系统越来越不可用。
四、代理池优化方案
待定，后续补充
