一、finalize方法是對(duì)象回收前的唯一自我救贖機(jī)會(huì)

JVM進(jìn)行GC時(shí)，首先使用可達(dá)性分析算法，找出不在GC Roots引用鏈上的對(duì)象，這時(shí)進(jìn)行一次標(biāo)記（標(biāo)記出需要回收的對(duì)象）并篩選（對(duì)需要回收對(duì)象進(jìn)行篩選），篩選條件就是是否有必要執(zhí)行finalize方法。當(dāng)對(duì)象沒(méi)有覆蓋或已執(zhí)行過(guò)finalize方法，則沒(méi)有必要執(zhí)行；否則，將對(duì)象放到由JVM創(chuàng)建的Finalizer線程維護(hù)的F-Queue（java.lang.ref.Finalizer.ReferenceQueue）隊(duì)列中，F(xiàn)inalizer線程會(huì)遍歷執(zhí)行隊(duì)列中對(duì)象的finalize方法，只有當(dāng)F-Queue中對(duì)象finalize執(zhí)行完成后，并且下次GC時(shí)可達(dá)性分析不再GC Roots的引用鏈上，則這些對(duì)象占用的內(nèi)存才能被真正回收。重寫finalize方法可以方便我們?nèi)ブ匦陆?duì)象的引用關(guān)系，避免被回收。

二、多線程環(huán)境重寫對(duì)象的finalize方法

由于Finalizer線程優(yōu)先級(jí)相較于普通線程優(yōu)先級(jí)要低，而根據(jù)Java的搶占式線程調(diào)度策略，優(yōu)先級(jí)越低的線程，分配CPU的機(jī)會(huì)越少，因此當(dāng)多線程創(chuàng)建重寫finalize方法的對(duì)象時(shí)，F(xiàn)inalizer可能無(wú)法及時(shí)執(zhí)行finalize方法，F(xiàn)inalizer線程處理對(duì)象的速度小于創(chuàng)建對(duì)象的速度時(shí)，會(huì)造成F-Queue越來(lái)越大，JVM內(nèi)存無(wú)法及時(shí)釋放，造成頻繁的Young GC，然后是Full GC，乃至最終的OutOfMemoryError。

三、代理池項(xiàng)目Finalizer線程踩坑記錄

我的個(gè)人爬蟲(chóng)代理池項(xiàng)目中使用多線程+Socket進(jìn)行代理的有效性檢測(cè)，代碼如下：

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;
    }

代理池跑了一段時(shí)間，發(fā)現(xiàn)可用代理越來(lái)越少，看了下GC情況，發(fā)現(xiàn)JVM進(jìn)行了上千次的Full GC，而且堆內(nèi)存基本上占滿了，于是就導(dǎo)出了Javacore和dump分析，在dump里發(fā)現(xiàn)Finalizer線程持有的java.lang.ref.Finalizer.ReferenceQueue里全是java.net.SocksSocketImpl的對(duì)象，所以就把目光投在了上面這一段代碼，跟蹤Socket的源代碼，發(fā)現(xiàn)在創(chuàng)建Socket實(shí)例的時(shí)候，會(huì)調(diào)用這個(gè)方法

    /**
     * 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);
    }

這里創(chuàng)建了SocksSocketImpl對(duì)象，是系統(tǒng)默認(rèn)的SocketImpl實(shí)現(xiàn)類，而SocksSocketImpl的父類java.net.PlainSocketImpl.PlainSocketImpl的父類java.net.AbstractPlainSocketImpl重寫了finalize方法，在方法里調(diào)用close方法：

    /**
     * Cleans up if the user forgets to close it.
     */
    protected void finalize() throws IOException {
        close();
    }

所以，到這里，問(wèn)題就可以定位了，多線程環(huán)境下，代理檢測(cè)代碼執(zhí)行完成后，Socket對(duì)象被回收，但是，因?yàn)镴VM在回收對(duì)象之前，需要對(duì)象的父類的終止邏輯也要被執(zhí)行，因此，在回收SocksSocketImpl對(duì)象時(shí)需要先執(zhí)行AbstractPlainSocketImpl的finalize方法，我們上面也說(shuō)了，F(xiàn)inalizer線程執(zhí)行優(yōu)先級(jí)低于普通線程，而代理池工程有140個(gè)有效性檢測(cè)線程，對(duì)象銷毀速度趕不上對(duì)象的創(chuàng)建速度，因此，F(xiàn)-Queue越來(lái)越大，JVM瘋狂GC，系統(tǒng)越來(lái)越不可用。

四、代理池優(yōu)化方案

待定，后續(xù)補(bǔ)充