java協程框架quasar和kotlin中的協程對比分析

2022-02-24 22:00:26

前言

早就聽說Go語言開發的服務不用任何架構優化，就可以輕鬆實現百萬級別的qps。這得益於Go語言級別的協程的處理效率。協程不同於執行緒，執行緒是作業系統級別的資源，建立執行緒，排程執行緒，銷燬執行緒都是重量級別的操作。而且執行緒的資源有限，在java中大量的不加限制的建立執行緒非常容易將系統搞垮。接下來要分享的這個開源專案，正是解決了在java中只能使用多執行緒模型開發高並行應用的窘境，使得java也能像Go語言那樣使用協程的語意開發了。

quasar專案地址：https://github.com/puniverse/quasar
quasar周邊專案地址：https://github.com/puniverse/comsat

快速體驗

新增依賴

<dependency>
            <groupId>co.paralleluniverse</groupId>
            <artifactId>quasar-core</artifactId>
            <version>0.7.10</version>
</dependency>

注意：目前quasar最高的版本是0.8.0，但是最高版本的只支援jdk11以上

新增java agent

quasar的實現原理是在java載入class前，通過jdk的instrument機制使用asm來修改目標class的位元組碼來實現的，他標記了協程程式碼的起始和結束的位置，以及方法需要暫停的位置，每個協程任務統一由FiberScheduler去排程，內部維護了一個或多個ForkJoinPool範例。所以，在執行應用前，需要設定好quasar-core的java agent地址，在vm引數上加上如下指令碼即可：

-javaagent:D:.m2repositorycoparalleluniversequasar-core.7.10quasar-core-0.7.10.jar

執行緒VS協程

下面模擬呼叫某個遠端的服務，假設遠端服務處理耗時需要1S，這裡使用執行阻塞1S來模擬，分別看多執行緒模型和協程模型呼叫這個服務10000次所需的耗時

協程程式碼

public static void main(String[] args) throws Exception{
        CountDownLatch count  = new CountDownLatch(10000);
        StopWatch stopWatch = new StopWatch();stopWatch.start();
        IntStream.range(0,10000).forEach(i-> new Fiber() {
            @Override
            protected String run() throws SuspendExecution, InterruptedException {
                Strand.sleep(1000 );
                count.countDown();
                return  "aa";
            }
        }.start());
        count.await();stopWatch.stop();
        System.out.println("結束了: " + stopWatch.prettyPrint());
    }

耗時情況：

多執行緒程式碼

public static void main(String[] args) throws Exception{
        CountDownLatch count  = new CountDownLatch(10000);
        StopWatch stopWatch = new StopWatch();stopWatch.start();
        ExecutorService executorService = Executors.newCachedThreadPool();
        IntStream.range(0,10000).forEach(i-> executorService.submit(() -> {
            try {
                TimeUnit.SECONDS.sleep(1);
            } catch (InterruptedException ex) { }
            count.countDown();
        }));
        count.await();stopWatch.stop();
        System.out.println("結束了: " + stopWatch.prettyPrint());
    }

耗時情況

協程完勝

可以看到上面的結果，在對比存取一個耗時1s的服務10000次時，協程只需要2秒多，而多執行緒模型需要4秒多，時效相差了一倍。而且上面多執行緒程式設計時，並沒有指定執行緒池的大小，在實際開發中是絕不允許的。一般我們會設定一個固定大小的執行緒池，因為執行緒資源是寶貴，執行緒多了費記憶體還會帶來執行緒切換的開銷。上面的場景在設定200個固定大小執行緒池時。結果也是可預見的達到了50多秒。這個結果足以證明協程程式設計ko執行緒程式設計了。而且在qps越大時，執行緒處理的效率和協程的差距就約明顯，縮小差距的唯一方式就是增加執行緒數，而這帶來的影響就是記憶體消耗激增。而反觀協程，基於固定的幾個執行緒排程，可以輕鬆實現百萬級的協程處理，而且記憶體穩穩的。

後記

最後，博主以為Quasar只是一個框架層面的東西，所以就又去看了下同樣是jvm語言的kotlin的協程。他的語言更簡潔，可以直接和java混合使用。跑上面這種範例只需要1秒多。

fun main() {
    val count = CountDownLatch(10000)
    val stopWatch = StopWatch()
    stopWatch.start()
    IntStream.range(0,10000).forEach {
        GlobalScope.launch {
            delay(1000L)
            println(Thread.currentThread().name + "->"+ it)
            count.countDown()
        }
    }
    count.await()
    stopWatch.stop()
    println("結束了: " + stopWatch.prettyPrint())
}

當博主看到這個結果的時候，有種震驚的趕腳，kotlin的同步模型牛逼呀，瞬時感覺到發現了java裡的騷操作了，可以使用kotlin的協程來代替java中的多執行緒操作。因為他們兩個混合開發毫無壓力。如果行的通，那就太爽了。所以就有下面這個kotlin協程實現的程式碼：

@Service
class KotlinAsyncService(private val weatherService: GetWeatherService,private val demoApplication: DemoApplication){
    val weatherUrl = "http://localhost:8080/demo/mockWeatherApi?city="
    fun getHuNanWeather(): JSONObject{
        val result = JSONObject()
        val count = CountDownLatch(demoApplication.weatherContext.size)
        for (city in demoApplication.weatherContext){
            val url = weatherUrl + city.key
            GlobalScope.launch {
                result[city.key.toString()] = weatherService.get(url)
                count.countDown()
            }
        }
        count.await()
        return result
    }
}

現實是，當我使用協程替換掉我java多執行緒寫的一個多執行緒匯聚多個http介面的結果的介面時，通過ab壓測他們兩個的效能並沒有很大的變化，最後瞭解到主要原因是這個時候，在協程裡發起一個http的請求時，涉及到作業系統層面的socket io操作，io操作是阻塞的，協程的並行也就變成了排程協程的幾個執行緒的並行了。而且當我把同樣的程式碼放到Quasar中的時候，Quasar直接拋io異常了，說明Quasar還並不能輕鬆支援這個場景。那為什麼上面的測試結果差距這麼大呢，是因為我錯誤的把協程實現裡的阻塞等同於執行緒的阻塞。協程裡的delay掛起函數，會立馬釋放執行緒到執行緒池，但是當真正的io阻塞的時候也就和真正的執行緒sleep一樣了，並沒有釋放當前的執行緒。所以這些對比都沒有太大的意義

以上就是java協程框架quasar和kotlin中的協程對比分析的詳細內容，更多關於java框架quasar和kotlin協程對比的資料請關注it145.com其它相關文章！