Java平臺一直以生態的繁榮著稱，大量的類庫、框架幫助開發者們快速搭建應用。而其中大部分Java框架類庫都是基於線程池以及阻塞機制來服務併發的，主要原因包括：
- Java語言在覈心類庫中提供了強大的併發能力，多線程應用可以獲得不俗的性能；
- Java EE的一些標準都是線程級阻塞的(比如JDBC)；
- 基於阻塞模式可以快速地開發應用。
但如今，大量新生的異步框架和支持協程的語言(如Go)的出現，在很多場景下操作系統的線程調度成爲了性能的瓶頸。Java也因此被質疑是否不再適應最新的雲場景了。
4年前，阿里開始自研Wisp2。它主要是用在IO密集的服務器場景，大部分公司的在線服務都是這樣的場景 (離線應用都是偏向於計算，則不適用)。它在功能屬性上對標Goroutine的Java協程，在產品形態、性能、穩定性上都達到了一個比較理想的情況。到現在，已經有上百個應用，數萬個容器上線了Wisp1/2。Wisp協程完全兼容多線程阻塞的代碼寫法，僅需增加JVM參數來開啓協程，阿里巴巴的核心電商應用已經在協程模型上經過兩個雙十一的考驗，既享受到了Java的豐富生態，又獲得了異步程序的性能。
Wisp2主打的是性能和對現有代碼的兼容性，簡而言之，現有的基於多線程的IO密集的Java應用只需要加上Wisp2的JVM參數就可以獲得異步的性能提升。
作爲例子，以下是消息中間件代理(簡稱mq)和drds只添加參數不改代碼的壓測比較：
可以看到上下文切換以及sys CPU顯著降低，RT減少、QPS分別提升11.45%，18.13%。
Quick Start
由於Wisp2完全兼容現有的Java代碼，因此使用起來十分簡單，有多簡單？
如果你的應用是“標準”的在線應用(使用/home/admin/$APP_NAME/setenv.sh配置參數)，那麼在admin用戶下輸入如下命令就可以開啓Wisp2了：
curl https://gosling.alibaba-inc.com/sh/enable-wisp2.sh | sh
否則需要手動升級JDK和Java參數：
ajdk 8.7.12_fp2 rpm
sudo yum install ajdk -b current # 也可以通過yum安裝最新jdk
java -XX:+UseWisp2 … # 使用Wisp參數啓動Java應用
然後就可以通過jstack驗證協程確實被開啓了。
Carrier線程是調度協程的線程，下方的- Coroutine […]表示一個協程，active表示協程被調度的次數，steal表示被work stealing的次數，preempt表示時間片搶佔次數。
下圖是DRDS在ecs上壓測時的top -H，可以看出來應用的數百個線程被8個Carrier線程託管，均勻地跑在CPU核數個線程上面。下方一些名爲java的線程是gc線程。
過多線程的開銷
誤區1: 進內核引發上下文切換
我們看一段測試程序：
pipe(a);
while (1) {
write(a[1], a, 1);
read(a[0], a, 1);
n += 2;
}
執行這段程序時上下文切換非常低，實際上上面的IO系統調用都是不會阻塞的，因此內核不需要掛起線程，也不需要切換上下文，實際發生的是用戶/內核態的模式切換。
上面的程序在神龍服務器測得每個pipe操作耗時約334ns，速度很快。
誤區2: 上下文切換的開銷很大
本質上來說無論是用戶態還是內核態的上下文切換都是很輕量的，甚至有一些硬件指令來支持，比如pusha可以幫助我們保存通用寄存器。同一個進程的線程共享頁表，因此上下文切換的開銷一般只有：
- 保存各種寄存器
- 切換sp(call指令會自動將pc壓棧)
可以在數十條指令內完成。
開銷
既然近內核以及上下文切換都不慢，那麼多線程的開銷究竟在哪？
我們不妨看一個阻塞的系統調用futex的熱點分佈：
可以看到上面的熱點中有大量涉及調度的開銷。我們來看過程：
- 調用系統調用(可能需要阻塞)；
- 系統調用確實需要阻塞，kernel需要決定下一個被執行的線程(調度)；
- 執行上下切換。
因此，上面2個誤區與多線程的開銷都有一定因果關係，但是真正的開銷來源於線程阻塞喚醒調度。
綜上，希望通過線程模型來提升web server性能的原則是：
- 活躍線程數約等於CPU個數
- 每個線程不太需要阻塞
文章後續將緊緊圍繞這兩個主題。
爲了滿足上述兩個條件，使用eventloop+異步callback的方式是一個極佳的選擇。
異步與協程的關係
爲了保持簡潔，我們以一個異步服務器上的Netty寫操作爲例子(寫操作也存在阻塞的可能)：
private void writeQuery(Channel ch) {
ch.write(Unpooled.wrappedBuffer("query".getBytes())).sync();
logger.info("write finish");
}
這裏的sync()會阻塞線程。不滿足期望。由於netty本身是一個異步框架，我們引入回調：
ch.write(Unpooled.wrappedBuffer("query".getBytes()))
.addListener(f -> {
logger.info("write finish");
});
}
注意這裏異步的write調用後，writeQuery會返回。因此假如邏輯上要求在write後執行的代碼，必須出現在回調裏，write是函數的最後一行。這裏是最簡單的情形，如果函數有其他調用者，那麼就需要用CPS變換。
需要不斷的提取程序的"下半部分"，即continuation，似乎對我們造成一些心智負擔了。這裏我們引入kotlin協程幫助我們簡化程序：
suspend fun Channel.aWrite(msg: Any): Int =
suspendCoroutine { cont ->
write(msg).addListener { cont.resume(0) }
}
suspend fun writeQuery(ch: Channel) {
ch.aWrite(Unpooled.wrappedBuffer("query".toByteArray()))
logger.info("write finish")
}
這裏引入了一個魔法suspendCoroutine，我們可以獲得當前Continuation的引用，並執行一段代碼，最後掛起當前協程。Continuation代表了當前計算的延續，通過Continuation.resume()我們可以恢復執行上下文。因此只需在寫操作完成時回調cont.resume(0)，我們又回到了suspendCoroutine處的執行狀態(包括caller writeQuery)，程序繼續執行，代碼返回，執行log。從writeQuery看我們用同步的寫法完成了異步操作。當協程被suspendCoroutine切換走後，線程可以繼續調度其他可以執行的協程來執行，因此不會真正阻塞，我們因此獲得了性能提升。
從這裏看，只需要我們有一個機制來保存/恢復執行上下文，並且在阻塞庫函數裏採用非阻塞+回調的方式讓出/恢復協程，就可以使得以同步形式編寫的程序達到和異步同樣的效果了。
理論上只要有一個庫包裝了所有JDK阻塞方法，我們就可以暢快地編寫異步程序了。改寫的阻塞庫函數本身需要足夠地通用流行，才能被大部分程序使用起來。據我所知，vert.x的kotlin支持已經做了這樣的封裝。
雖然vert.x很流行，但是無法兼顧遺留代碼以及代碼中的鎖阻塞等邏輯。因此不能算是最通用的選擇。實際上Java程序有一個繞不過的庫——JDK。Wisp就是在JDK裏所有的阻塞調用出進行了非阻塞+事件恢復協程的方式支持了協程調度，在爲用戶帶來最大便利的同時，兼顧了現有代碼的兼容性。
上述方式支持了，每個線程不太需要阻塞，Wisp在Thread.start()處，將線程轉成成了協程，來達到了另一目的: 活躍線程數約等於CPU個數。因此只需要使用Wisp協程，所有現有的Java多線程代碼都可以獲得異步的性能。
手工異步/Wisp性能比較
對於基於傳統的編程模型的應用，考慮到邏輯清晰性、異常處理的便利性、現有庫的兼容性，改造成異步成本巨大。使用Wisp相較於異步編程優勢明顯。
下面我們在只考慮性能的新應用的前提下分析技術的選擇。
基於現有組件寫新應用
如果要新寫一個應用我們通常會依賴JDBC、Dubbo、Jedis這樣的常用協議/組件，假如庫的內部使用了阻塞形式，並且沒有暴露回調接口，那麼我們就沒法基於這些庫來寫異步應用了(除非包裝線程池，但是本末倒置了)。下面假設我們依賴的所有庫都有回調支持，比如dubbo。
1）假設我們使用Netty接受請求，我們稱之爲入口eventLoop，收到請求可以在Netty的handler裏處理，也可以爲了io的實時性使用業務線程池。
2）假設請求處理期間需要調用dubbo，因爲dubbo不是我們寫的，因此內部有自己的Netty Eventloop，於是我們向dubbo內部的Netty eventLoop處理IO，等待後端響應後回調。
3）dubbo eventLoop收到響應後在eventloop或者callback線程池調用callback。
4）後續邏輯可以在callback線程池或者原業務線程池繼續處理。
5）爲了完成對客戶端的響應最終總是要由入口的eventloop來寫回響應。
我們可以看到由於這種封裝導致的eventLoop的割裂，即便完全使用回調的形式，我們處理請求時多多少少要在多個eventLoop/線程池之間傳遞，而每個線程又都沒法跑到一個較滿的程度，導致頻繁地進入os調度。與上述的每個線程不太需要阻塞原則相違背。因此雖然減少了線程數，節約了內存，但是我們得到的性能收益變得很有限。
完全從零開始開發
對於一個功能有限的新應用(比如nginx只支持http和mail協議)來說我們可以不依賴現有的組件來重新寫應用。比如我們可以基於Netty寫一個數據庫代理服務器，與客戶端的連接以及與真正後端數據庫的連接共享同一個eventloop。
這樣精確控制線程模型的應用通常可以獲得很好的性能，通常性能是可以高於通過非異步程序轉協程的，原因如下：
- 線程控制更加精確：舉個例子，比如我們可以控制代理的客戶端和後端連接都綁定在同一個netty線程，所有的操作都可以threadLocal化
- 沒有協程的runtime和調度開銷(1%左右)
但是使用協程依舊有一個優勢：對於jdk中無處不在的synchronized塊，wisp可以正確地切換調度。
適應的Workload
基於上述的背景，我們已經知道Wisp或者其他各種協程是適用於IO密集Java程序設計的。否則線程沒有任何切換，只需要盡情地在CPU上跑，OS也不需要過多的干預，這是比較偏向於離線或者科學計算的場景。
在線應用通常需要訪問RPC、DB、cache、消息，並且是阻塞的，十分適合使用Wisp來提升性能。
最早的Wisp1也是對這些場景進行了深度定製，比如hsf接受的請求處理是會自動用協程取代線程池，將IO線程數量設置成1個後使用epoll_wait(1ms)來代替selector.wakeup()，等等。因此我們經常受到的一個挑戰是Wisp是否只適合阿里內部的workload？
- 對於Wisp1是這樣的，接入的應用的參數以及Wisp的實現做了深度的適配。
- 對於Wisp2，會將所有線程轉換成協程，已經無需任何適配了。
爲了證明這一點，我們使用了web領域最權威的techempower benchmak集來驗證，我們選擇了com.sun.net.httpserver、Servlet等常見的阻塞型的測試(性能不是最好，但是最貼近普通用戶，同時具備一定的提升空間)來驗證Wisp2在常見開源組件下的性能，可以看到在高壓力下qps/RT會有10%~20%的優化。
Project Loom
Project Loom作爲OpenJDK上的標準協程實現很值得關注，作爲java開發者我們是否應該擁抱Loom呢？
我們首先對Wisp和Loom這裏進行一些比較：
1）Loom使用序列化的方式保存上下文，更省內存，但是切換效率低。
2）Wisp採用獨立棧的方式，這點和go類似。協程切換隻需切換寄存器，效率高但是耗內存。
3）Loom不支持ObectMonitor，Wisp支持。
- synchronized/Object.wait()將佔用線程，無法充分利用CPU。
- 還可能產生死鎖，以Wisp的經驗來說是一定會產生死鎖(Wisp也是後來陸續支持ObectMonitor的)。
4）Wisp支持在棧上有native函數時切換(反射等等)，Loom不支持。
- 對dubbo這樣的框架不友好，棧底下幾乎都帶有反射。
總根據我們的判斷，Loom至少還要2年時間才能到達一個穩定並且功能完善的狀態。Wisp的性能優秀，功能要完整很多，產品本身也要成熟很多。Loom作爲Oracle項目很有機會進入Java標準，我們也在積極地參與社區，希望能將Wisp的一些功能實現貢獻進社區。
同時Wisp目前完全兼容Loom的Fiber API，假如我們的用戶基於Fiber API來編程，我們可以保證代碼的行爲在Loom和Wisp上表現完全一致。
FAQ
協程也有調度，爲什麼開銷小？
我們一直強調了協程適用於IO密集的場景，這就意味了通常任務執行一小段時間就會阻塞等待IO，隨後進行調度。這種情況下只要系統的CPU沒有完全打滿，使用簡單的先進先出調度策略基本都能保證一個比較公平的調度。同時，我們使用了完全無鎖的調度實現，使得調度開銷相對內核大大減少。
Wisp2爲什麼不使用ForkJoinPool來調度協程？
ForkJoinPool本身十分優秀，但是不太適合Wisp2的場景。
爲了便於理解，我們可以將一次協程喚醒看到做一個Executor.execute()操作，ForkJoinPool雖然支持任務竊取，但是execute()操作是隨機或者本線程隊列操作(取決於是否異步模式)的，這將導致協程在哪個線程被喚醒的行爲也很隨機。
在Wisp底層，一次steal的代價是有點大的，因此我們需要一個affinity，讓協程儘量保持綁定在固定線程，只有線程忙的情況下才發生workstealing。我們實現了自己的workStealingPool來支持這個特性。從調度開銷/延遲等各項指標來看，基本能和ForkJoinPool打平。
還有一個方面是爲了支持類似go的M和P機制，我們需要將被協程阻塞的線程踢出調度器，這些功能都不適宜改在ForkJoinPool裏。
如何看待Reactive編程？
Reactive編程模型已經被業界廣泛接受，是一種重要的技術方向；同時Java代碼裏的阻塞也很難完全避免。我們認爲協程可以作爲一種底層worker機制來支持Reactive編程，即保留了Reactive編程模型，也不用太擔心用戶代碼的阻塞導致了整個系統阻塞。
這裏是Ron Pressler最近的一次演講，作爲Quasar和Loom的作者，他的觀點鮮明地指出了回調模型會給目前的編程帶來很多挑戰 。
Wisp經歷了4年的研發，我將其分爲幾個階段：
1）Wisp1，不支持objectMonitor、並行類加載，可以跑一些簡單應用；
2）Wisp1，支持了objectMonitor，上線電商核心，不支持workStealing，導致只能將一些短任務轉爲協程(否則workload不均勻)，netty線程依舊是線程，需要一些複雜且trick的配置；
3）Wisp2，支持了workStealing，因此可以將所有線程轉成協程，上述netty問題也不再存在了。
目前主要的限制是什麼？
目前主要的限制是不能有阻塞的JNI調用，wisp是通過在JDK中插入hook來實現阻塞前調度的，如果是用戶自定義的JNI則沒有機會hook。
最常見的場景就是使用了Netty的EpollEventLoop：
1）螞蟻的bolt組件默認開啓了這個特點，可以通過-Dbolt.netty.epoll.switch=false 來關閉，對性能的影響不大。
2）也可以使用-Dio.netty.noUnsafe=true , 其他unsafe功能可能會受影響。
3）(推薦) 對於netty 4.1.25以上，支持了通過-Dio.netty.transport.noNative=true 來僅關閉jni epoll，參見358249e5
本文轉載自公衆號阿里技術（ID：ali_tech）。
原文鏈接：