亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

理解并解決JavaScript內(nèi)存泄漏

系統(tǒng) 1999 0

Web開發(fā)的發(fā)展

??? 在過去一些的時候,Web開發(fā)人員并沒有太多的去關(guān)注內(nèi)存泄露問題。那時的頁面間聯(lián)系大都比較簡單,并主要使用不同的連接地址在同一個站點(diǎn)中導(dǎo)航,這樣的 設(shè)計方式是非常有利于瀏覽器釋放資源的。即使Web頁面運(yùn)行中真的出現(xiàn)了資源泄漏,那它的影響也是非常有限而且常常是不會被人在意的。

??? 今天人們對Web應(yīng)用有了高更的要求。一個頁面很可能數(shù)小時不會發(fā)生URL跳轉(zhuǎn),并同時通過Web服務(wù)動態(tài)的更新頁面內(nèi)容。復(fù)雜的事件關(guān)聯(lián)設(shè)計、基于對象 的JScript和DHTML技術(shù)的廣泛采用,使得代碼的能力達(dá)到了其承受的極限。在這樣的情況和改變下,弄清楚內(nèi)存泄露方式變得非常的急迫,特別是過去 這些問題都被傳統(tǒng)的頁面導(dǎo)航方法給屏蔽了。

??? 還算好的事情是,當(dāng)你明確了希望尋找什么時,內(nèi)存泄露方式是比較容易被確定的。大多數(shù)你能遇到的泄露問題我們都已經(jīng)知道,你只需要少量額外的工作就會給你帶來好處。雖然在一些頁面中少量的小泄漏問題仍會發(fā)生,但是主要的問題還是很容易解決的。

泄露方式

??? 在接下來的內(nèi)容中,我們會討論內(nèi)存泄露方式,并為每種方式給出示例。其中一個重要的示例是JScript中的Closure技術(shù),另一個示例是在事件執(zhí)行 中使用Closures。當(dāng)你熟悉本示例后,你就能找出并修改你已有的大多數(shù)內(nèi)存泄漏問題,但是其它Closure相關(guān)的問題可能又會被忽視。

現(xiàn)在讓我們來看看這些個方式都有什么:

?1、循環(huán)引用(Circular References) — IE瀏覽器的COM組件產(chǎn)生的對象實例和網(wǎng)頁腳本引擎產(chǎn)生的對象實例相互引用,就會造成內(nèi)存泄漏。這也是Web頁面中我們遇到的最常見和主要的泄漏方式;

?2、內(nèi)部函數(shù)引用(Closures) — Closures可以看成是目前引起大量問題的循環(huán)應(yīng)用的一種特殊形式。由于依賴指定的關(guān)鍵字和語法結(jié)構(gòu),Closures調(diào)用是比較容易被我們發(fā)現(xiàn)的;

?3、頁面交叉泄漏(Cross-Page Leaks) — 頁面交叉泄漏其實是一種較小的泄漏,它通常在你瀏覽過程中,由于內(nèi)部對象薄計引起。下面我們會討論DOM插入順序的問題,在那個示例中你會發(fā)現(xiàn)只需要改動 少量的代碼,我們就可以避免對象薄計對對象構(gòu)建帶來的影響;

?4、貌似泄漏(Pseudo-Leaks) — 這個不是真正的意義上的泄漏,不過如果你不了解它,你可能會在你的可用內(nèi)存資源變得越來越少的時候極度郁悶。為了演示這個問題,我們將通過重寫Script元素中的內(nèi)容來引發(fā)大量內(nèi)存的"泄漏"。

循環(huán)引用

??? 循環(huán)引用基本上是所有泄漏的始作俑者。通常情況下,腳本引擎通過垃圾收集器(GC)來處理循環(huán)引用,但是某些未知因數(shù)可能會妨礙從其環(huán)境中釋放資源。對于IE來說,某些DOM對象實例的狀態(tài)是腳本無法得知的。下面是它們的基本原則:

理解并解決JavaScript內(nèi)存泄漏

Figure 1: 基本的循環(huán)引用模型

