快捷導(dǎo)航

網(wǎng)站導(dǎo)致瀏覽器崩潰的原因總結(jié)(多款瀏覽器) 推薦

更新時(shí)間：2010年04月15日 22:37:43 作者：

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

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

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

1. 內(nèi)存泄漏

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

　　Apache的Web服務(wù)器是用C/C++編寫(xiě)的，C/C++的內(nèi)存泄漏問(wèn)題不必多說(shuō)，系統(tǒng)中存在無(wú)法回收的內(nèi)存，有時(shí)候會(huì)造成內(nèi)存不足或系統(tǒng)崩潰。在Java中，內(nèi)存泄漏就是存在一些被分配的可達(dá)而無(wú)用的對(duì)象，這些對(duì)象不會(huì)被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）語(yǔ)言，這就是說(shuō)，內(nèi)存是根據(jù)對(duì)象的創(chuàng)建分配給該對(duì)象的，并會(huì)在沒(méi)有對(duì)該對(duì)象的引用時(shí)由瀏覽器收回。再根據(jù)《Fabulous Adventures In Coding》一文的說(shuō)法：“JScript uses a nongenerational mark-and-sweep garbage collector.”，對(duì)” nongenerational mark-and-sweep”的可以這樣理解，瀏覽器處理JavaScript并非采用純粹的垃圾收集，還使用引用計(jì)數(shù)來(lái)為Native對(duì)象(例如Dom、ActiveX Object)處理內(nèi)存。

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

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

復(fù)制代碼代碼如下:

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

可見(jiàn)，JavaScript 對(duì)象和 DOM 對(duì)象間就產(chǎn)生了一個(gè)循環(huán)引用。由于 DOM 對(duì)象是通過(guò)引用計(jì)數(shù)管理的，所以?xún)蓚€(gè)對(duì)象將都不能銷(xiāo)毀。

　　另一種情況是閉包中，當(dāng)碰到閉包，我們?cè)贜ative對(duì)象上綁定事件響應(yīng)代碼時(shí)，很容易制造出Closure Memory Leak。其關(guān)鍵原因和前者是一樣的，也是一個(gè)跨JavaScript對(duì)象和Native對(duì)象的循環(huán)引用。只是代碼更為隱蔽。

復(fù)制代碼代碼如下:

window.onload = function AttachEvents(element){ 
　　//element有個(gè)引用指向函數(shù)ClickEventHandler() 
　　element.attachEvent( " onclick " , ClickEventHandler); 
function ClickEventHandler(){ 
//該函數(shù)有個(gè)引用指向AttachEvents(element)調(diào)用Scope， 
　　 //也就是執(zhí)行了參數(shù)element。 
　　} 
} 

這里簡(jiǎn)單理解了JavaScript造成內(nèi)存泄漏的原因，內(nèi)存泄漏加大瀏覽器的負(fù)擔(dān)，很有可能導(dǎo)致瀏覽器崩潰，我們要做的就是盡量去避免這種情況，做法可參考剛剛所說(shuō)《Memory leak patterns in JavaScript》和《Understanding and Solving Internet Explorer Leak Patterns》兩篇文章加以理解。處理JavaScript內(nèi)存泄漏最終目的還是要打破JavaScript對(duì)象和Native對(duì)象間的循環(huán)引用或者清零引用計(jì)數(shù)，釋放對(duì)象。

　　一些內(nèi)存泄漏如閉包內(nèi)存泄漏，我們可能比較難以發(fā)現(xiàn)，內(nèi)存泄漏的檢測(cè)我們可能參考《javascript 內(nèi)存泄露工具使用》。

2. 網(wǎng)頁(yè)代碼復(fù)雜和瀏覽器bug

　　大量個(gè)人網(wǎng)站和低質(zhì)量網(wǎng)站代碼的涌現(xiàn)造成對(duì)瀏覽標(biāo)準(zhǔn)的普遍不支持，如果正好碰上瀏覽器存在的一些bug，瀏覽器渲染引擎在處理這些網(wǎng)頁(yè)代碼的時(shí)候會(huì)出錯(cuò)，比如陷入死循環(huán)或直接崩潰等。

HTML代碼導(dǎo)致網(wǎng)站崩潰

