前言

隨著大量新生的異步框架和支持協(xié)程的語言(如Go)的出現(xiàn)尊流，在很多場景下操作系統(tǒng)的線程調(diào)度成為了性能的瓶頸帅戒，Java也因此被質(zhì)疑是否不再適應(yīng)最新的云場景了。4年前崖技，阿里JVM團隊開始自研Wisp2逻住，將Go語言的協(xié)程能力帶入到Java世界。既享受Java的豐富生態(tài)迎献，又獲得異步程序的性能瞎访，Wisp2讓Java平臺歷久彌新。

Java平臺一直以生態(tài)的繁榮著稱吁恍，大量的類庫扒秸、框架幫助開發(fā)者們快速搭建應(yīng)用。而其中大部分Java框架類庫都是基于線程池以及阻塞機制來服務(wù)并發(fā)的冀瓦，主要原因包括：

1. Java語言在核心類庫中提供了強大的并發(fā)能力伴奥，多線程應(yīng)用可以獲得不俗的性能；
2. Java EE的一些標(biāo)準(zhǔn)都是線程級阻塞的(比如JDBC)翼闽；
3. 基于阻塞模式可以快速地開發(fā)應(yīng)用渔伯。

但如今，大量新生的異步框架和支持協(xié)程的語言(如Go)的出現(xiàn)肄程，在很多場景下操作系統(tǒng)的線程調(diào)度成為了性能的瓶頸。Java也因此被質(zhì)疑是否不再適應(yīng)最新的云場景了选浑。

4年前蓝厌，阿里開始自研Wisp2。它主要是用在IO密集的服務(wù)器場景古徒，大部分公司的在線服務(wù)都是這樣的場景 (離線應(yīng)用都是偏向于計算拓提，則不適用)。它在功能屬性上對標(biāo)Goroutine的Java協(xié)程隧膘，在產(chǎn)品形態(tài)代态、性能寺惫、穩(wěn)定性上都達(dá)到了一個比較理想的情況。到現(xiàn)在蹦疑，已經(jīng)有上百個應(yīng)用西雀，數(shù)萬個容器上線了Wisp1/2。Wisp協(xié)程完全兼容多線程阻塞的代碼寫法歉摧，僅需增加JVM參數(shù)來開啟協(xié)程艇肴，阿里巴巴的核心電商應(yīng)用已經(jīng)在協(xié)程模型上經(jīng)過兩個雙十一的考驗，既享受到了Java的豐富生態(tài)叁温，又獲得了異步程序的性能再悼。

Wisp2主打的是性能和對現(xiàn)有代碼的兼容性，簡而言之膝但，現(xiàn)有的基于多線程的IO密集的Java應(yīng)用只需要加上Wisp2的JVM參數(shù)就可以獲得異步的性能提升冲九。

作為例子，以下是消息中間件代理(簡稱mq)和drds只添加參數(shù)不改代碼的壓測比較：

image

可以看到上下文切換以及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

否則需要手動升級JDK和Java參數(shù)：

ajdk 8.7.12_fp2 rpm

sudo yum install ajdk -b current # 也可以通過yum安裝最新jdk
java -XX:+UseWisp2 .... # 使用Wisp參數(shù)啟動Java應(yīng)用

然后就可以通過jstack驗證協(xié)程確實被開啟了。

Carrier線程是調(diào)度協(xié)程的線程刨肃，下方的- Coroutine [...]表示一個協(xié)程古拴，active表示協(xié)程被調(diào)度的次數(shù)，steal表示被work stealing的次數(shù)真友，preempt表示時間片搶占次數(shù)黄痪。

image

下圖是DRDS在ecs上壓測時的top -H，可以看出來應(yīng)用的數(shù)百個線程被8個Carrier線程托管盔然，均勻地跑在CPU核數(shù)個線程上面桅打。下方一些名為java的線程是gc線程。

image

過多線程的開銷

誤區(qū)1: 進(jìn)內(nèi)核引發(fā)上下文切換