??? 本模型中引起的泄漏問題基于COM的引用計數(shù)。腳本引擎對象會維持對DOM對象的引用,并在清理和釋放DOM對象指針前等待所有引用的移除。在我們的示例 中,我們的腳本引擎對象上有兩個引用:腳本引擎作用域和DOM對象的expando屬性。當(dāng)終止腳本引擎時第一個引用會釋放,DOM對象引用由于在等待腳 本擎的釋放而并不會被釋放。你可能會認(rèn)為檢測并修復(fù)假設(shè)的這類問題會非常的容易,但事實上這樣基本的的示例只是冰山一角。你可能會在30個對象鏈的末尾發(fā) 生循環(huán)引用,這樣的問題排查起來將會是一場噩夢。

??? 如果你仍不清楚這種泄漏方式在HTML代碼里到底怎樣,你可以通過一個全局腳本變量和一個DOM對象來引發(fā)并展現(xiàn)它。

    <html>
    <head>
        <script language="JScript">
        var myGlobalObject;
        function SetupLeak()
        {
            // First set up the script scope to element reference
            myGlobalObject = document.getElementById("LeakedDiv");

            // Next set up the element to script scope reference
            document.getElementById("LeakedDiv").expandoProperty = myGlobalObject;
        }

        function BreakLeak()
        {
            document.getElementById("LeakedDiv").expandoProperty = null;
        }
        </script>
    </head>
    <body onload="SetupLeak()" onunload="BreakLeak()">
        <div id="LeakedDiv"></div>
    </body>
</html>
  

?你可以使用直接賦null值得方式來破壞該泄漏情形。在頁面文檔卸載前賦null值,將會讓腳本引擎知道對象間的引用鏈沒有了。現(xiàn)在它將能正常的清理引用并釋放DOM對象。在這個示例中,作為Web開發(fā)員的你因該更多的了解了對象間的關(guān)系。

??? 作為一個基本的情形,循環(huán)引用可能還有更多不同的復(fù)雜表現(xiàn)。對基于對象的JScript,一個通常用法是通過封裝JScript對象來擴(kuò)充DOM對象。在 構(gòu)建過程中,你常常會把DOM對象的引用放入JScript對象中,同時在DOM對象中也存放上對新近創(chuàng)建的JScript對象的引用。你的這種應(yīng)用模式 將非常便于兩個對象之間的相互訪問。這是一個非常直接的循環(huán)引用問題,但是由于使用不用的語法形式可能并不會讓你在意。要破環(huán)這種使用情景可能變得更加復(fù) 雜,當(dāng)然你同樣可以使用簡單的示例以便于清楚的討論。

    <html>
    <head>
        <script language="JScript">

        function Encapsulator(element)
        {
            // Set up our element
            this.elementReference = element;

            // Make our circular reference
            element.expandoProperty = this;
        }

        function SetupLeak()
        {
            // The leak happens all at once
            new Encapsulator(document.getElementById("LeakedDiv"));
        }

        function BreakLeak()
        {
            document.getElementById("LeakedDiv").expandoProperty = null;
        }
        </script>
    </head>
    <body onload="SetupLeak()" onunload="BreakLeak()">
        <div id="LeakedDiv"></div>
    </body>
</html>
  

?更復(fù)雜的辦法還有記錄所有需要解除引用的對象和屬性,然后在Web文檔卸載的時候統(tǒng)一清理,但大多數(shù)時候你可能會再造成額外的泄漏情形,而并沒有解決你的問題。

閉包函數(shù)(Closures)

??? 由于閉包函數(shù)會使程序員在不知不覺中創(chuàng)建出循環(huán)引用,所以它對資源泄漏常常有著不可推卸的責(zé)任。而在閉包函數(shù)自己被釋放前,我們很難判斷父函數(shù)的參數(shù)以及 它的局部變量是否能被釋放。實際上閉包函數(shù)的使用已經(jīng)很普通,以致人們頻繁的遇到這類問題時我們卻束手無策。在詳細(xì)了解了閉包背后的問題和一些特殊的閉包 泄漏示例后,我們將結(jié)合循環(huán)引用的圖示找到閉包的所在,并找出這些不受歡迎的引用來至何處。

理解并解決JavaScript內(nèi)存泄漏

Figure 2. 閉包函數(shù)引起的循環(huán)引用

