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

四、代理池優化方案

待定，后續補充