一、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，系统越来越不可用。

四、代理池优化方案

待定，后续补充