我們看一段測試程序：

pipe(a);
while (1) {
  write(a[1], a, 1);
  read(a[0], a, 1);
  n += 2;
}

image

執(zhí)行這段程序時上下文切換非常低愈案，實際上上面的IO系統(tǒng)調(diào)用都是不會阻塞的挺尾，因此內(nèi)核不需要掛起線程，也不需要切換上下文站绪，實際發(fā)生的是用戶/內(nèi)核態(tài)的模式切換遭铺。

上面的程序在神龍服務(wù)器測得每個pipe操作耗時約334ns，速度很快。

誤區(qū)2: 上下文切換的開銷很大

本質(zhì)上來說無論是用戶態(tài)還是內(nèi)核態(tài)的上下文切換都是很輕量的魂挂，甚至有一些硬件指令來支持甫题，比如pusha可以幫助我們保存通用寄存器。同一個進(jìn)程的線程共享頁表涂召，因此上下文切換的開銷一般只有：

• 保存各種寄存器
• 切換sp(call指令會自動將pc壓棧)

可以在數(shù)十條指令內(nèi)完成坠非。

開銷

既然近內(nèi)核以及上下文切換都不慢，那么多線程的開銷究竟在哪芹扭？

我們不妨看一個阻塞的系統(tǒng)調(diào)用futex的熱點分布：

image

可以看到上面的熱點中有大量涉及調(diào)度的開銷麻顶。我們來看過程：

1. 調(diào)用系統(tǒng)調(diào)用(可能需要阻塞)；
2. 系統(tǒng)調(diào)用確實需要阻塞舱卡，kernel需要決定下一個被執(zhí)行的線程(調(diào)度)辅肾；
3. 執(zhí)行上下切換。

因此轮锥，上面2個誤區(qū)與多線程的開銷都有一定因果關(guān)系矫钓，但是真正的開銷來源于線程阻塞喚醒調(diào)度。

綜上舍杜，希望通過線程模型來提升web server性能的原則是：

1. 活躍線程數(shù)約等于CPU個數(shù)
2. 每個線程不太需要阻塞

文章后續(xù)將緊緊圍繞這兩個主題新娜。

為了滿足上述兩個條件，使用eventloop+異步callback的方式是一個極佳的選擇既绩。

異步與協(xié)程的關(guān)系

為了保持簡潔概龄，我們以一個異步服務(wù)器上的Netty寫操作為例子(寫操作也存在阻塞的可能)：

private void writeQuery(Channel ch) {
  ch.write(Unpooled.wrappedBuffer("query".getBytes())).sync();
  logger.info("write finish");
}

這里的sync()會阻塞線程。不滿足期望饲握。由于netty本身是一個異步框架私杜，我們引入回調(diào)：

private void writeQuery(Channel ch) {
  ch.write(Unpooled.wrappedBuffer("query".getBytes()))
    .addListener(f -> {
      logger.info("write finish");
    });
}

注意這里異步的write調(diào)用后，writeQuery會返回救欧。因此假如邏輯上要求在write后執(zhí)行的代碼衰粹，必須出現(xiàn)在回調(diào)里，write是函數(shù)的最后一行笆怠。這里是最簡單的情形铝耻，如果函數(shù)有其他調(diào)用者，那么就需要用CPS變換蹬刷。

需要不斷的提取程序的"下半部分"瓢捉，即continuation，似乎對我們造成一些心智負(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")
}

這里引入了一個魔法suspendCoroutine泊柬，我們可以獲得當(dāng)前Continuation的引用，并執(zhí)行一段代碼诈火，最后掛起當(dāng)前協(xié)程。Continuation代表了當(dāng)前計算的延續(xù)，通過Continuation.resume()我們可以恢復(fù)執(zhí)行上下文冷守。因此只需在寫操作完成時回調(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í)行，因此不會真正阻塞混卵，我們因此獲得了性能提升映穗。

