通常，隨着頁面js/jquery代碼的增多，我們會發現頁面打開速度不盡人意。這個時候通常會想到性能調優。除了算法，及時釋放變量外，同時也要注意垃圾回收。
因爲有時候你會發現，某個按鈕綁定的js變量(object)裏面的事件(event)失效了。或者發現頁面打開很慢。
這次重點強調垃圾回收，多數材料是引入的：
key point:
1.javascript具有自動垃圾收集機制，也就是說，執行環境會負責管理代碼執行過程中的使用的內存。
在編寫javascript程序時候，開發人員不用再關心內存使用的問題，所 需內存的分配以及無用的回收完全實現了自動管理。這種垃圾收集機制的原理其實很簡單：找出那些不再繼續使用的變量，然後釋放其中佔用的內存。爲此，垃圾收集器會按照固定的時間間隔（或代碼執行中預設的收集時間），週期性的執行這一操作。
好的一面：我們不用擔憂內存釋放問題。
壞的一面：用戶抱怨某些按鈕事件的丟失：例子
========================================================
<input type='button' onclick='myObj.act()'/>
其中, myObj是一個js封裝類，在頁面onload的時候初始化，初始裏面有段代碼：
js類對象myObj所在的初始化函數裏面有代碼： if(myObj.afterAct!=undefined) my.afterAct();
頁面引用的裏面有代碼：
var afterAct= function(){//這裏會有一些動作，在調用 myObj.act()後面執行..};
var myObj=new myObj(params,...., {afterAct});
理論上，當用戶點擊button的時候，會執行 act函數，然後執行 afterAct函數。實際大多時候也確實是這樣。然後，偶爾的情況下，用戶會抱怨afterAct失效了！當然他/她不會告訴你他/她打開那個頁面後，去喝了杯咖啡，然後開了個會議，回來再點擊那個button。
這就是聰明的垃圾回收器做了一件“聰明”的事情，這個情況我們會想要避免。代碼可以自己擴展，看完下面的論述後。
=======================================================
然而，上面只是一個貌似“反面”的例子，說回收機制的不足，相對編程人員而言。下面再列舉一個正面的例子，有木有發現win7的ie8特別佔內存，特別是開flash遊戲的時間比較長的時候。
以上，拋磚引玉。
2.垃圾收集器都是週期性運行的，某些極端的情況下，我們可以干擾這個週期。
垃圾收集器都是週期性運行的，而且如果爲變量分配的內存數量很客觀，那麼回收工作量也是相當大的。在這種情況下，確定垃圾收集的時間間隔是一個非常重要的問題。說到垃圾收集器多長時間運行一次，不禁讓人聯想到IE因此聲名狼藉的性能問題。IE的垃圾收集器是根據內存分配量運行的，具體一點說就是256個變量、4096個對象（或數組）字面量和數組元素（slot）或者64KB的字符串。達到上述任何一個臨界值，垃圾收集器就會運行。這種實現的問題在於，如果一個腳本中包含那麼多 變量，那麼該腳本很可能會在其生命中起一支保持那麼多的變量。而這樣一來，垃圾收集器就可能不得不頻繁的運行。結果，由此引發的嚴重性能問題初始IE7重寫了其垃圾收集例程。
隨着IE7的發佈，其javascript引擎的垃圾收集例程改變了工作方式：觸發垃圾收集的變量分配、字面量和（或）數組元素的臨界值被調整爲動態修正。IE7中的各項臨界值在初始化時與IE6相等。如果例程回收的內存分配量低於15%，則變量 、字面量和（或）數組元素的臨界值就會加倍。如果例程回收了85%的內存分配量，則將各種臨界重置會默認值。這一看似簡單的調整，極大地提升了IE在運行包含大量javascript的頁面時的性能。
事實上，在有的瀏覽器中可以觸發垃圾收集過程，當我們不建議讀者這樣做。在IE中，調用window.CollectGarbage()方法會立即指向垃圾收集，在Opera7及更高版本中，調用widnow.opera.collect()也會啓動垃圾收集例程。
3.確保佔用最少內存可以讓頁面獲得更好的性能，最好通過將其值設置爲null來釋放其引用
使具備垃圾收集機制的語言編寫程序，開發人員一般不必操心內存管理的問題。但是，javascript在進行內出你管理及垃圾收集時面臨的問題還是有點與衆不同。其中最重要的一個問題，就是分配給web瀏覽器的可使用內存數量通常要比分配給桌面應用程序的少。這樣做的目的出要是處於安全方面的考慮，目的是防止運行javascript的網頁耗盡全部系統內存而導致系統崩潰。內存限制問題不僅會影響給變量分配內存，同時還會影響調用棧以及在一個線程中能夠同時執行語句數量。
function createPerson (name) {
var localPerson = new Object();
localPerson.name = name;
return localPerson;
};
var gllbalPerson = createPerson("Nicholas");
// 手工解除globalPerson的引用
globalPerson = null;
在這個例子中，變量globalPerson取得了createPerson()函數返回的值。在createPerson()函數內部，我們創建了一個對象並將其賦給了局部變量localPerson，然後又爲該對象添加了一個名爲name的屬性。最後，當調用這個函數時，localPerson以函數的形式返回並賦給全局變量globalPerson。由於localPerson在createPerson()函數執行完畢後就離開了其執行環境，因此無需我們顯示的去爲他解除引用。但是對於全局變量globalPerson而言，則需要我們在不使用它的時候手工爲它解除引用，這也正是上面例子中最後一行代碼的目的。
不過，解除一個值的引用並不意味着自動回收該值所佔用的內存。解除引用的真正作用是讓值脫離執行環境，一邊垃圾收集器下次運行時將其回收。
4.避免內存泄漏，避免變量調用形成閉包（循環引用）。
function assignHandler () {
var element = document.getElementById("someElement");
element.onclick = function () {
alert(element.id);
};
};
以上代碼創建了一個作爲element元素時間處理程序的閉包，而這個閉包則有創建了一個循環引用。由於匿名函數保存了一個對assignHandler()的活動對象的引用，因此就會導致無法減少element的引用數。只要匿名函數存在，element的引用數至少也是1，因此它所佔用的內存就永遠不會被回收。不過，這個問題可以通過稍微改寫一下代碼來解決，如下所示：
function assignHandler () {
var element = document.getElementById("someElement");
var id = element.id;
element.onclick = function () {
alert(id);
};
element = null;
};
在上面代碼中，通過把element.id的一個副本保存在一個變量中，並且在閉包中引用該變量消除了循環引用。但僅僅做到這一步，還是不能解決內存泄漏的問題。必須要記住：閉包會引用包含函數活動的整個活動對象，而其中包含着element。即使閉包不直接引用element，包含函數的活動對象中也仍然會保存一個引用。因此，有必要把element變量設置爲null。這樣就能夠解除對DOM對象的引用，順利地減少其引用數，確保正常回收其佔用的內存。