??? 普通的循環(huán)引用,是兩個不可探知的對象相互引用造成的,但是閉包卻不同。代替直接造成引用,閉包函數(shù)則取而代之從其父函數(shù)作用域中引入信息。通常,函數(shù)的 局部變量和參數(shù)只能在該被調(diào)函數(shù)自身的生命周期里使用。當(dāng)存在閉包函數(shù)后,這些變量和參數(shù)的引用會和閉包函數(shù)一起存在,但由于閉包函數(shù)可以超越其父函數(shù)的 生命周期而存在,所以父函數(shù)中的局部變量和參數(shù)也仍然能被訪問。在下面的示例中,參數(shù)1將在函數(shù)調(diào)用終止時正常被釋放。當(dāng)我們加入了一個閉包函數(shù)后,一個 額外的引用產(chǎn)生,并且這個引用在閉包函數(shù)釋放前都不會被釋放。如果你碰巧將閉包函數(shù)放入了事件之中,那么你不得不手動從那個事件中將其移出。如果你把閉包 函數(shù)作為了一個expando屬性,那么你也需要通過置null將其清除。

??? 同時閉包會在每次調(diào)用中創(chuàng)建,也就是說當(dāng)你調(diào)用包含閉包的函數(shù)兩次,你將得到兩個獨(dú)立的閉包,而且每個閉包都分別擁有對參數(shù)的引用。由于這些顯而易見的因素,閉包確實非常用以帶來泄漏。下面的示例將展示使用閉包的主要泄漏因素:

    <html>
    <head>
        <script language="JScript">

        function AttachEvents(element)
        {
            // This structure causes element to ref ClickEventHandler
            element.attachEvent("onclick", ClickEventHandler);

            function ClickEventHandler()
            {
                // This closure refs element
            }
        }

        function SetupLeak()
        {
            // The leak happens all at once
            AttachEvents(document.getElementById("LeakedDiv"));
        }

        function BreakLeak()
        {
        }
        </script>
    </head>
    <body onload="SetupLeak()" onunload="BreakLeak()">
        <div id="LeakedDiv"></div>
    </body>
</html>
  

?如果你對怎么避免這類泄漏感到疑惑,我將告訴你處理它并不像處理普通循環(huán)引用那么簡單。"閉包"被看作函數(shù)作用域中的一個臨時對象。一旦函數(shù)執(zhí)行退出,你 將失去對閉包本身的引用,那么你將怎樣去調(diào)用detachEvent方法來清除引用呢?在Scott Isaacs的MSN Spaces上有一種解決這個問題的有趣方法。這個方法使用一個額外的引用(原文叫second closure,可是這個示例里致始致終只有一個closure)協(xié)助window對象執(zhí)行onUnload事件,由于這個額外的引用和閉包的引用存在于 同一個對象域中,于是我們可以借助它來釋放事件引用,從而完成引用移除。為了簡單起見我們將閉包的引用暫存在一個expando屬性中,下面的示例將向你 演示釋放事件引用和清除expando屬性。

    <html>
    <head>
        <script language="JScript">

        function AttachEvents(element)
        {
            // In order to remove this we need to put
            // it somewhere. Creates another ref
            element.expandoClick = ClickEventHandler;

            // This structure causes element to ref ClickEventHandler
            element.attachEvent("onclick", element.expandoClick);

            function ClickEventHandler()
            {
                // This closure refs element
            }
        }

        function SetupLeak()
        {
            // The leak happens all at once
            AttachEvents(document.getElementById("LeakedDiv"));
        }

        function BreakLeak()
        {
            document.getElementById("LeakedDiv").detachEvent("onclick",
                document.getElementById("LeakedDiv").expandoClick);
            document.getElementById("LeakedDiv").expandoClick = null;
        }
        </script>
    </head>
    <body onload="SetupLeak()" onunload="BreakLeak()">
        <div id="LeakedDiv"></div>
    </body>
</html>
  

?在這篇KB文章中,實際上建議我們除非迫不得已盡量不要創(chuàng)建使用閉包。文章中的示例,給我們演示了非閉包的事件引用方式,即把閉包函數(shù)放到頁面的全 局作用域中。當(dāng)閉包函數(shù)成為普通函數(shù)后,它將不再繼承其父函數(shù)的參數(shù)和局部變量,所以我們也就不用擔(dān)心基于閉包的循環(huán)引用了。在非必要的時候不使用閉包這 樣的編程方式可以盡量使我們的代碼避免這樣的問題。

??? 最后,腳本引擎開發(fā)組的Eric Lippert,給我們帶來了一篇關(guān)于閉包使用通俗易懂的好文章。他的最終建議也是希望在真正必要的時候才使用閉包函數(shù)。雖然他的文章沒有提及閉包會使用的真正場景,但是這兒已有的大量示例非常有助于大家起步。

