面試某公司的時候，面試官問到，導(dǎo)致瀏覽器崩潰的原因有哪些？愚輩不才，僅回答出了內(nèi)存泄漏。其實在網(wǎng)頁在裝載的過程中，常常由于種種原因使瀏覽器的反映變的很慢，或造成瀏覽器失去響應(yīng)，甚至?xí)?dǎo)致機器無法進(jìn)行其他的操作。

　　對于訪客，如果登錄您網(wǎng)站，瀏覽器就立刻崩潰，我想這對誰都是無法容忍的，對此總結(jié)了網(wǎng)站導(dǎo)致瀏覽器崩潰的原因：

　　1. 內(nèi)存泄漏

　　還是先談下內(nèi)存泄漏，網(wǎng)站由于內(nèi)存泄漏的而照成崩潰有兩種情況，服務(wù)器的崩潰和瀏覽器的崩潰。內(nèi)存泄漏所造成的問題是顯而易見的，它使得已分配的內(nèi)存的引用就會丟失，只要系統(tǒng)還在運行中，則進(jìn)程就會一直使用該內(nèi)存。這樣的結(jié)果是，曾占用更多的內(nèi)存的程序會降低系統(tǒng)性能，直到機器完全停止工作，才會完全清空內(nèi)存。

　　Apache的Web服務(wù)器是用C/C++編寫的，C/C++的內(nèi)存泄漏問題不必多說，系統(tǒng)中存在無法回收的內(nèi)存，有時候會造成內(nèi)存不足或系統(tǒng)崩潰。在Java中，內(nèi)存泄漏就是存在一些被分配的可達(dá)而無用的對象，這些對象不會被GC所回收，然而它卻占用內(nèi)存。

　　而在客戶端，JavaScript所造成的內(nèi)存泄漏，也將可能使得瀏覽器崩潰。關(guān)于JavaScript的內(nèi)存泄漏的文章，較權(quán)威的有《Memory leak patterns in JavaScript》和《Understanding and Solving InterNET Explorer Leak Patterns》。

　　JavaScript 是一種垃圾收集式（garbage collector，GC）語言，這就是說，內(nèi)存是根據(jù)對象的創(chuàng)建分配給該對象的，并會在沒有對該對象的引用時由瀏覽器收回。再根據(jù)《Fabulous Adventures In Coding》一文的說法：“JScript uses a nongenerational mark-and-sweep garbage collector.”，對” nongenerational mark-and-sweep”的可以這樣理解，瀏覽器處理JavaScript并非采用純粹的垃圾收集，還使用引用計數(shù)來為Native對象(例如Dom、ActiveX Object)處理內(nèi)存。

　　在引用計數(shù)系統(tǒng)，每個所引用的對象都會保留一個計數(shù)，以獲悉有多少對象正在引用它。如果計數(shù)為零，該對象就會被銷毀，其占用的內(nèi)存也會返回給堆。 當(dāng)對象相互引用時，就構(gòu)成循環(huán)引用，瀏覽器（IE6，F(xiàn)irefox2.0）對于純粹的JavaScript對象間的循環(huán)引用是可以正確處理的，但由于在引用計數(shù)系統(tǒng)，相互引用的對象都不能被銷毀，因為是引用計數(shù)永遠(yuǎn)不能為零，因此瀏覽器無法處理JavaScript與Native對象(例如Dom、ActiveX Object)之間循環(huán)引用。所以，當(dāng)我們出現(xiàn)Native對象與JavaScript對象間的循環(huán)引用時，就會出現(xiàn)內(nèi)存泄漏的問題。

　　簡單來說就是，瀏覽器使用引用計數(shù)來為Native對象處理內(nèi)存，而引用計數(shù)的對象無法被銷毀，涉及Native對象的循環(huán)引用將會出現(xiàn)內(nèi)存泄漏。配合下面的例子，理解這句話，基本上就可以理解JavaScript造成的內(nèi)存泄漏了。

var obj;
window.onload = function(){
    // JavaScript對象obj到DOM對象的引用，根據(jù)id獲得
    obj=document.getElementById("DivElement");
　　// DOM 對象則有到此 JavaScript 對象的引用，由expandoProperty實現(xiàn)
　　document.getElementById("DivElement").expandoProperty=obj;
};        

        

        
        
      
        
it知識庫：【總結(jié)】網(wǎng)站令瀏覽器崩潰的原因，轉(zhuǎn)載需保留來源！
        
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。