本來是想著學學node.js試試的，後來發現node.js才是真正的js啊，它裡面用到了很多我們平時沒用過的js特性，而且還非常優雅，比如它裡面的非同步程式設計思想，總之，《深入淺出node.js》絕對值得一看。
下面是我的讀書筆記。
1.非同步io的優勢：a.從使用者體驗上來說，非同步io在這個資源的獲取時並不會阻塞下乙個資源，因此我們可以享受併發的體驗；b.從資源分配上來說，單執行緒同步程式設計模型會因阻塞io導致硬體資源得不到更優的使用，多執行緒程式設計模型會因為死鎖、狀態同步等問題讓開發人員頭疼，但是非同步io利用單執行緒，遠離了死鎖和狀態同步等問題，而且利用子程序也彌補了無法利用多核cpu的缺點。
2.阻塞io會造成cpu等待io，浪費等待時間；非阻塞性io返回後，cpu的時間片可以用來處理其他事務，但是應用程式需要重複呼叫io操作來確認是否完成。這種判斷操作叫做輪詢。
3.現存的輪詢技術主要有：
read。重複呼叫來檢查io的狀態。
select。通過檔案描述符的事件狀態來進行判斷。
poll。採用鍊錶的方式避免陣列長度的限制。
epoll。進入輪詢的時候如果沒有檢查到io事件，將會進行休眠。
kqueue。僅在freebsd系統下存在。
4.理想的完美非同步io：應用程式發起非阻塞呼叫，無須通過遍歷或者事件喚醒等方式輪詢，可以直接處理下乙個任務，只需在io完成後通過訊號或者**將資料傳遞給應用程式。
5.現實的非同步io：利用多執行緒解決。讓乙個執行緒進行計算處理，通過執行緒之間的通訊將io得到的資料進行傳遞，這就輕鬆實現了非同步io。
6.由於windows平台和lunix等平台的差異，node提供了libuv作為抽象封裝層，使得所有平台相容性的判斷都由這一層來完成。
7.node的非同步io：完成整個非同步io環節的有事件迴圈、觀察者和請求物件等。
事件迴圈：每個迴圈稱為tick，每個tick的過程檢視是否有事件待處理，有就處理，沒有就進入下個tick。
觀察者：每個事件迴圈中有乙個或多個觀察者，判斷是否有事件處理的過程就是向這些觀察者詢問是否有要處理的事件。
請求物件：呼叫過程中，會建立乙個fsreqwrap請求物件，來掛載js層傳入的引數，並提供呼叫方法。
執行緒池：組裝好請求物件後，會將它送入io執行緒池等待執行。執行完畢之後，會通知當前物件操作已經完成，然後執行**，歸還執行緒池。
8.非io的非同步api：
settimeout和setinterval。
process.nexttick。
setimmediate。
9.伺服器模型：
1.同步式。一次只能處理乙個請求，並且其餘請求都處於等待狀態。
2.每程序/每請求。為每個請求啟動乙個程序。（不具備擴充套件能力，因為系統資源只有那麼多）
3.每執行緒/每請求。為每個請求啟動乙個執行緒。(由於每個執行緒都占用一定記憶體，併發過多時記憶體容易被用光)
4.事件驅動。無須為每乙個請求建立額外的對應執行緒，可以省掉建立執行緒和銷毀執行緒的開銷，上下文切換的代價也很低。
nodejs深入淺出讀書筆記 三
使用者體驗 資源分配 1.單執行緒同步程式設計會因i o導致硬體資源得不到更有的使用 2.多執行緒也會因為程式設計中的死鎖，狀態同步等問題讓人頭痛 nodejs給出的解決方案 1.利用單執行緒，原理多執行緒死鎖，狀態同步等問題 2.利用非同步i o讓單執行緒原理阻塞，更好的使用cpu 3.提供了類似...
node 《深入淺出nodejs》 讀書筆記
事件驅動是指在持續事務管理過程中，進行決策的一種策略，即跟隨當前時間點上出現的事件，調動可用資源，執行相關任務，使不斷出現的問題得以解決，防止事務堆積。訊息是乙個報告事件發生的通知，訊息驅動是圍繞訊息的產生與處理展開的，並依靠訊息迴圈機制來實現。非阻塞io 單執行緒 多執行緒 死鎖 web work...
深入淺出pmp讀書筆記（三）
深入淺出 pmp 讀書筆記 程序結構 pmp將專案劃分成為一系列程序的集合，程序直接的銜接，就十分重要了。而程序的結構已經專案的知識面就是程序銜接流暢的關鍵。1.程序的結構 pmp為所有的程序都設定了相同的結構，每個程序都由輸入，工具和技術以及輸出三部分組成。a.輸入 程序工作所需要的資訊，資料，檔...