從這里看，只需要我們有一個機制來保存/恢復(fù)執(zhí)行上下文幕随，并且在阻塞庫函數(shù)里采用非阻塞+回調(diào)的方式讓出/恢復(fù)協(xié)程蚁滋，就可以使得以同步形式編寫的程序達(dá)到和異步同樣的效果了。

理論上只要有一個庫包裝了所有JDK阻塞方法赘淮，我們就可以暢快地編寫異步程序了辕录。改寫的阻塞庫函數(shù)本身需要足夠地通用流行，才能被大部分程序使用起來梢卸。據(jù)我所知走诞，vert.x的kotlin支持已經(jīng)做了這樣的封裝。

雖然vert.x很流行蛤高，但是無法兼顧遺留代碼以及代碼中的鎖阻塞等邏輯蚣旱。因此不能算是最通用的選擇。實際上Java程序有一個繞不過的庫——JDK襟齿。Wisp就是在JDK里所有的阻塞調(diào)用出進(jìn)行了非阻塞+事件恢復(fù)協(xié)程的方式支持了協(xié)程調(diào)度姻锁，在為用戶帶來最大便利的同時，兼顧了現(xiàn)有代碼的兼容性猜欺。

上述方式支持了位隶，每個線程不太需要阻塞，Wisp在Thread.start()處开皿，將線程轉(zhuǎn)成成了協(xié)程涧黄，來達(dá)到了另一目的: 活躍線程數(shù)約等于CPU個數(shù)。因此只需要使用Wisp協(xié)程赋荆，所有現(xiàn)有的Java多線程代碼都可以獲得異步的性能笋妥。

手工異步/Wisp性能比較

對于基于傳統(tǒng)的編程模型的應(yīng)用，考慮到邏輯清晰性窄潭、異常處理的便利性春宣、現(xiàn)有庫的兼容性，改造成異步成本巨大。使用Wisp相較于異步編程優(yōu)勢明顯月帝。

下面我們在只考慮性能的新應(yīng)用的前提下分析技術(shù)的選擇躏惋。

基于現(xiàn)有組件寫新應(yīng)用

如果要新寫一個應(yīng)用我們通常會依賴JDBC、Dubbo嚷辅、Jedis這樣的常用協(xié)議/組件簿姨，假如庫的內(nèi)部使用了阻塞形式，并且沒有暴露回調(diào)接口簸搞，那么我們就沒法基于這些庫來寫異步應(yīng)用了(除非包裝線程池扁位，但是本末倒置了)。下面假設(shè)我們依賴的所有庫都有回調(diào)支持趁俊，比如dubbo域仇。

1）假設(shè)我們使用Netty接受請求，我們稱之為入口eventLoop则酝，收到請求可以在Netty的handler里處理殉簸，也可以為了io的實時性使用業(yè)務(wù)線程池。

