相對C/C++ 而言,我們所用的JavaScript 在內存這一方面的處理已經讓我們在開發中更注重業務邏輯的編寫。但是隨著業務的不斷復雜化,單頁面應用、移動HTML5 應用和Node.js 程序等等的發展,JavaScript 中的內存問題所導致的卡頓、內存溢出等現象也變得不再陌生。
這篇文章將從JavaScript 的語言層面進行內存的使用和優化的探討。從大家熟悉或略有耳聞的方面,到大家大多數時候不會注意到的地方,我們一一進行剖析。
1. 語言層面的內存管理
1.1 作用域
作用域(scope)是JavaScript 編程中一個非常重要的運行機制,在同步JavaScript 編程中它并不能充分引起初學者的注意,但在異步編程中,良好的作用域控制技能成為了JavaScript 開發者的必備技能。另外,作用域在JavaScript 內存管理中起著至關重要的作用。
在JavaScript中,能形成作用域的有函數的調用、with語句和全局作用域。
如以下代碼為例:
這里我們定義了foo()函數和bar()函數,他們的意圖都是為了定義一個名為local的變量。但最終的結果卻截然不同。
在foo()函數中,我們使用var語句來聲明定義了一個local變量,而因為函數體內部會形成一個作用域,所以這個變量便被定義到該作用域中。而且foo()函數體內并沒有做任何作用域延伸的處理,所以在該函數執行完畢后,這個local變量也隨之被銷毀。而在外層作用域中則無法訪問到該變量。
而在bar()函數內,local變量并沒有使用var語句進行聲明,取而代之的是直接把local作為全局變量來定義。故外層作用域可以訪問到這個變量。
如以下代碼所示:
根據前面關于作用域的闡述,你可能會認為這里的代碼所顯示的結果是world,但實際的結果卻是hello。很多初學者在這里就會開始感到困惑了,那么我們再來看看這段代碼是怎么工作的。
由于JavaScript 中,變量標識符的查找是從當前作用域開始向外查找,直到全局作用域為止。所以JavaScript 代碼中對變量的訪問只能向外進行,而不能逆而行之。
baz()函數的執行在全局作用域中定義了一個全局變量val。而在bar()函數中,對val這一標識符進行訪問時,按照從內到外厄德查找原則:在bar函數的作用域中沒有找到,便到上一層,即foo()函數的作用域中查找。
然而,使大家產生疑惑的關鍵就在這里:本次標識符訪問在foo()函數的作用域中找到了符合的變量,便不會繼續向外查找,故在baz()函數中定義的全局變量val并沒有在本次變量訪問中產生影響。
1.3 閉包
我們知道JavaScript 中的標識符查找遵循從內到外的原則。但隨著業務邏輯的復雜化,單一的傳遞順序已經遠遠不能滿足日益增多的新需求。
我們先來看看下面的代碼:
這里所展示的讓外層作用域訪問內層作用域的技術便是閉包(Closure)。得益于高階函數的應用,使foo()函數的作用域得到『延伸』。
foo()函數返回了一個匿名函數,該函數存在于foo()函數的作用域內,所以可以訪問到foo()函數作用域內的local變量,并保存其引用。而因這個函數直接返回了local變量,所以在外層作用域中便可直接執行bar()函數以獲得local變量。
閉包是JavaScript 的高級特性,我們可以借助它來實現更多更復雜的效果來滿足不同的需求。但是要注意的是因為把帶有內部變量引用的函數帶出了函數外部,所以該作用域內的變量在函數執行完畢后的并不一定會被銷毀,直到內部變量的引用被全部解除。所以閉包的應用很容易造成內存無法釋放的情況。
2. JavaScript 的內存回收機制
這里我將以Chrome 和Node.js 所使用的,由Google 推出的V8 引擎為例,簡要介紹一下JavaScript 的內存回收機制,更詳盡的內容可以購買我的好朋友樸靈的書《深入淺出Node.js 》進行學習,其中『內存控制』一章中有相當詳細的介紹。
在V8 中,所有的JavaScript 對象都是通過『堆』來進行內存分配的。
當我們在代碼中聲明變量并賦值時,V8 就會在堆內存中分配一部分給這個變量。如果已申請的內存不足以存儲這個變量時,V8 就會繼續申請內存,直到堆的大小達到了V8 的內存上限為止。默認情況下,V8 的堆內存的大小上限在64位系統中為1464MB,在32位系統中則為732MB,即約1.4GB 和0.7GB。
另外,V8 對堆內存中的JavaScript 對象進行分代管理:新生代和老生代。新生代即存活周期較短的JavaScript 對象,如臨時變量、字符串等;而老生代則為經過多次垃圾回收仍然存活,存活周期較長的對象,如主控制器、服務器對象等。
垃圾回收算法一直是編程語言的研發中是否重要的一環,而V8 中所使用的垃圾回收算法主要有以下幾種:
1.Scavange 算法:通過復制的方式進行內存空間管理,主要用于新生代的內存空間;
2.Mark-Sweep 算法和Mark-Compact 算法:通過標記來對堆內存進行整理和回收,主要用于老生代對象的檢查和回收。
PS: 更詳細的V8 垃圾回收實現可以通過閱讀相關書籍、文檔和源代碼進行學習。
我們再來看看JavaScript 引擎在什么情況下會對哪些對象進行回收。
2.1 作用域與引用
初學者常常會誤認為當函數執行完畢時,在函數內部所聲明的對象就會被銷毀。但實際上這樣理解并不嚴謹和全面,很容易被其導致混淆。
引用(Reference)是JavaScript 編程中十分重要的一個機制,但奇怪的是一般的開發者都不會刻意注意它、甚至不了解它。引用是指『代碼對對象的訪問』這一抽象關系,它與C/C++ 的指針有點相似,但并非同物。引用同時也是JavaScript 引擎在進行垃圾回收中最關鍵的一個機制。
以下面代碼為例:
閱讀完這段代碼,你能否說出這部分代碼在執行過后,有哪些對象是依然存活的么?
根據相關原則,這段代碼中沒有被回收釋放的對象有val和bar(),究竟是什么原因使他們無法被回收?
JavaScript 引擎是如何進行垃圾回收的?前面說到的垃圾回收算法只是用在回收時的,那么它是如何知道哪些對象可以被回收,哪些對象需要繼續生存呢?答案就是JavaScript 對象的引用。
JavaScript 代碼中,哪怕是簡單的寫下一個變量名稱作為單獨一行而不做任何操作,JavaScript 引擎都會認為這是對對象的訪問行為,存在了對對象的引用。為了保證垃圾回收的行為不影響程序邏輯的運行,JavaScript 引擎就決不能把正在使用的對象進行回收,不然就亂套了。所以判斷對象是否正在使用中的標準,就是是否仍然存在對該對象的引用。但事實上,這是一種妥協的做法,因為JavaScript 的引用是可以進行轉移的,那么就有可能出現某些引用被帶到了全局作用域,但事實上在業務邏輯里已經不需要對其進行訪問了,應該被回收,但是JavaScript 引擎仍會死板地認為程序仍然需要它。
如何用正確的姿勢使用變量、引用,正是從語言層面優化JavaScript 的關鍵所在。
3. 優化你的JavaScript
終于進入正題了,非常感謝你秉著耐心看到了這里,經過上面這么多介紹,相信你已經對JavaScript 的內存管理機制有了不錯的理解,那么下面的技巧將會讓你如虎添翼。
3.1 善用函數
如果你有閱讀優秀JavaScript 項目的習慣的話,你會發現,很多大牛在開發前端JavaScript 代碼的時候,常常會使用一個匿名函數在代碼的最外層進行包裹。
這樣做有什么好處?我們都知道文章開始的時候就說了,JavaScript中能形成作用域的有函數的調用、with語句和全局作用域。而我們也知道,被定義在全局作用域的對象,很有可能是會一直存活到進程退出的,如果是一個很大的對象,那就麻煩了。比如有的人喜歡在JavaScript中做模版渲染:
這種代碼在新手的作品中經常能看得到,這里存在什么問題呢?如果在從數據庫中獲取到的數據的量是非常大的話,前端完成模板渲染以后,data變量便被閑置在一邊??梢驗檫@個變量是被定義在全局作用域中的,所以JavaScript引擎不會將其回收銷毀。如此該變量就會一直存在于老生代堆內存中,直到頁面被關閉。
可是如果我們作出一些很簡單的修改,在邏輯代碼外包裝一層函數,這樣效果就大不同了。當UI渲染完成之后,代碼對data的引用也就隨之解除,而在最外層函數執行完畢時,JavaScript引擎就開始對其中的對象進行檢查,data也就可以隨之被回收。
3.2 絕對不要定義全局變量
我們剛才也談到了,當一個變量被定義在全局作用域中,默認情況下JavaScript 引擎就不會將其回收銷毀。如此該變量就會一直存在于老生代堆內存中,直到頁面被關閉。
那么我們就一直遵循一個原則:絕對不要使用全局變量。雖然全局變量在開發中確實很省事,但是全局變量所導致的問題遠比其所帶來的方便更嚴重。
使變量不易被回收;
1.多人協作時容易產生混淆;
2.在作用域鏈中容易被干擾。
3.配合上面的包裝函數,我們也可以通過包裝函數來處理『全局變量』。
3.3 手工解除變量引用
如果在業務代碼中,一個變量已經確切是不再需要了,那么就可以手工解除變量引用,以使其被回收。
3.4 善用回調
除了使用閉包進行內部變量訪問,我們還可以使用現在十分流行的回調函數來進行業務處理。
回調函數是一種后續傳遞風格(Continuation Passing Style, CPS)的技術,這種風格的程序編寫將函數的業務重點從返回值轉移到回調函數中去。而且其相比閉包的好處也不少:
1.如果傳入的參數是基礎類型(如字符串、數值),回調函數中傳入的形參就會是復制值,業務代碼使用完畢以后,更容易被回收;
2.通過回調,我們除了可以完成同步的請求外,還可以用在異步編程中,這也就是現在非常流行的一種編寫風格;
3.回調函數自身通常也是臨時的匿名函數,一旦請求函數執行完畢,回調函數自身的引用就會被解除,自身也得到回收。
3.5 良好的閉包管理
當我們的業務需求(如循環事件綁定、私有屬性、含參回調等)一定要使用閉包時,請謹慎對待其中的細節。
循環綁定事件可謂是JavaScript 閉包入門的必修課,我們假設一個場景:有六個按鈕,分別對應六種事件,當用戶點擊按鈕時,在指定的地方輸出相應的事件。
這里第一個解決方案顯然是典型的循環綁定事件錯誤,這里不細說,詳細可以參照我給一個網友的回答;而第二和第三個方案的區別就在于閉包傳入的參數。
第二個方案傳入的參數是當前循環下標,而后者是直接傳入相應的事件對象。事實上,后者更適合在大量數據應用的時候,因為在JavaScript的函數式編程中,函數調用時傳入的參數是基本類型對象,那么在函數體內得到的形參會是一個復制值,這樣這個值就被當作一個局部變量定義在函數體的作用域內,在完成事件綁定之后就可以對events變量進行手工解除引用,以減輕外層作用域中的內存占用了。而且當某個元素被刪除時,相應的事件監聽函數、事件對象、閉包函數也隨之被銷毀回收。
3.6 內存不是緩存
緩存在業務開發中的作用舉足輕重,可以減輕時空資源的負擔。但需要注意的是,不要輕易將內存當作緩存使用。內存對于任何程序開發來說都是寸土寸金的東西,如果不是很重要的資源,請不要直接放在內存中,或者制定過期機制,自動銷毀過期緩存。
4. 檢查JavaScript 的內存使用情況
在平時的開發中,我們也可以借助一些工具來對JavaScript 中內存使用情況進行分析和問題排查。
4.1 Blink / Webkit 瀏覽器
在Blink / Webkit 瀏覽器中(Chrome, Safari, Opera etc.),我們可以借助其中的Developer Tools 的Profiles 工具來對我們的程序進行內存檢查。
4.2 Node.js 中的內存檢查
在Node.js 中,我們可以使用node-heapdump 和node-memwatch 模塊進行內存檢查。
這樣在文件目錄下會有一個以heapdump-<sec>.<usec>.heapsnapshot格式命名的快照文件,我們可以使用瀏覽器的Developer Tools中的Profiles工具將其打開,并進行檢查。
5. 小結
很快又來到了文章的結束,這篇分享主要向大家展示了以下幾點內容:
1.JavaScript 在語言層面上,與內存使用息息相關的東西;
2.JavaScript 中的內存管理、回收機制;
3.如何更高效地使用內存,以至于讓出產的JavaScript 能更有拓展的活力;
4.如何在遇到內存問題的時候,進行內存檢查。
希望通過對這篇文章的學習,你能夠出產更優秀的JavaScript 代碼,讓媽媽安心、讓老板放心。
新聞熱點
疑難解答