Go語言出現後，Java仍是最佳選擇嗎？

阿里妹導讀：隨着大量新生的異步框架和支持協程的語言(如Go)的出現，在不少場景下操做系統的線程調度成爲了性能的瓶頸，Java也所以被質疑是否再也不適應最新的雲場景了。4年前，阿里JVM團隊開始自研Wisp2，將Go語言的協程能力帶入到Java世界。既享受Java的豐富生態，又得到異步程序的性能，Wisp2讓Java平臺歷久彌新。

Java平臺一直以生態的繁榮著稱，大量的類庫、框架幫助開發者們快速搭建應用。而其中大部分Java框架類庫都是基於線程池以及阻塞機制來服務併發的，主要緣由包括：

1. Java語言在覈心類庫中提供了強大的併發能力，多線程應用能夠得到不俗的性能；
2. Java EE的一些標準都是線程級阻塞的(好比JDBC)；
3. 基於阻塞模式能夠快速地開發應用。

但現在，大量新生的異步框架和支持協程的語言(如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的熱點分佈：

能夠看到上面的熱點中有大量涉及調度的開銷。咱們來看過程：

1. 調用系統調用(可能須要阻塞)；
2. 系統調用確實須要阻塞，kernel須要決定下一個被執行的線程(調度)；
3. 執行上下切換。

所以，上面2個誤區與多線程的開銷都有必定因果關係，可是真正的開銷來源於線程阻塞喚醒調度。

綜上，但願經過線程模型來提高web server性能的原則是：

1. 活躍線程數約等於CPU個數
2. 每一個線程不太須要阻塞

文章後續將牢牢圍繞這兩個主題。

爲了知足上述兩個條件，使用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

阿里雲雙11億元補貼提早領，進入抽取iPhone 11 Pro：https://www.aliyun.com/1111/2...

---

本文做者： 梁希

閱讀原文

本文來自雲棲社區合做夥伴「阿里技術」，如需轉載請聯繫原做者。