Java Async IO Library: Quasar (use Fiber)

前言

Quasar 提供不少的功能（Go-like channels, Erlang-like actors），這篇博客主要介紹Quasar的核心Fiber和使用Fiber來處理異步IO（本博客給出的例子是發起Http 請求）。

本博客所指的線程均指Linux下的線程，Linux下不區分線程和進程，特別的地方會再作說明。

Fiber是什麼？

Fiber（中文翻譯成纖程） 是JVM上實現的輕量級用戶態線程，和go 語言的goroutine 相似。Fiber 有以下幾個特色：

1. 用戶態，用戶態的線程切換是很是快的,並且單個時間片能夠執行更多的代碼(緣由：操做系統什麼時候進行線程調度(時間片用盡,IO中斷，系統調用等))。衆所周知，咱們在進行系統調用（好比IO請求）的時候，當前的線程就會阻塞，產生線程上下文切換（從用戶態切換到內核態）Context Switch,關於這個方面的測試請查看How long does it take to make a context switch?，從這裏能夠看出上下文切換的代價是很是高的，這也正是Fiber的優點。
2. 輕量級，Fiber 佔有的資源很是少，一個fiber大概在400 bytes of RAM,因此係統裏能夠同時有上百萬個Fiber。

爲何使用Fiber(或者說使用Threads有什麼問題)?

先看一下在JVM 中用戶態線程和內核態線程的對應關係：

Thread: 1:1 一個Java 線程對應一個內核線程.(能夠被內核調度，消耗context switch)

   Fiber:  M:N mapping to kernel threads.

   Strand:  abstraction of thread or fiber（後面會有介紹）.

• 線程不是輕量的（heavy）,也就是說單機可以產生的線程數量是很是有限的，不能知足如今Application併發的需求。
• 在Java Web應用中，咱們使用Java NIO 來接收TCP請求，線程和TCP鏈接是不匹配的。這種方式缺點是比較難以編碼和維護（只是在Library 中使用，不多有用戶代碼中直接使用的）,而Fiber 採起的方式是："thread(fiber)-per-connection"

怎樣不阻塞（non-block）？

傳統作法：

1. CallBacks(hell) 傳統的回調，對應的問題就是末日金字塔...

public void messageFriend() {
       withModule(() -> {
                 withConnection(richard -> {
                        richard.dataHandler(data -> {
                                assertEquals("bob>oh its you!", data.toString());
                                moduleTestComplete();
                           });
                        richard.write("richard\n");
                        withConnection(bob -> {
                                       bob.dataHandler(data -> {
                                                                          assertEquals("richard>hai",data.toString());
                               bob.write("richard<oh its you!");
                               });
                        bob.write("bob\n");
                 vertx.setTimer(6, id -> richard.write("bob<hai"));
             });
         });
       });
}

2.Monads

In Java8 like:

CompletableFuture.supplyAsync().thenAccept()...

這個要優於回調，它去除回調金字塔，可是也有以下的缺點，手動的上下文管理（須要在CompletableFuture 裏面執行），併發邏輯不清晰（你會有不少的 .then().then()），還須要改變接口（方法須要返回 CompletableFuture）

你能夠在這裏看到更多的內容Monads vs Scoped Continuations

Fiber 的作法： Just Block, 由於Fiber 是輕量的，能夠Suspend 和 Resume,Fiber 的執行過程是這樣的，你建立並啓動一個Fiber(Fiber建立和使用和線程同樣):

new Fiber<Void>(new SuspendableRunnable() {
  public void run() throws SuspendExecution, InterruptedException {
    // your code
    bar(); // call bar;
  }
}).start();

而後由 Schedule（有默認提供） 調度，當Fiber須要block的時候，調用Fiber.park()，Schedule 能夠執行其它的操做（效率就是在這個時候體現出來的），而後block完的時候 又經過 Fiber.unpark()繼續執行。

Fiber在JVM上的實現方式(ByteCode instrumentation)

1.怎麼 instrument：

Quasar fibers 依賴 bytecode instrumentation. 能夠經過Java Agent在類加載的時候實現, 也能夠經過在編譯期間經過 Ant task來是實現. 實現的效果就是在原來的代碼中插入一些額外的代碼（或者說字節碼）。

2.爲何Fiber是Suspendable 和 Resumeable 的，就是經過一個Stack來存儲代碼執行的相關信息：

class Stack{
    int[] method;  // PC（程序計數器）, SP(棧指針)
    long[] dataLong; // stack premitives（基地址）
    Object[] dataObject; // stack refs （相關引用）
}

3.Instrumentation 以後在JVM中的執行過程:

before :

if bar() run in a fiber, and it call foo(),so foo() should be Suspendable.

bar(){
    baz();
    foo();          
}

foo(){
    Fiber.park(); // throw Exception
}

after:

bar(){
    int pc = isFiber ? s.pc :0;
    switch(pc){
        case 0:
            baz():
            if(isFiber){
                s.pc=1;
                // store locals -> s
            }
        case 1:
            if(isFiber)
                // load locals <-s
            foo(); // suspendable
    }            
}

foo(){
    int pc =isFiber ? s.pc : 0;
    switch(pc){
        if(isFiber){
            s.pc = 3;
            // store locals -> s
        }
        Fiber.park(); // throw Exception
    case 3:
        if(isFiber)
            // load locals <- s
    }
}

JVM上使用Fiber的一些問題

• Interfaces/superclasses:iff have a suspendable implementation (dynamic proxies marked manually)
• Reflection,invoke dynamic:presumed suspendable(except lambdas)
• Which methods to instrument?(manual/graph analysis)
• Instrument "infection":if we`re conservative and automatic,a lot of methods must be instrumented(e.g. consider Runnable being suspendable - and all it`s callers...)

這些問題的意思是說在進行Instrument的過程當中，針對接口和動態代理方法，只有在運行時才能決定具體的實現類(決定具體的調用方法)，因此須要手動管理列出這些類，這也是Fiber使用起來比較繁瑣的一點，你們能夠參考我最後給出的例子，例子中會給你們一個大概的說明（主要是爲了新手少踩一些坑）。官方文檔也給了詳細的說明，須要耐心一點看完。

Fiber的使用場景

Fibers are not meant to replace threads in all circumstances. A fiber should be used when its body (the code it executes) blocks very often waiting on other fibers (e.g. waiting for messages sent by other fibers on a channel, or waiting for the value of a dataflow-variable). For long-running computations that rarely block, traditional threads are preferable. Fortunately, as we shall see, fibers and threads interoperate very well.

Fiber適用於阻塞頻繁的代碼（好比IO阻塞），並且若是須要消耗CPU的代碼使用Thread,它們能夠同時抽象爲前面的Strand,這樣的話優點就會高於Node（Node 經過單線程異步來高效實現IO請求處理，具體對比我會給出另一篇博客）。

怎樣開始？

建議感興趣的朋友從官方文檔開始Quasar

另外我作了一個使用Spring Boot 和 Fiber來作HttpClient的demo,放在GitHub上，以供你們參考 spring-quasar-demo。

下一篇我會介紹在使用Fiber來作HttpServer。