頁面交叉泄漏(Cross-Page Leaks)

??? 這種基于插入順序而常常引起的泄漏問題,主要是由于對象創(chuàng)建過程中的臨時對象未能被及時清理和釋放造成的。它一般在動態(tài)創(chuàng)建頁面元素,并將其添加到頁面 DOM中時發(fā)生。一個最簡單的示例場景是我們動態(tài)創(chuàng)建兩個對象,并創(chuàng)建一個子元素和父元素間的臨時域(譯者注:這里的域(Scope)應(yīng)該是指管理元素之 間層次結(jié)構(gòu)關(guān)系的對象)。然后,當(dāng)你將這兩個父子結(jié)構(gòu)元素構(gòu)成的的樹添加到頁面DOM樹中時,這兩個元素將會繼承頁面DOM中的層次管理域?qū)ο螅⑿孤┲?前創(chuàng)建的那個臨時域?qū)ο蟆O旅娴膱D示示例了兩種動態(tài)創(chuàng)建并添加元素到頁面DOM中的方法。在第一種方法中,我們將每個子元素添加到它的直接父元素中,最后 再將創(chuàng)建好的整棵子樹添加到頁面DOM中。當(dāng)一些相關(guān)條件合適時,這種方法將會由于臨時對象問題引起泄漏。在第二種方法中,我們自頂向下創(chuàng)建動態(tài)元素,并 使它們被創(chuàng)建后立即加入到頁面DOM結(jié)構(gòu)中去。由于每個被加入的元素繼承了頁面DOM中的結(jié)構(gòu)域?qū)ο螅覀儾恍枰獎?chuàng)建任何的臨時域。這是避免潛在內(nèi)存泄漏 發(fā)生的好方法。

理解并解決JavaScript內(nèi)存泄漏

Figure 3. DOM插入順序泄漏模型

??? 接下來,我們將給出一個躲避了大多數(shù)泄漏檢測算法的泄漏示例。因為我們實際上沒有泄漏任何可見的元素,并且由于被泄漏的對象太小從而你可能根本不會注意這 個問題。為了使我們的示例產(chǎn)生泄漏,在動態(tài)創(chuàng)建的元素結(jié)構(gòu)中將不得不內(nèi)聯(lián)的包含一個腳本函數(shù)指針。在我們設(shè)置好這些元素間的相互隸屬關(guān)系后這將會使我們泄 漏內(nèi)部臨時腳本對象。由于這個泄漏很小,我們不得不將示例執(zhí)行成千上萬次。事實上,一個對象的泄漏只有很少的字節(jié)。在運(yùn)行示例并將瀏覽器導(dǎo)航到一個空白頁 面,你將會看到兩個版本代碼在內(nèi)存使用上的區(qū)別。當(dāng)我們使用第一種方法,將子元素加入其父元素再將構(gòu)成的子樹加入頁面DOM,我們的內(nèi)存使用量會有微小的 上升。這就是一個交叉導(dǎo)航泄漏,只有當(dāng)我們重新啟動IE進(jìn)程這些泄漏的內(nèi)存才會被釋放。如果你使用第二種方法將父元素加入頁面DOM再將子元素加入其父元 素中,同樣運(yùn)行若干次后,你的內(nèi)存使用量將不會再上升,這時你會發(fā)現(xiàn)你已經(jīng)修復(fù)了交叉導(dǎo)航泄漏的問題。

    <html>
    <head>
        <script language="JScript">

        function LeakMemory()
        {
            var hostElement = document.getElementById("hostElement");

            // Do it a lot, look at Task Manager for memory response

            for(i = 0; i < 5000; i++)
            {
                var parentDiv =
                    document.createElement("<div onClick='foo()'>");
                var childDiv =
                    document.createElement("<div onClick='foo()'>");

                // This will leak a temporary object
                parentDiv.appendChild(childDiv);
                hostElement.appendChild(parentDiv);
                hostElement.removeChild(parentDiv);
                parentDiv.removeChild(childDiv);
                parentDiv = null;
                childDiv = null;
            }
            hostElement = null;
        }


        function CleanMemory()
        {
            var hostElement = document.getElementById("hostElement");

            // Do it a lot, look at Task Manager for memory response

            for(i = 0; i < 5000; i++)
            {
                var parentDiv =
                    document.createElement("<div onClick='foo()'>");
                var childDiv =
                    document.createElement("<div onClick='foo()'>");

                // Changing the order is important, this won't leak
                hostElement.appendChild(parentDiv);
                parentDiv.appendChild(childDiv);
                hostElement.removeChild(parentDiv);
                parentDiv.removeChild(childDiv);
                parentDiv = null;
                childDiv = null;
            }
            hostElement = null;
        }
        </script>
    </head>

    <body>
        <button onclick="LeakMemory()">Memory Leaking Insert</button>
        <button onclick="CleanMemory()">Clean Insert</button>
        <div id="hostElement"></div>
    </body>
