深入分析 Java、Kotlin、Go 的線程和協程 前言 進程 線程 協程 Java、Kotlin、Go 的線程與協程 總結 參考資料 代碼

• 前言
  • 協程是什麼
  • 協程的好處
• 進程
  • 進程是什麼
  • 進程組成
  • 進程特徵
• 線程
  • 線程是什麼
  • 線程組成
  • 任務調度
  • 進程與線程的區別
  • 線程的實現模型
    • 一對一模型
    • 多對一模型
    • 多對多模型
  • 線程的“併發”
• 協程
  • 協程的目的
  • 協程的特點
  • 協程的原理
• Java、Kotlin、Go 的線程與協程
  • Kotlin 的協程
    • 使用「線程」的代碼
    • 使用「協程」的代碼
  • Go 的協程
  • Java 的 Kilim 協程框架
  • Java 的 Project Loom
    • 使用 Fiber
• 總結
• 參考資料

前言

Go 語言比 Java 語言性能優越的一個原因，就是輕量級線程Goroutines（協程Coroutine）。本篇文章深入分析下 Java 的線程和 Go 的協程。

協程是什麼

協程並不是 Go 提出來的新概念，其他的一些編程語言，例如：Go、Python 等都可以在語言層面上實現協程，甚至是 Java，也可以通過使用擴展庫來間接地支持協程。

當在網上搜索協程時，我們會看到：

• Kotlin 官方文檔說「本質上，協程是輕量級的線程」。
• 很多博客提到「不需要從用戶態切換到內核態」、「是協作式的」等等。

「協程 Coroutines」源自 Simula 和 Modula-2 語言，這個術語早在 1958 年就被 Melvin Edward Conway 發明並用於構建彙編程序，說明協程是一種編程思想，並不侷限於特定的語言。

協程的好處

性能比 Java 好很多，甚至代碼實現都比 Java 要簡潔很多。

那這究竟又是爲什麼呢？下面一一分析。

說明：下面關於進程和線程的部分，幾乎完全參考自：https://www.cnblogs.com/Survivalist/p/11527949.html，這篇文章寫得太好了~~~

進程

進程是什麼

計算機的核心是 CPU，執行所有的計算任務；操作系統負責任務的調度、資源的分配和管理；應用程序是具有某種功能的程序，程序是運行在操作系統上的。

進程是一個具有一定獨立功能的程序在一個數據集上的一次動態執行的過程，是操作系統進行資源分配和調度的一個獨立單位，是應用程序運行的載體。

進程組成

進程由三部分組成：

• 程序：描述進程要完成的功能，是控制進程執行的指令集。
• 數據集合：程序在執行時所需要的數據和工作區。
• 進程控制塊：(Program Control Block，簡稱PCB)，包含進程的描述信息和控制信息，是進程存在的唯一標誌。

進程特徵

• 動態性：進程是程序的一次執行過程，是臨時的，有生命期的，是動態產生，動態消亡的。
• 併發性：任何進程都可以同其他進程一起併發執行。
• 獨立性：進程是系統進行資源分配和調度的一個獨立單位。
• 結構性：進程由程序、數據和進程控制塊三部分組成。

線程

線程是什麼

線程是程序執行中一個單一的順序控制流程，是程序執行流的最小單元，是處理器調度和分派的基本單位。一個進程可以有一個或多個線程，各個線程之間共享程序的內存空間(也就是所在進程的內存空間)。

線程組成

• 線程ID、當前指令指針(PC)
• 寄存器
• 堆棧

任務調度

大部分操作系統(如Windows、Linux)的任務調度是採用時間片輪轉的搶佔式調度方式。

在一個進程中，當一個線程任務執行幾毫秒後，會由操作系統的內核（負責管理各個任務）進行調度，通過硬件的計數器中斷處理器，讓該線程強制暫停並將該線程的寄存器放入內存中，通過查看線程列表決定接下來執行哪一個線程，並從內存中恢復該線程的寄存器，最後恢復該線程的執行，從而去執行下一個任務。

