這篇文章主要介紹了nodejs中的fiber（纖程）庫詳解,本文講解了node-fibers的安裝、API介紹、方法使用示例等內容,需要的朋友可以參考下
fiber/纖程
在操作系統中，除了進程和線程外，還有一種較少應用的纖程（fiber，也叫協程）。纖程常常拿來跟線程做對比，對於操作系統而言，它們都是較輕量級的運行態。通常認為纖程比線程更為輕量，開銷更小。不同之處在於，纖程是由線程或纖程創建的，纖程調度完全由用戶代碼控制，對系統內核而言，是一種非搶占性的調度方式，纖程實現了合作式的多任務；而線程和進程則受內核調度，依照優先級，實現了搶占式的多任務。另外，系統內核是不知道纖程的具體運行狀態，纖程的使用其實是比較與操作系統無關。
在node中，單線程是僅針對javascript而言的，其底層其實充斥著多線程。而如果需要在javascript中實現多線程，一種常見的做法是編寫C++ addon，繞過javascript的單線程機制。不過這種方法提升了開發調試的難度和成本。像其他很多腳本語言，我們也可以把纖程的概念引入到node中。
node-fibers
node-fibers這個庫就為node提供了纖程的功能。多線程方面沒有測試出理想的結果，不過在異步轉同步作用顯著，也許在減少node調用堆棧、無限遞歸方面也會有價值可挖。本文檔主要介紹 node-fibers庫的使用方法和異步轉同步等內容。
安裝
node-fibers是采用C語言編寫，直接下載源碼需要編譯，通常直接npm安裝即可：
代碼如下:
fibers庫的使用
API
1.Fiber(fn)/ new Fiber(fn):
創建一個纖程，可以當成構造函數使用，也可以當成普通函數調用。如下例：
代碼如下:
當 run()調用的時候，纖程啟動，並為 fn分配新的堆棧， fn會在這個新的堆棧上運行，直到 fn有返回值或調用 yield()。 fn返回後或調用 yield()後，堆棧重置，當再次調用 run()時，纖程會再次啟動， fn運行於首次分配的堆棧中。
2.Fiber.current:
獲得當前纖程，並可對其進行操作。如果指定一個變量與其相關聯，請務必確保此纖程能夠釋放，否則V8的垃圾回收機制會一直忽略這部分的內存，造成內存洩漏。
3.Fiber.yield(param):
前面的說明中已經提及過這個函數。 yield()方法用於中斷纖程，一定程度上類似 return。一旦執行 yield()，則此 Fiber中後續代碼將沒有機會執行，例如：
代碼如下:
執行後只會輸出“Fiber Start”，後一個輸出命令沒有執行。如果向 yield()傳入參數，那麼此參數作為 run()的返回值。
代碼如下:
4.Fiber.prototype.run(param):
這個方法已經很熟悉了，之前隱約有提及調用 run()的兩種時態，一是Fiber未啟動時，一時Fiber被yield時。在這兩種時態下， run()的行為並不太一樣。
當Fiber未啟動時， run()接受一個參數，並把它傳遞給 fn，作為其參數。當Fiber處理yielding狀態時， run()接受一個參數，並把它作為 yield()的返回值，fn並不會從頭運行，而是從中斷處繼續運行。關於 fn、 yield、 run三者的參數、返回值等關系，可以通過下面的小例子來說明：
代碼如下:
輸出如下：
代碼如下:
從上面例子中，可以很明顯看出 yield的使用方法與現在的javascript的語法相當不同。在別的語言中（C#、Python等）已經實現了 yield關鍵字，作為迭代器的中斷。不妨在node上也實現一個迭代器，具體體會一下 yield的使用。還是以開頭的斐波那契數列為例：
代碼如下:
輸出為：
代碼如下:
有兩個問題需要留意，第一， yield說是方法，更多地像關鍵字，與 run不同， yield不需要依托Fiber實例，而 run則需要。如果在Fiber內部調用 run，則一定要使用： Fiber.current.run()；第二， yield本身為javascript的保留關鍵字，不確定是否會、何時會啟用，所以代碼在將來可能會面臨變更。
5.Fiber.prototype.reset():
我們已經知道Fiber可能存在不同的時態，同時會影響 run的行為。而 reset方法則不管Fiber處理什麼狀態，都恢復到初始狀態。隨後再執行 run，就會重新運行 fn。
6.Fiber.prototype.throwInto(Exception):
本質上 throwInto會拋出傳給它的異常，並將異常信息作為 run的返回值。如果在Fiber內不對它拋出的異常作處理，異常會繼續冒泡。不管異常是否處理，它會強制 yield，中斷Fiber。
future庫的使用
在node中直接使用Fiber並不一直是合理的，因為Fiber的API實在簡單，實際使用中難免會產生重復冗長的代碼，不利於維護。推薦在node與Fiber之間增加一層抽象，讓Fiber能夠更好地工作。 future庫就提供了這樣一種抽象。 future庫或者任何一層抽象也許都不是完美的，沒有誰對誰錯，只有適用不適用。比如， future庫向我們提供了簡單的API能夠完成異步轉同步的工作，然而它對封裝 generator （類似上面的斐波那契數列生成器）則無能為力。
future庫不需要單獨下載安裝，已經包含在 fibers庫中，使用時只需要 var future=require('fibers/future') 即可。
API
1.Function.prototype.future():
給 Function類型添加了 future方法，將function轉化成一個“funture-function”。
代碼如下:
實際上 power方法是在Fibel內執行的。不過現有版本的 future有bug，官方沒有具體的說明，如果需要使用此功能，請刪除掉 future.js的第339行和第350行。
2.new Future()
Future對象的構造函數，下文詳細介紹。
3.Future.wrap(fn, idx)
wrap方法封裝了異步轉同步的操作，是 future庫中對我們最有價值的方法。 fn表示需要轉換的函數， idx表示 fn接受的參數數目，認為其 callback方法為最後一個參數（這邊API的制定頗有爭議，有人傾向傳遞 callback應該處於的位置，好在 wrap方法比較簡單，可以比較容易修改代碼）。看一個例子就能了解 wrap的用法：
代碼如下:
從這個例子中可以看出Fiber異步轉同步確實非常有效，除了語法上多了一步 .wait()外，其他已經 fs提供的 fs.readFileSync方法別無二致了。
4.Future.wait(futures):
這個方法前面已經多次看到了。顧名思義，它的作用就是等待結果。如果要等待一個future的實例的結果，直接調用 futureInstance.wait()即可；如果需要等待一系列future實例的結果，則調用 Future.wait(futuresArray)。需要注意的是，在第二種用法中，一個future實例在運行時出現錯誤， wait方法不會拋出錯誤，不過我們可以使用 get()方法直接獲取運行結果。
5.Future.prototype.get():
get()的用法與 wait()的第一種方式很像，所不同的是， get()立刻返回結果。如果數據沒有准備好， get()會拋出錯誤。
6.Future.prototype.resolve(param1,param2):
上面的的 wrap方法總給人以一種 future其實在吞噬異步方法的回調函數，並直接返回異步結果。事實上 future也通過 resolve方法提供設置回調函數的解決方案。 resolve最多接受兩個參數，如果只傳入一個參數， future認為傳了一個node風格的回調函數，例如如下示例：
代碼如下:
如果傳入兩個參數，則表示對錯誤和數據分別做處理，示例如下：
代碼如下:
另外 future並不區分 resolve的調用時機，如果數據沒有准備好，則將回調函數壓入隊列，由 resolver()方法統一調度，否則直接取數據立即執行回調函數。
7.Future.prototype.isResolved():
返回布爾值，表示操作是否已經執行。
8.Future.prototype.proxy(futureInstance):
proxy方法提供一種 future實例的代理，本質上是對 resolve方法的包裝，其實是將一個instance的回調方法作為另一個instance的回調執行者。例如：
代碼如下:
雖然執行的是 proxy，但是最終 target的回調函數執行了，並且是以 proxy的執行結果驅動 target的回調函數。這種代理手段也許在我們的實際應用中有很大作用，我暫時還沒有深入地思考過。
9.Future.prototype.return(value):
10.Future.prototype.throw(error):
11.Future.prototype.resolver():
12.Future.prototype.detach():
以上四個API呢我感覺相對於別的API，實際使用的場景或作用比較一般。 return和 throw都受 resolver方法調度，這三個方法都很重要，在正常的future使用流程中都會默默工作著，只是我沒有想出具體單獨使用它們的場景，所以沒有辦法具體介紹。 detach方法只能算 resolve方法的簡化版，亦沒有介紹的必要。