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