進程與線程的區別

• 線程是程序執行的最小單位，而進程是操作系統分配資源的最小單位；
• 一個進程由一個或多個線程組成，線程是一個進程中代碼的不同執行路線；
• 進程之間相互獨立，但同一進程下的各個線程之間共享程序的內存空間(包括代碼段、數據集、堆等)及一些進程級的資源(如打開文件和信號)，某進程內的線程在其它進程不可見；
• 調度和切換：線程上下文切換比進程上下文切換要快得多。

線程的實現模型

程序一般不會直接去使用內核線程，而是去使用內核線程的一種高級接口——輕量級進程（Lightweight Process，LWP），輕量級進程就是我們通常意義上所講的線程，也被叫做用戶線程。

一對一模型

一個用戶線程對應一個內核線程，如果是多核的 CPU，那麼線程之間是真正的併發。

缺點：

• 內核線程的數量有限，一對一模型使用的用戶線程數量有限制。
• 內核線程的調度，上下文切換的開銷較大（雖然沒有進程上下文切換的開銷大），導致用戶線程的執行效率下降。

多對一模型

多個用戶線程映射到一個內核線程上，線程間的切換由用戶態的代碼來進行。用戶線程的建立、同步、銷燬都是在用戶態中完成，不需要內核的介入。因此多對一的上下文切換速度快很多，且用戶線程的數量幾乎沒有限制。

缺點：

• 若一個用戶線程阻塞，其他所有線程都無法執行，此時內核線程處於阻塞狀態。
• 處理器數量的增加，不會對多對一模型的線程性能造成影響，因爲所有的用戶線程都映射到了一個處理器上。

多對多模型

結合了一對一模型和多對一模型的優點，多個用戶線程映射到多個內核線程上，由線程庫負責在可用的可調度實體上調度用戶線程。這樣線程間的上下文切換很快，因爲它避免了系統調用。但是增加了系統的複雜性。

優點：

• 一個用戶線程的阻塞不會導致所有線程的阻塞，因爲此時還有別的內核線程被調度來執行；
• 多對多模型對用戶線程的數量沒有限制；
• 在多處理器的操作系統中，多對多模型的線程也能得到一定的性能提升，但提升的幅度不如一對一模型的高。

線程的“併發”

只有在線程的數量 < 處理器的數量時，線程的併發纔是真正的併發，這時不同的線程運行在不同的處理器上。但是當線程的數量 > 處理器的數量時，會出現一個處理器運行多個線程的情況。

在單個處理器運行多個線程時，併發是一種模擬出來的狀態。操作系統採用時間片輪轉的方式輪流執行每一個線程。現在，幾乎所有的現代操作系統採用的都是時間片輪轉的搶佔式調度方式。

協程

當在網上搜索協程時，我們會看到：

• 本質上，協程是輕量級的線程。
• 很多博客提到「不需要從用戶態切換到內核態」、「是協作式的」。

協程也並不是 Go 提出來的，協程是一種編程思想，並不侷限於特定的語言。Go、Python、Kotlin 都可以在語言層面上實現協程，Java 也可以通過擴展庫的方式間接支持協程。

協程比線程更加輕量級，可以由程序員自己管理的輕量級線程，對內核不可見。

協程的目的

在傳統的 J2EE 系統中都是基於每個請求佔用一個線程去完成完整的業務邏輯（包括事務）。所以系統的吞吐能力取決於每個線程的操作耗時。如果遇到很耗時的 I/O 行爲，則整個系統的吞吐立刻下降，因爲這個時候線程一直處於阻塞狀態，如果線程很多的時候，會存在很多線程處於空閒狀態（等待該線程執行完才能執行），造成了資源應用不徹底。

最常見的例子就是 JDBC（它是同步阻塞的），這也是爲什麼很多人都說數據庫是瓶頸的原因。這裏的耗時其實是讓 CPU 一直在等待 I/O 返回，說白了線程根本沒有利用 CPU 去做運算，而是處於空轉狀態。而另外過多的線程，也會帶來更多的 ContextSwitch 開銷。

