Libuv是一個跨平臺的的基於事件驅動的異步io庫。但是他提供的功能不僅僅是io，包括進程、線程、信號、定時器、進程間通信等。下面是來自官網對Libuv架構的介紹圖。
從上圖中我們看到
-
Libuv使用各平臺提供的事件驅動模塊實現異步（epoll, kqueue, IOCP, event
ports）。他用來支持上層非文件io的模塊。libuv把上層的事件和回調封裝成io觀察者（uv__io_t）放到底層的事件驅動模塊。當事件觸發的時候，libuv會執行io觀察者中的回調。 -
Libuv實現一個線程池用來支持上層文件io、dns以及用戶層耗cpu的任務。
Libuv的整體執行架構
從上圖中我們大致瞭解到，Libuv分爲幾個階段，然後在一個循環裏不斷執行每個階段裏的任務。下面我們具體看一下每個階段。
1 更新當前事件，在每次事件循環開始的時候，libuv會更新當前事件到變量中，這一輪循環的剩下操作可能使用這個變量獲取當前事件，避免過多的系統調用影響性能。
2 如果時間循環是處於alive狀態，則開始處理事件循環的每個階段。否則退出這個事件循環。alive狀態是什麼意思呢？如果有active和ref狀態的handle，active狀態的request或者closing狀態的handle則認爲事件循環是alive的（具體的後續會講到）。
3 timer階段：判斷最小堆中的節點哪個節點超時了，執行他的回調。
4 pending階段：執行pending回調。一般來說，所有的io回調（網絡，文件，dns）都會在poll io階段執行。但是有的情況下，poll io階段的回調會延遲到下一次循環執行，那麼這種回調就是在pending階段執行的。
5 idle階段：如果節點處理avtive狀態，每次事件循環都會被執行（idle不是說事件循環空閒的時候才執行）。
6 prepare階段：和idle階段一樣。
7 poll io階段：計算最長等待時間timeout，計算規則：
如果時間循環是以UV_RUN_NOWAIT模式運行的，則timeout是0。
如果時間循環即將退出（調用了uv_stop），則timeout是0。
如果沒有active狀態的handle或者request，timeout是0。
如果有dile階段的隊列裏有節點，則timeout是0。
如果有handle等待被關閉的（即調了uv_close），timeout是0。
如果上面的都不滿足，則取timer階段中最快超時的節點作爲timeout，如果沒有則timeout等於-1，即永遠阻塞，直到滿足條件。
8 poll io階段：調用各平臺提供的io多路複用接口，最多等待timeout時間。返回的時候，執行對應的回調。（比如linux下就是epoll模式）
9 check階段：和idle prepare一樣。
10 closing階段：處理調用了uv_close函數的handle的回調。
11 如果libuv是以UV_RUN_ONCE模式運行的，那事件循環即將退出。但是有一種情況是，poll io階段的timeout的值是timer階段的節點的值。並且poll io階段是因爲超時返回的，即沒有任何事件發生，也沒有執行任何io回調。這時候需要在執行一次timer階段。因爲有節點超時了。
12 一輪事件循環結束，如果libuv以UV_RUN_NOWAIT 或 UV_RUN_ONCE模式運行的，則退出事件循環。如果是以UV_RUN_DEFAULT模式運行的並且狀態是alive，則開始下一輪循環。否則退出事件循環。
下面是Libuv事件循環實現的邏輯。
int uv_run(uv_loop_t* loop, uv_run_mode mode) {
int timeout;
int r;
int ran_pending;
// 在uv_run之前要先提交任務到loop
r = uv__loop_alive(loop);
// 事件循環沒有任務執行，即將退出，設置一下當前循環的時間
if (!r)
uv__update_time(loop);
// 沒有任務需要處理或者調用了uv_stop
while (r != 0 && loop->stop_flag == 0) {
// 更新loop的time字段
uv__update_time(loop);
// 執行超時回調
uv__run_timers(loop);
// 執行pending回調，ran_pending代表pending隊列是否爲空，即沒有節點可以執行
ran_pending = uv__run_pending(loop);
// 繼續執行各種隊列
uv__run_idle(loop);
uv__run_prepare(loop);
timeout = 0;
// 執行模式是UV_RUN_ONCE時，如果沒有pending節點，纔會阻塞式poll io，默認模式也是
if ((mode == UV_RUN_ONCE && !ran_pending) || mode == UV_RUN_DEFAULT)
timeout = uv_backend_timeout(loop);
// poll io timeout是epoll_wait的超時時間
uv__io_poll(loop, timeout);
uv__run_check(loop);
uv__run_closing_handles(loop);
// 還有一次執行超時回調的機會，因爲poll io階段可能是因爲定時器超時返回的。
if (mode == UV_RUN_ONCE) {
uv__update_time(loop);
uv__run_timers(loop);
}
r = uv__loop_alive(loop);
// 只執行一次，退出循環,UV_RUN_NOWAIT表示在poll io階段不會阻塞並且循環只執行一次
if (mode == UV_RUN_ONCE || mode == UV_RUN_NOWAIT)
break;
}
// 是因爲調用了uv_stop退出的，重置flag
if (loop->stop_flag != 0)
loop->stop_flag = 0;
// 返回是否還有活躍的任務（handle或request），業務代表可以再次執行uv_run
return r;
}
文檔 http://docs.libuv.org/en/v1.x/design.html