阿裡妹導讀：随着大量新生的異步架構和支援協程的語言(如Go)的出現，在很多場景下作業系統的線程排程成為了性能的瓶頸，Java也是以被質疑是否不再适應最新的雲場景了。4年前，阿裡JVM團隊開始自研Wisp2，将Go語言的協程能力帶入到Java世界。既享受Java的豐富生态，又獲得異步程式的性能，Wisp2讓Java平台曆久彌新。
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本身是一個異步架構，我們引入回調：
private void writeQuery(Channel ch) {
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
原文釋出時間為：2019-10-31
作者： 梁希
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。