對於上述問題，現階段行業裏的比較流行的解決方案之一就是單線程加上異步回調。其代表派是 node.js 以及 Java 裏的新秀 Vert.x。

而協程的目的就是當出現長時間的 I/O 操作時，通過讓出目前的協程調度，執行下一個任務的方式，來消除 ContextSwitch 上的開銷。

協程的特點

• 線程的切換由操作系統負責調度，協程由用戶自己進行調度，減少了上下文切換，提高了效率
• 線程的默認 Stack 是1M，協程更加輕量，是 1K，在相同內存中可以開啓更多的協程。
• 由於在同一個線程上，因此可以避免競爭關係而使用鎖。
• 適用於被阻塞的，且需要大量併發的場景。但不適用於大量計算的多線程，遇到此種情況，更好用線程去解決。

協程的原理

當出現IO阻塞的時候，由協程的調度器進行調度，通過將數據流立刻yield掉（主動讓出），並且記錄當前棧上的數據，阻塞完後立刻再通過線程恢復棧，並把阻塞的結果放到這個線程上去跑，這樣看上去好像跟寫同步代碼沒有任何差別，這整個流程可以稱爲coroutine，而跑在由coroutine負責調度的線程稱爲Fiber。比如Golang裏的 go關鍵字其實就是負責開啓一個Fiber，讓func邏輯跑在上面。

由於協程的暫停完全由程序控制，發生在用戶態上；而線程的阻塞狀態是由操作系統內核來進行切換，發生在內核態上。
因此，協程的開銷遠遠小於線程的開銷，也就沒有了 ContextSwitch 上的開銷。

假設程序中默認創建兩個線程爲協程使用，在主線程中創建協程ABCD…，分別存儲在就緒隊列中，調度器首先會分配一個工作線程A執行協程A，另外一個工作線程B執行協程B，其它創建的協程將會放在隊列中進行排隊等待。

當協程A調用暫停方法或被阻塞時，協程A會進入到掛起隊列，調度器會調用等待隊列中的其它協程搶佔線程A執行。當協程A被喚醒時，它需要重新進入到就緒隊列中，通過調度器搶佔線程，如果搶佔成功，就繼續執行協程A，失敗則繼續等待搶佔線程。

Java、Kotlin、Go 的線程與協程

Java 在 Linux 操作系統下使用的是用戶線程+輕量級線程，一個用戶線程映射到一個內核線程，線程之間的切換就涉及到了上下文切換。所以在 Java 中並不適合創建大量的線程，否則效率會很低。可以先看下 Kotlin 和 Go 的協程：

Kotlin 的協程

Kotlin 在誕生之初，目標就是完全兼容 Java，卻是一門非常務實的語言，其中一個特性，就是支持協程。

但是 Kotlin 最終還是運行在 JVM 中的，目前的 JVM 並不支持協程，Kotlin 作爲一門編程語言，也只是能在語言層面支持協程。Kotlin 的協程是用於異步編程等場景的，在語言級提供協程支持，而將大部分功能委託給庫。

使用「線程」的代碼

@Test
fun testThread() {
    // 執行時間 1min+
    val c = AtomicLong()
    for (i in 1..1_000_000L)
        thread(start = true) {
            c.addAndGet(i)
        }
    println(c.get())
}

上述代碼創建了 100 萬個線程，在每個線程裏僅僅調用了 add 操作，但是由於創建線程太多，這個測試用例在我的機器上要跑 1 分鐘左右。

使用「協程」的代碼

@Test
fun testLaunch() {
    val c = AtomicLong()
    runBlocking {
        for (i in 1..1_000_000L)
            launch {
                c.addAndGet(workload(i))
            }
    }
    print(c.get())
}

suspend fun workload(n: Long): Long {
    delay(1000)
    return n
}

這段代碼是創建了 100 萬個協程，測試用例在我的機器上執行時間大概是 10 秒鐘。而且這段代碼的每個協程都 delay 了 1 秒鐘，執行效率仍然遠遠高於線程。