2）假設(shè)請求處理期間需要調(diào)用dubbo沽讹，因為dubbo不是我們寫的般卑，因此內(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）為了完成對客戶端的響應(yīng)最終總是要由入口的eventloop來寫回響應(yīng)叹谁。

我們可以看到由于這種封裝導(dǎo)致的eventLoop的割裂，即便完全使用回調(diào)的形式乘盖，我們處理請求時多多少少要在多個eventLoop/線程池之間傳遞焰檩，而每個線程又都沒法跑到一個較滿的程度，導(dǎo)致頻繁地進(jìn)入os調(diào)度订框。與上述的每個線程不太需要阻塞原則相違背疆拘。因此雖然減少了線程數(shù)床牧，節(jié)約了內(nèi)存，但是我們得到的性能收益變得很有限。

完全從零開始開發(fā)

對于一個功能有限的新應(yīng)用(比如nginx只支持http和mail協(xié)議)來說我們可以不依賴現(xiàn)有的組件來重新寫應(yīng)用蹬屹。比如我們可以基于Netty寫一個數(shù)據(jù)庫代理服務(wù)器及汉，與客戶端的連接以及與真正后端數(shù)據(jù)庫的連接共享同一個eventloop霹琼。

這樣精確控制線程模型的應(yīng)用通陈贩可以獲得很好的性能，通常性能是可以高于通過非異步程序轉(zhuǎn)協(xié)程的履羞，原因如下：

• 線程控制更加精確：舉個例子峦萎，比如我們可以控制代理的客戶端和后端連接都綁定在同一個netty線程屡久，所有的操作都可以threadLocal化
• 沒有協(xié)程的runtime和調(diào)度開銷(1%左右)

但是使用協(xié)程依舊有一個優(yōu)勢：對于jdk中無處不在的synchronized塊，wisp可以正確地切換調(diào)度骨杂。

適應(yīng)的Workload

基于上述的背景涂身，我們已經(jīng)知道Wisp或者其他各種協(xié)程是適用于IO密集Java程序設(shè)計的。否則線程沒有任何切換搓蚪，只需要盡情地在CPU上跑，OS也不需要過多的干預(yù)丁鹉，這是比較偏向于離線或者科學(xué)計算的場景妒潭。

在線應(yīng)用通常需要訪問RPC、DB揣钦、cache雳灾、消息，并且是阻塞的冯凹，十分適合使用Wisp來提升性能谎亩。

最早的Wisp1也是對這些場景進(jìn)行了深度定制，比如hsf接受的請求處理是會自動用協(xié)程取代線程池宇姚，將IO線程數(shù)量設(shè)置成1個后使用epoll_wait(1ms)來代替selector.wakeup()匈庭，等等。因此我們經(jīng)常受到的一個挑戰(zhàn)是Wisp是否只適合阿里內(nèi)部的workload浑劳？

• 對于Wisp1是這樣的阱持，接入的應(yīng)用的參數(shù)以及Wisp的實現(xiàn)做了深度的適配。
• 對于Wisp2魔熏，會將所有線程轉(zhuǎn)換成協(xié)程衷咽，已經(jīng)無需任何適配了。

為了證明這一點蒜绽，我們使用了web領(lǐng)域最權(quán)威的techempower benchmak集來驗證镶骗，我們選擇了com.sun.net.httpserver、Servlet等常見的阻塞型的測試(性能不是最好躲雅，但是最貼近普通用戶鼎姊，同時具備一定的提升空間)來驗證Wisp2在常見開源組件下的性能，可以看到在高壓力下qps/RT會有10%~20%的優(yōu)化吏夯。

Project Loom

Project Loom作為OpenJDK上的標(biāo)準(zhǔn)協(xié)程實現(xiàn)很值得關(guān)注此蜈，作為java開發(fā)者我們是否應(yīng)該擁抱Loom呢？

我們首先對Wisp和Loom這里進(jìn)行一些比較：

1）Loom使用序列化的方式保存上下文噪生，更省內(nèi)存裆赵，但是切換效率低。

2）Wisp采用獨立棧的方式跺嗽，這點和go類似战授。協(xié)程切換只需切換寄存器页藻，效率高但是耗內(nèi)存。

3）Loom不支持ObectMonitor植兰，Wisp支持份帐。

• synchronized/Object.wait()將占用線程，無法充分利用CPU楣导。
• 還可能產(chǎn)生死鎖废境，以Wisp的經(jīng)驗來說是一定會產(chǎn)生死鎖(Wisp也是后來陸續(xù)支持ObectMonitor的)。

4）Wisp支持在棧上有native函數(shù)時切換(反射等等)筒繁，Loom不支持噩凹。

• 對dubbo這樣的框架不友好，棧底下幾乎都帶有反射毡咏。

總根據(jù)我們的判斷驮宴，Loom至少還要2年時間才能到達(dá)一個穩(wěn)定并且功能完善的狀態(tài)。Wisp的性能優(yōu)秀呕缭，功能要完整很多堵泽，產(chǎn)品本身也要成熟很多。Loom作為Oracle項目很有機會進(jìn)入Java標(biāo)準(zhǔn)恢总，我們也在積極地參與社區(qū)迎罗，希望能將Wisp的一些功能實現(xiàn)貢獻(xiàn)進(jìn)社區(qū)。

同時Wisp目前完全兼容Loom的Fiber API离熏，假如我們的用戶基于Fiber API來編程佳谦，我們可以保證代碼的行為在Loom和Wisp上表現(xiàn)完全一致。

FAQ

協(xié)程也有調(diào)度滋戳，為什么開銷凶昝铩？

我們一直強調(diào)了協(xié)程適用于IO密集的場景奸鸯，這就意味了通常任務(wù)執(zhí)行一小段時間就會阻塞等待IO咪笑，隨后進(jìn)行調(diào)度。這種情況下只要系統(tǒng)的CPU沒有完全打滿娄涩，使用簡單的先進(jìn)先出調(diào)度策略基本都能保證一個比較公平的調(diào)度窗怒。同時，我們使用了完全無鎖的調(diào)度實現(xiàn)蓄拣，使得調(diào)度開銷相對內(nèi)核大大減少扬虚。

Wisp2為什么不使用ForkJoinPool來調(diào)度協(xié)程？

ForkJoinPool本身十分優(yōu)秀球恤，但是不太適合Wisp2的場景辜昵。

為了便于理解，我們可以將一次協(xié)程喚醒看到做一個Executor.execute()操作咽斧，F(xiàn)orkJoinPool雖然支持任務(wù)竊取堪置，但是execute()操作是隨機或者本線程隊列操作(取決于是否異步模式)的躬存，這將導(dǎo)致協(xié)程在哪個線程被喚醒的行為也很隨機。

在Wisp底層舀锨，一次steal的代價是有點大的岭洲，因此我們需要一個affinity，讓協(xié)程盡量保持綁定在固定線程坎匿，只有線程忙的情況下才發(fā)生workstealing盾剩。我們實現(xiàn)了自己的workStealingPool來支持這個特性。從調(diào)度開銷/延遲等各項指標(biāo)來看替蔬，基本能和ForkJoinPool打平彪腔。

還有一個方面是為了支持類似go的M和P機制，我們需要將被協(xié)程阻塞的線程踢出調(diào)度器进栽，這些功能都不適宜改在ForkJoinPool里。

如何看待Reactive編程恭垦？

Reactive編程模型已經(jīng)被業(yè)界廣泛接受快毛，是一種重要的技術(shù)方向；同時Java代碼里的阻塞也很難完全避免番挺。我們認(rèn)為協(xié)程可以作為一種底層worker機制來支持Reactive編程唠帝，即保留了Reactive編程模型，也不用太擔(dān)心用戶代碼的阻塞導(dǎo)致了整個系統(tǒng)阻塞玄柏。

這里是Ron Pressler最近的一次演講襟衰，作為Quasar和Loom的作者，他的觀點鮮明地指出了回調(diào)模型會給目前的編程帶來很多挑戰(zhàn) 粪摘。

Wisp經(jīng)歷了4年的研發(fā)瀑晒，我將其分為幾個階段：

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來實現(xiàn)阻塞前調(diào)度的三娩，如果是用戶自定義的JNI則沒有機會hook庵芭。

最常見的場景就是使用了Netty的EpollEventLoop：

1）螞蟻的bolt組件默認(rèn)開啟了這個特點，可以通過-Dbolt.netty.epoll.switch=false 來關(guān)閉雀监，對性能的影響不大双吆。

2）也可以使用-Dio.netty.noUnsafe=true , 其他unsafe功能可能會受影響。

3）(推薦) 對于netty 4.1.25以上会前，支持了通過-Dio.netty.transport.noNative=true 來僅關(guān)閉jni epoll好乐，參見358249e5

作者：阿里云云棲號
鏈接：http://www.reibang.com/p/26f9a370d020