　　這是HTML結(jié)構(gòu)錯(cuò)誤而導(dǎo)致IE6的崩潰，在<col width="100"/>前或后添加任何字符均會(huì)導(dǎo)致IE6 Crash。

復(fù)制代碼代碼如下:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd"> 
<html> 
<head></head> 
<body> 
　<table> 
<tr> 
<td> 
<table style="width:100%;table-layout:fixed;"> 
<colgroup><col width="100px"><col></colgroup> 
</table> 
</td> 
</tr> 
<table> 
</body> 
</html> 

該代碼來(lái)個(gè)韓國(guó)的一個(gè)網(wǎng)站，無(wú)論是使用XHTML或者HTML的什么版本，只要帶了DOCTYPE聲明，IE6就會(huì)立即崩潰，當(dāng)不帶DOCTYPE聲明的時(shí)候就沒(méi)有錯(cuò)誤，原因可能跟文檔類(lèi)型聲明有關(guān)。

令I(lǐng)E6崩潰的CSS代碼

　　該代碼參考自網(wǎng)站Cats who Code。該Bug發(fā)現(xiàn)與2007年，據(jù)說(shuō)是一名日本人發(fā)現(xiàn)的：

復(fù)制代碼代碼如下:

<style>*{position:relative}</style> 
<table><input></table>

原因在于table中直接放置內(nèi)容，在IE6會(huì)引起mshtml.dll模塊損壞而關(guān)閉瀏覽器，非IE6則安全無(wú)恙。

　　除此之外，存在于IE6的Bug還有下面這種情況，當(dāng)偽類(lèi)為 a:active 時(shí)同樣會(huì)遇到此問(wèn)題：

復(fù)制代碼代碼如下:

 
<style type="text/css"> 
a{position:relative;} 
a:hover{float:left;} 
</style> 
<a href="">崩潰IE6 ，crash ie6</a> 

　　解決方案：為 <a> 添加 zoom:1; 令其觸發(fā)haslayout。

復(fù)制代碼代碼如下:

 
<style type="text/css"> 
a{position:relative;zoom:1;} 
a:hover{float:left;} 
</style> 

令I(lǐng)E7崩潰的CSS代碼

　　此Bug來(lái)自偷米飯，它只存在IE7中據(jù)估計(jì)是處理省略字的時(shí)候?qū)е翴E7崩潰。

復(fù)制代碼代碼如下:

 
<style type="text/css"> 
div{float:left;width:175px;} 
ul{overflow:hidden;white-space:nowrap;text-overflow:ellipsis;} 
li{position:relative;} 
</style> 
<div> 
<ul> 
<li>崩潰崩潰崩潰崩潰崩潰crash ie7</li> 
<li>崩潰崩潰崩潰崩潰崩潰crash ie7</li> 
</ul> 
</div> 

　　解決方案：為 <li> 添加 zoom:1; 令其觸發(fā)haslayout

令I(lǐng)E6崩潰的JavaScript代碼

　　來(lái)自Internet Explorer Sucks，這個(gè)網(wǎng)站就是使用了一下代碼，當(dāng)你使用IE6訪問(wèn)的時(shí)候，瀏覽器將立刻崩潰。代碼如下：

復(fù)制代碼代碼如下:

具體引起的原因暫時(shí)無(wú)法解析，但在兼容性和執(zhí)行效率來(lái)看一般不會(huì)采取這樣的寫(xiě)法。

3. 網(wǎng)頁(yè)數(shù)據(jù)過(guò)多

　　網(wǎng)頁(yè)含有大量需要處理的數(shù)據(jù)，造成系統(tǒng)繁忙，如多圖頁(yè)面，超長(zhǎng)頁(yè)面等，或者網(wǎng)頁(yè)內(nèi)嵌的各種控件會(huì)導(dǎo)致瀏覽器處理大量數(shù)據(jù)，造成系統(tǒng)繁忙。如Flash游戲，ActiveX控件等。當(dāng)瀏覽器訪問(wèn)網(wǎng)站的時(shí)候，如果網(wǎng)站的數(shù)據(jù)量大，會(huì)使得瀏覽器一般在處理過(guò)程中會(huì)占用很大的CPU使用率和內(nèi)存、造成瀏覽器失去響應(yīng)，甚至?xí)闺娔X系統(tǒng)死機(jī)。在網(wǎng)站開(kāi)發(fā)的時(shí)候，如果充分考慮Web性能，很大程度上能避免這個(gè)問(wèn)題。