詳細的語法可以查看 Kotlin 的官方網站：https://www.kotlincn.net/docs/reference/coroutines/basics.html

其中關鍵字 launch 是開啓了一個協程，關鍵字 suspend 是掛起一個協程，而不會阻塞。現在在看這個流程，應該就懂了~

Go 的協程

官方例程：https://gobyexample-cn.github.io/goroutines

go語言層面並不支持多進程或多線程，但是協程更好用，協程被稱爲用戶態線程，不存在CPU上下文切換問題，效率非常高。下面是一個簡單的協程演示代碼：

package main

func main() {
    go say("Hello World")
}

func say(s string) {
    println(s)
}

Java 的 Kilim 協程框架

目前 Java 原生語言暫時不支持協程，可以使用 kilim，具體原理可以看官方文檔，暫時還沒有研究~

Java 的 Project Loom

Java 也在逐步支持協程，其項目就是 Project Loom(https://openjdk.java.net/projects/loom/)。這個項目在18年底的時候已經達到可初步演示的原型階段。不同於之前的方案，Project Loom 是從 JVM 層面對多線程技術進行徹底的改變。

官方介紹：
http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html

其中一段介紹了爲什麼引入這個項目：

One of Java's most important contributions when it was first released, over twenty years ago, was the easy access to threads and synchronization primitives. Java threads (either used directly, or indirectly through, for example, Java servlets processing HTTP requests) provided a relatively simple abstraction for writing concurrent applications. These days, however, one of the main difficulties in writing concurrent programs that meet today's requirements is that the software unit of concurrency offered by the runtime — the thread — cannot match the scale of the domain's unit of concurrency, be it a user, a transaction or even a single operation. Even if the unit of application concurrency is coarse — say, a session, represented by single socket connection — a server can handle upward of a million concurrent open sockets, yet the Java runtime, which uses the operating system's threads for its implementation of Java threads, cannot efficiently handle more than a few thousand. A mismatch in several orders of magnitude has a big impact.

文章大意就是本文上面所說的，Java 的用戶線程與內核線程是一對一的關係，一個 Java 進程很難創建上千個線程，如果是對於 I/O 阻塞的程序（例如數據庫讀取/Web服務），性能會很低下，所以要採用類似於協程的機制。

使用 Fiber

在引入 Project Loom 之後，JDK 將引入一個新類：java.lang.Fiber。此類與 java.lang.Thread 一起，都成爲了 java.lang.Strand 的子類。即線程變成了一個虛擬的概念，有兩種實現方法：Fiber 所表示的輕量線程和 Thread 所表示的傳統的重量級線程。

Fiber f = Fiber.schedule(() -> {
  println("Hello 1");
  lock.lock(); // 等待鎖不會掛起線程
  try {
      println("Hello 2");
  } finally {
      lock.unlock();
  }
  println("Hello 3");
})

只需執行 Fiber.schedule(Runnable task) 就能在 Fiber 中執行任務。最重要的是，上面例子中的 lock.lock() 操作將不再掛起底層線程。除了 Lock 不再掛起線程以外，像 Socket BIO 操作也不再掛起線程。 但 synchronized，以及 Native 方法中線程掛起操作無法避免。

總結

協程大法好，比線程更輕量級，但是僅針對 I/O 阻塞纔有效；對於 CPU 密集型的應用，因爲 CPU 一直都在計算並沒有什麼空閒，所以沒有什麼作用。

Kotlin 兼容 Java，在編譯器、語言層面實現了協程，JVM 底層並不支持協程；Go 天生就是支持協程的，不支持多進程和多線程。Java 的 Project Loom 項目支持協程，

參考資料

• 極客時間-Java性能調優實戰/19.如何用協程來優化多線程業務？
• https://www.cnblogs.com/Survivalist/p/11527949.html
• https://www.jianshu.com/p/5db701a764cb

代碼

代碼和思維導圖在 GitHub 項目中，歡迎大家 star！