前言
對于想要真正理解JavaScript工作機制的人，理解JS的事件循環（Event Loop）應當是首當其沖的繞不過的坎。因為事件驅動模型的設計和事件循環機制的實現，才使得js成為一門真正純異步，使得回調函數十分普遍的編程語言，也是Node之所以被作為網絡應用節點，用于高效處理并發I/O的原因。
當你真正理解了事件循環機制時，下面這樣的一些問題相信你也會就了然了。
解釋JavaScript事件模型本身的文章還是非常多的，并且不乏有不少出色的文章。本文將引用部分文章的圖片，結合對Node源碼的分析，逐步理出Node事件循環機制的實現原理。
因為在寫本文時，主要參考的是樸靈老師寫的《深入淺出nodejs》，寫這本書時的node穩定版本為0.10.13，且早期版本的node源碼較少，讀起來較為容易理解，因此這里的代碼分析主要是基于0.10.13來進行的。
事件循環
大家都知道，一般我們會講JS是單線程的，Node在處理I/O的時候也是單線程的，好處就是沒有線程的切換和數據共享的問題。但實際上，在系統底層，非阻塞的I/O解決方案，只有Network I/O部分，linux底層使用epoll，windows下使用IOCP。文件等操作則沒有很好的系統解決方案，因此為了模擬實現非阻塞的I/O方案，Node在libuv層啟用了一個線程池，用于調用系統的阻塞式I/O。
因此，實際上，node只是在應用層屬于單線程，底層其實通過libuv維護了一個阻塞I/O調用的線程池。
JS之所以可以在執行異步操作時可以設置好callback函數之后，就繼續執行后續代碼，當異步操作執行完成時，又能夠及時觸發回調函數，獲取異步結果。最關鍵的核心就在于事件循環。
在進程啟動時，Node便會創建一個類似于while(true)的循環，每執行一次循環體的過程被稱為tick，中文翻譯應該意為“滴答”，就像時鐘一樣，每滴答一下，就表示過去了1s。這個tick也有點這個意思，每循環一次，都表示本次tick結束，下次tick開始。每個tick開始之初，都會檢查是否有事件需要處理，如果有，就取出事件及關聯的callbak函數，如果存在有關聯的callback函數，就把事件的結果作為參數調用這個callback函數執行。如果不在有事件處理，就退出進程。
那么在每個tick的過程中，如何判斷是否有事件需要處理，先要引入一個概念，叫做“觀察者”（watcher）。每一個事件循環都有一個或者多個觀察者，判斷是否有事件要處理的過程就是向這些觀察者詢問是否有需要處理的事件
Node的觀察者有這樣幾種：
idle觀察者：顧名思義，就是早已等在那里的觀察者，以后會說到的process.nextTick就屬于這類
I/O觀察者：顧名思義，就是I/O相關觀察者，也就是I/O的回調事件，如網絡，文件，數據庫I/O等
check觀察者：顧名思義，就是需要檢查的觀察者，后面會說到的setTimeout/setInterval就屬于這類
事件循環是一個典型的生產者/消費者模型。異步I/O，網絡請求，setTimeout等都是典型的事件生產者，源源不斷的為Node提供不同類型的事件，這些事件被傳到對應的觀察者那里，事件循環在每次tick時則從觀察者那里取出事件并處理。
我們現在知道，JavaScript的異步I/O調用過程中，回調函數并不由我們開發者調用，事實上，在JavaScript發起調用到內核執行完I/O操作的過程中，存在一種中間產物，它叫做請求對象。這個請求對象會重新封裝回調函數及參數，并做一些其他的處理。這個請求對象，會在異步事件完成時被調用，取出回調函數和參數，并傳入執行結果進行回調。這個請求對象，在下一篇介紹setTimeout等的文章中會舉例。
組裝好請求對象，送入I/O線程池等待執行，實際上只是完成了異步I/O的第一步；第二步則是異步I/O被線程池處理結束后的回調，也就是執行回調。
因為事件循環的邏輯就是這樣，這里就不手工再重新繪制一張異步I/O流程圖，直接把樸老師書里面的圖貼上來給大家看。
應該說，事件循環、觀察者、請求對象、I/O線程池，這四者共同組成了Node異步I/O模型的基本要素。
源碼分析
下面我給出0.10.13中關于事件循環的源碼分析結果圖對上述分析給予說明
總結
根據源碼分析圖，可以請求出得出這樣幾個結論：
1、每次tick都會檢查所有完成的回調事件，并一一執行回調函數。
2、跑完當前執行環境下能跑完的代碼。每一個事件消息都被運行直到完成為止，在此之前，任何其他事件都不會被處理。這和C等一些語言不通，它們可能在一個線程里面，函數跑著跑著突然停下來，然后其他線程又跑起來了。JS這種機制的一個典型的壞處，就是當某個事件處理耗時過長時，后面的事件處理都會被延后，直到這個事件處理結束，在瀏覽器環境中運行時，可能會出現某個腳本運行時間過長，頁面無響應的提示。Node環境則可能出現大量用戶請求被掛起，不能及時響應的情況。
3、不同類型的觀察者，處理的優先級不同，idle觀察者最先，I/O觀察者其次，check觀察者最后。