4. Ajax的Web服務(wù)漏洞

　　Ajax的是基于XML的異步傳輸，文本格式的XML消息可能是二進(jìn)制數(shù)據(jù)帶寬量的兩倍之多。傳輸XML消息所需的帶寬越多，系統(tǒng)或應(yīng)用程序用來(lái)執(zhí)行其他任務(wù)的可用資源就越少。例如執(zhí)行復(fù)雜算法來(lái)獲取期望結(jié)果。

　　過(guò)高的帶寬可能導(dǎo)致由系統(tǒng)超載引起的性能減退。過(guò)高的帶寬將導(dǎo)致Ajax應(yīng)用程序輸出破損的數(shù)據(jù)，因?yàn)闆](méi)有足夠的資源生成干凈的數(shù)據(jù)。這意味著Web服務(wù)門(mén)戶(Ajax應(yīng)用程序?qū)儆谄渲械囊徊糠?將把破損數(shù)據(jù)暴露給門(mén)戶的其他部分，從而導(dǎo)致畸形消息和過(guò)度解析。如果威脅者利用了這個(gè)漏洞，則會(huì)引起瀏覽器崩潰。

　　另外一方面，頻繁的、較小的 HTTP 請(qǐng)求會(huì)加重后端服務(wù)器、負(fù)載均衡程序和防火墻的負(fù)擔(dān)，結(jié)果是造成過(guò)高的帶寬，最終導(dǎo)致性能降低。如果客戶端長(zhǎng)期停留在該頁(yè)面或沒(méi)有關(guān)閉瀏覽器，會(huì)使得瀏覽器的內(nèi)存持續(xù)上漲，得不到釋放，導(dǎo)致客戶端瀏覽器崩潰。

　　為此，在較多的時(shí)候Ajax的時(shí)候，我們要考慮通過(guò)專(zhuān)門(mén)的硬件加速器、優(yōu)化軟件、消除代碼冗余、XML加速功能和解決互操作性問(wèn)題等方式加速Ajax應(yīng)用程序。另外，積極地監(jiān)視通信流可以持續(xù)地度量Ajax應(yīng)用程序的網(wǎng)絡(luò)流量性能。通過(guò)將數(shù)據(jù)放入實(shí)時(shí)日志中，您可以查看在哪些位置何時(shí)出現(xiàn)大量的包丟失和抖動(dòng)事件，響應(yīng)變慢的原因以及如何通過(guò)修改應(yīng)用程序的優(yōu)先級(jí)來(lái)改善通信流性能。

5. 其他原因

　　除以上提到的原因之外，還有其他許多原因，雖然有些不會(huì)導(dǎo)致瀏覽器直接崩潰，但也會(huì)造成網(wǎng)站無(wú)法訪問(wèn)，如日志文件導(dǎo)致磁盤(pán)已滿、Web服務(wù)器C指針錯(cuò)誤、進(jìn)程缺乏文件描述符、線程死鎖、數(shù)據(jù)庫(kù)中的臨時(shí)表不夠用和服務(wù)器超載等，可參考《導(dǎo)致Web站點(diǎn)崩潰最常見(jiàn)的七大原因》。

總結(jié)

　　對(duì)于訪客，如果登錄您網(wǎng)站，瀏覽器就立刻崩潰，我想這對(duì)誰(shuí)都是無(wú)法容忍的，通過(guò)總結(jié)《網(wǎng)站令瀏覽器崩潰的原因》，在我們從事網(wǎng)站開(kāi)發(fā)維護(hù)的時(shí)候，我們應(yīng)該盡量去避免內(nèi)存泄漏、代碼錯(cuò)誤和冗余及數(shù)據(jù)量過(guò)大等問(wèn)題，構(gòu)建更佳性能的站點(diǎn)。

PS：本文由維奇總結(jié)，如有轉(zhuǎn)載請(qǐng)注明出處