簡單複習下node，不過很多重要的知識點是圖，文字無法展示出來。 1.Node的特點 非同步I/O 事件與回調函數 單線程 跨平臺（libuv） 2.Node的應用場景 I/O密集型（事件迴圈、非同步I/O） CPU密集型（可以採用子進程） 3.CommonJS的模塊規範 模塊引用 模塊定義 模塊標識 ...
簡單複習下node，不過很多重要的知識點是圖，文字無法展示出來。
1.Node的特點
- 非同步I/O
- 事件與回調函數
- 單線程
- 跨平臺（libuv）
2.Node的應用場景
- I/O密集型（事件迴圈、非同步I/O）
- CPU密集型（可以採用子進程）
3.CommonJS的模塊規範
- 模塊引用
- 模塊定義
- 模塊標識
4.Node的模塊實現
- 優先從緩存載入
- 路徑分析和文件定位（核心模塊》文件模塊》自定義模塊）（.js、.json、.node）
- 模塊編譯（js：fs讀取。node：dlopen()。json：fs模塊+JSON.parse()）
5.AMD規範與CMD規範
-
對於依賴的模塊，AMD 是提前執行，CMD 是延遲執行。
- CMD 推崇依賴就近，AMD 推崇依賴前置
6.Node的非同步I/O
- 事件迴圈
- 觀察者
- 請求對象
- 執行回調
事件迴圈、觀察者、請求對象、I/O線程池這死者共同構成了Node非同步I/O模型的基本要素。
windows下主要通過IOCP來向系統發送I/O調用和從內核獲取已完成的I/O操作，配以事件迴圈，以此來完成非同步I/O的過程。
在linux下通過epoll來實現這個過程。，FreeBSD通過kqueue實現，Solaris通過Event ports實現。
不同的是線程池在windos下由內核（IOCP）直接提供，*nix系列下由libuv自行實現。
7.非I/O的非同步API
執行順序可以參考這篇文章
https://juejin.im/post/5b097df46fb9a07aa213cf88
異或是這兩篇
http://www.cnblogs.com/wuguanglin/p/EventLoop.html
https://www.jianshu.com/p/12b9f73c5a4f
8.非同步編程解決方案
- 事件發佈/訂閱模式
- Promise
- Generator
- Async/Await
9.V8的記憶體限制
Node基於V8構建，在Node使用的javascript對象基本上都是通過V8自己的方式來進行分配和管理。V8的這套記憶體管理機制在瀏覽器的應用場景下綽綽有餘，但在Node中，卻限制了開發者隨心所欲使用大記憶體的想法。
V8為何要限制堆的大小，表層原因為V8最初為瀏覽器而設計，不太可能遇到用大量記憶體的場景。深層的原因是V8的垃圾回收機制的限制。（記憶體越大，垃圾回收耗時越長）
10.V8的垃圾回收機制
V8的垃圾回收策略主要基於分代式垃圾回收機制：現代的垃圾回收演算法中按對象的存活時間將記憶體的垃圾回收進行不同的分代，然後分別對不同分代的記憶體施以更高效的演算法。
在V8中，主要將記憶體分為新生代和老生代兩代，新生代中的對象為存活時間較短的對象，老生代中的對象為存活時間較長或常駐記憶體的對象。
V8堆記憶體的最大保留空間=4*reserved_semispace_size_+max_old_generation_size_
預設情況下，V8堆記憶體的最大值在64位系統上為1464MB，32位系統上則為732MB。
新生代對象回收演算法：Scavenge(打掃)演算法（具體實現為Cheney演算法），典型的犧牲空間換取時間的演算法
當開始進行垃圾回收時，會檢查from空間的存活對象，這些存活對象將被覆制到To空間中，而非存活對象占用的空間將會被釋放。完成複製後，From空間和To空間的角色發生對換。簡而言之，在垃圾的回收過程中，就是講存活對象在兩個semispace空間之間進行複製。
對象晉升的條件：a.對象是否經歷過一次Scavenge回收。b.To空間的記憶體占比是否超過限制。
老生代對象回收演算法：Mark-Sweep(標記清除)&Mark-Compat(標記整理)
Mark-Sweep是標記清除的意思，它分為標記和清除兩個階段。與Scavenge相比，Mark-Sweep並不將記憶體空間劃分為兩半，所以不存在浪費一半空間的行為。與Scavenge複製活著的對象不同，Mark-Sweep在標記階段遍歷堆中所有的對象，並標記活著的對象，在隨後的清除階段中，只清除沒有被標記的對象。可以看出,Scavenge中只複製活著的對象，而Mark-Sweep只清理死亡對象，活對象在新生代中只占較小部分，死對象在老生代中只占較小部分，這是兩種回收方式能高效的原因。
MarkSweep最大的問題是在一次標記清除回收後，記憶體空間會出現不連續的狀態。
為瞭解決MarkSweep的記憶體碎片問題，Mark-Compat被提出來：對象在標記為死亡後，在整理的過程中，將活著的對象往一端移動，移動完成後，直接清理掉邊界外的記憶體。
V8主要使用Mark-Sweep，在空間不足以對新生代中晉升過來的對象進行分配時才是用Mark-Compat
為了降低全堆垃圾回收帶來的停頓時間，V8先從標記階段入手，將原來要一口氣停頓完成的動作改為增量標記（Incemental Marking）,也就是拆分為許多小“步進”，垃圾回收與應用邏輯交替執行直到標記階段完成。
V8後續還引入了延遲清理（lazy sweeping）與增量式清理（incremental compaction）,還計劃引入並行標記與並行清理。
11.如何高效使用記憶體
由於全局作用域需要直到進程退出才能釋放，此時將導致引用的對象常駐記憶體（常駐在老生代中），建議通過賦值的方式解除引用。
閉包會導致作用域無法釋放，即產生的記憶體占用也得不到釋放，除非不再引用，才會逐步釋放。
12.堆外記憶體
rss（進程的常駐記憶體）=堆記憶體+堆外記憶體
Node的記憶體使用並非都是通過V8進行分配的，那些不通過V8分配的記憶體稱為堆外記憶體。
利用堆外記憶體可以突破記憶體限制的問題
Buffer對象不經過V8的記憶體分配機制，而是在Node的C++層面實現記憶體的申請的。
Node提供了Stream模塊用於處理大文件。
13.造成記憶體泄露的常見原因
- 緩存（應當限制緩存的無限增長。使用大緩存的解決方案：進程外的緩存。Redis和Memcached）
- 隊列消費不及時（消費速度低於生產速度，產生堆積。解決方案：a.監控隊列的長度.b.超時機制）
- 作用域未釋放
14.Buffer
Buffer是一個像Array的毒香，但它主要用於操作位元組。
創建的話就用Buffer.from()方法
Buffer的記憶體分配不是在V8的堆記憶體中，而是在C++層面實現記憶體的申請的。Node採用了slab分配機制，一種動態記憶體管理機制。
簡單而言，slab是一塊申請好的固定大小的記憶體區域，具有3種狀態。
- full：完全分配狀態
- partial：部分分配狀態
- empty：沒有被分配狀態
並且Node以8KB為界限來區分Buffer是小對象還是大對象，從而採用不同的分配方法。
小Buffer對象一般都是儘量占滿slab單元，slab單元不夠的話，就會創建新的slab單元
大Buffer對象則是獨占整個slab單元（SlowBuffer對象）。