</html>
  

?這類泄漏應(yīng)該被澄清,因為這個解決方法有悖于我們在IE中的一些有益經(jīng)驗。創(chuàng)建帶有腳本對象的DOM元素,以及它們已進(jìn)行的相互關(guān)聯(lián)是了解這個泄漏 的關(guān)鍵點(diǎn)。這實際上這對于泄漏來說是至關(guān)重要的,因為如果我們創(chuàng)建的DOM元素不包含任何的腳本對象,同時使用相同的方式將它們進(jìn)行關(guān)聯(lián),我們是不會有任 何泄漏問題的。示例中給出的第二種技巧對于關(guān)聯(lián)大的子樹結(jié)構(gòu)可能更有效(由于在那個示例中我們一共只有兩個元素,所以建立一個和頁面DOM不相關(guān)的樹結(jié)構(gòu) 并不會有什么效率問題)。第二個技巧是在創(chuàng)建元素的開始不關(guān)聯(lián)任何的腳本對象,所以你可以安全的創(chuàng)建子樹。當(dāng)你把你的子樹關(guān)聯(lián)到頁面DOM上后,再繼續(xù)處 理你需要的腳本事件。牢記并遵守關(guān)于循環(huán)引用和閉包函數(shù)的使用規(guī)則,你不會再在掛接事件時在你的代碼中遇到不同的泄漏。

??? 我真的要指出這個問題,因為我們可以看出不是所有的內(nèi)存泄漏都是可以很容易發(fā)現(xiàn)的。它們可能都是些微不足道的問題,但往往需要成千上萬次的執(zhí)行一個更小的 泄漏場景才能使問題顯現(xiàn)出來,就像DOM元素插入順序引起的問題那樣。如果你覺得使用所謂的"最佳"經(jīng)驗來編程,那么你就可以高枕無憂,但是這個示例讓我 們看到,即使是"最佳"經(jīng)驗似乎也可能帶來泄漏。我們這里的解決方案希望能提高這些已有的好經(jīng)驗,或者介紹一些新經(jīng)驗使我們避免泄漏發(fā)生的可能。

貌似泄漏(Pseudo-Leaks)

??? 在大多數(shù)時候,一些APIs的實際的行為和它們預(yù)期的行為可能會導(dǎo)致你錯誤的判斷內(nèi)存泄漏。貌似泄漏大多數(shù)時候總是出現(xiàn)在同一個頁面的動態(tài)腳本操作中,而 在從一個頁面跳轉(zhuǎn)到空白頁面的時候發(fā)生是非常少見的。那你怎么能象排除頁面間泄漏那樣來排除這個問題,并且在新任務(wù)運(yùn)行中的內(nèi)存使用量是否是你所期望的。 我們將使用腳本文本的重寫來作為一個貌似泄漏的示例。

??? 象DOM插入順序問題那樣,這個問題也需要依賴創(chuàng)建臨時對象來產(chǎn)生"泄漏"。對一個腳本元素對象內(nèi)部的腳本文本一而再再而三的反復(fù)重寫,慢慢地你將開始泄 漏各種已關(guān)聯(lián)到被覆蓋內(nèi)容中的腳本引擎對象。特別地,和腳本調(diào)試有關(guān)的對象被作為完全的代碼對象形式保留了下來。

    <html>
    <head>
        <script language="JScript">
        function LeakMemory()
        {
            // Do it a lot, look at Task Manager for memory response
            for(i = 0; i < 5000; i++)
            {
                hostElement.text = "function foo() { }";
            }
        }
        </script>
    </head>
    <body>
        <button onclick="LeakMemory()">Memory Leaking Insert</button>
        <script id="hostElement">function foo() { }</script>
    </body>
