JS具體自動垃圾收集機制（Java也有GC）；也就是說，執行環境會負責管理代碼執行過程中使用的內存。在編寫JS程序時，開發人員不用再關心內存使用問題，所需內存的分配以及無用內存的回收完全實現了自動管理。這種垃圾收集器會按照固定的時間間隔（或代碼中預定的收集時間），周期性的執行這一操作； 下面讓我們一起來分析一下函數中局部變量的正常生命周期。局部變量只在函數執行的過程中存在，而在這個過程中，會為局部變量分配相應的內存空間，以便存儲它們的值。然后在函數中使用這些變量，直至函數執行結束。此時局部變量就沒有存在的必要了，因此可以釋放內存以供將來使用。對于垃圾Js垃圾收集來說一般也就是兩種策略，這兩種策略感覺和Java很相似； **標記清除：** JS中最常用的垃圾收集方式是標記清楚（mark-and-swecp)。當變量進入環境時，我們會標記為“進入環境，并且給它一個標示。從邏輯上講，永遠不能釋放進入環境的變量所占用的內存，因為只要進入到了相應的環境，那么我們的瀏覽器就有可能用到它們，而當變量離開環境時。則將其標記為離開環境； 可以在使用任何方式來標記變量。比如，可以通過翻轉某個特殊的位來記錄一個變量何時進入環境，或者使用一個進入環境的變量列表及一個離開環境的變量列表來跟蹤哪個變量發生了變化。說到底，如何標記變量其實并不重要，關鍵在于采取什么策略。 垃圾收集器在運行的時候會給存儲在內存中的所有變量都加上標記，然后，它會去掉環境中的變量及被環境中的變量引用的變量的標記。而在此之后再被加上離開環境時標記的變量講被視為準備刪除的變量，原因是環境中的變量已經無法訪問到這些變量了，最后，垃圾收集器完成內存的清除工作。銷毀哪些帶標記的值，并回收他們所占用的內存空間。 **引用計數：** 另一種不太常見的垃圾收集策略叫做引用計數（Reference counting）。引用計數的含義是跟蹤記錄每個值被引用的次數。當一個變量引用了另一個變量的時候，則這個值就會加1，如果一個變量又賦值給了另外一個變量，則再加1.相反如果又沒有引用這個值的變量了，那么會減1.當這個值的引用次數為0時，則說明沒有辦法在訪問這個值了，因而可以將其占用的內存空間回收回來。這樣，當垃圾收集器下次再執行時，它就會釋放那些引用次數為零的值所占用的內存。 但是這樣有一個很嚴重的Bug，就是循環引用。即A對象中包含一個指向對象B的指針，而對象B中也包含一個指向對象A的引用。 ~~~ function problem(){ var objectA=new Object(); var objectB=new Object(); objectA.aobject=objectB; objectB.bobject=objectA; } ~~~ 在上面的這個例子中，兩個對象的屬性相互引用；也就是說。這兩個對象的引用次數都是2.在采用標記清除策略的實現中，當函數執行完畢后，兩個變量還繼續存在，因為它們的引用次數永遠都不會是0.假如這個函數被重復多次調用，就會導致大量內存得不到回收。為此現在用的最多的就是標記清除。可是引用計數導致的麻煩還未就此終結； **性能問題：** 垃圾收集器是周期性運行的，而且如果為變量分配的內存數量很客觀，那么回收工作量也是相當大的，在這種情況下，確定垃圾收集的時間間隔是一個非常重要的問題。說到垃圾收集器多長時間運行一次，IE的垃圾收集器是根據內存分配量運行的，具體一點說就是256個變量，4096個對象或數組字面量和數組元素（slot)或者64KB的字符串，達到上述任何一個臨界值，垃圾收集器就會運行。這種實現方式的問題在于，如果一個腳本中包含那么多變量，那么該腳本很可能會在生命周期 中一直保存著那么多變量，而這樣一來，垃圾收集器就不得不頻繁的運行。后來IE7就重寫了其垃圾收集例程。 管理內存： 使用具備垃圾收集機制的語言編寫程序，開發人員一般不必擔心內存管理的問題，但是Js在進行內存管理和垃圾收集時面臨的問題還是于眾不同。最主要的就是分配給微博web瀏覽器的內存數量要比桌面應用程序少。這樣是出于安全方面考慮，內存限制問題不僅會影響給變量分配內存，同時還是影響調用棧以及一個線程中能夠同時執行的語句數量。 因為優化內存占用是一個好習慣，一旦數據不再用，最好設置為null，來釋放其引用，這個做法叫做接觸引用。 **GC優化策略：** （1）分代回收（Generation GC） ?? 這個和Java回收策略思想是一致的。目的是通過區分“臨時”與“持久”對象；多回收“臨時對象”區（young generation），少回收“持久對象”區（tenured generation），減少每次需遍歷的對象，從而減少每次GC的耗時。 （2）增量GC ?? 這個方案的思想很簡單，就是“每次處理一點，下次再處理一點，如此類推”