</html>
  

?如果你運(yùn)行上面的示例代碼并使用任務(wù)管理器查看,當(dāng)從"泄漏"頁面跳轉(zhuǎn)到空白頁面時,你并不會注意到任何腳本泄漏。因為這種腳本泄漏完全發(fā)生在頁面 內(nèi)部,而且當(dāng)你離開該頁面時被使用的內(nèi)存就會回收。對于我們原本所期望的行為來說這樣的情況是糟糕的。你希望當(dāng)重寫了腳本內(nèi)容后,原來的腳本對象就應(yīng)該徹 底的從頁面中消失。但事實上,由于被覆蓋的腳本對象可能已用作事件處理函數(shù),并且還可能有一些未被清除的引用計數(shù)。正如你所看到的,這就是貌似泄漏。在表 面上內(nèi)存消耗量可能看起來非常的糟糕,但是這個原因是完全可以接受的。

?

總結(jié)

??? 每一位Web開發(fā)員可能都整理有一份自己的代碼示例列表,當(dāng)他們在代碼中看到如列表中的代碼時,他們會意識到泄漏的存在并會使用一些開發(fā)技巧來避免這些問 題。這樣的方法雖然簡單便捷,但這也是今天Web頁面內(nèi)存泄漏普遍存在的原因。考慮我們所討論的泄漏情景而不是關(guān)注獨(dú)立的代碼示例,你將會使用更加有效的 策略來解決泄漏問題。這樣的觀念將使你在設(shè)計階段就把問題估計到,并且確保你有計劃來處理潛在的泄漏問題。使用編寫加固代碼(譯者注:就是異常處理或清理 對象等的代碼)的習(xí)慣并且采取清理所有自己占用內(nèi)存的方法。雖然對這個問題來說可能太夸張了,你也可能幾乎從沒有見到編寫腳本卻需要自己清理自己占用的內(nèi) 存的情況;使這個問題變得越來越顯著的是,腳本變量和expando屬性間存在的潛在泄漏可能。

??? 如果對模式和設(shè)計感興趣,我強(qiáng)烈推薦Scott的這篇blog,因為其中演示了一個通用的移除基于閉包泄漏的示例代碼。當(dāng)然這需要我們使用更多的代碼,但 是這個實踐是有效的,并且改進(jìn)的場景非常容易在代碼中定位并進(jìn)行調(diào)試。類似的注入設(shè)計也可以用在基于expando屬性引起的循環(huán)引用中,不過需要注意所 注冊的方法自身不要讓泄漏(特別使用閉包的地方)跑掉。

?

?

[ 轉(zhuǎn)自 : http://blog.csdn.net/popeyes_hsz/archive/2009/03/17/3997220.aspx ]

理解并解決JavaScript內(nèi)存泄漏


更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯(lián)系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點(diǎn)擊下面給點(diǎn)支持吧,站長非常感激您!手機(jī)微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點(diǎn)擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發(fā)表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 狠狠操天天射 | 最新日韩中文字幕 | 国产日韩欧美一区二区三区综合 | 欧美毛片免费 | 99视频免费看 | 99国产精品免费视频 | 久久久久免费精品国产 | 国产一区中文字幕 | 久久久久久久久久综合情日本 | 永久看日本大片免费 | 久久99爰这里有精品国产 | 欧美日韩一区二区三区自拍 | 亚洲欧洲精品在线 | 亚洲欧美韩日 | 91拍拍在线观看 | 国产精品久久久久久久久99热 | 久操视频在线免费观看 | 美女一级大黄录像一片 | 日日日操操操 | 色综合色综合色综合色综合网 | 99精品视频在线免费观看 | 91久久精品国产91性色tv | 国产福利一区二区三区在线视频 | 中文字幕免费视频精品一 | 2020亚洲欧美日韩在线观看 | 高清欧美日本视频免费观看 | 欧美色视频网 | 亚洲精品一二三区 | 久草色播| 色综合网站在线 | 欧美特黄一级aa毛片 | 国产精品福利视频主播真会玩 | 经典邵氏三级 在线观看 | 亚洲美女网址 | 国产一区二区三区久久 | 中文字幕一区二区三区视频在线 | 亚洲国产精品成人午夜在线观看 | 成人一级黄色片 | jazzjazz国产精品久久 | 国内精品久久久久久久999下 | 日韩天堂在线观看 |