目錄：

一、多線程概念

並發與並行

進程與線程

二. 並發編程的挑戰

上下文切換

死鎖

資源限制的挑戰

一、多線程概念

1. 並發與並行

「並發」指的是程序的結構，「並行」指的是程序運行時的狀態

即使不看詳細解釋，也請記住這句話。下面來具體說說：

並行（parallelism）

這個概念很好理解。所謂並行，就是同時執行的意思，無需過度解讀。判斷程序是否處於並行的狀態，就看同一時刻是否有超過一個「工作單位」在運行就好了。所以，單線程永遠無法達到並行狀態。

要達到並行狀態，最簡單的就是利用多線程和多進程。但是 Python 的多線程由於存在著名的 GIL，無法讓兩個線程真正「同時運行」，所以實際上是無法到達並行狀態的。

並發（concurrency）

要理解「並發」這個概念，必須得清楚，並發指的是程序的「結構」。當我們說這個程序是並發的，實際上，這句話應當表述成「這個程序採用了支持並發的設計」。好，既然並發指的是人為設計的結構，那麼怎樣的程序結構才叫做支持並發的設計？

正確的並發設計的標準是：使多個操作可以在重疊的時間段內進行

(two tasks can start, run, and complete in overlapping time periods)。

這句話的重點有兩個。我們先看「（操作）在重疊的時間段內進行」這個概念。它是否就是我們前面說到的並行呢？是，也不是。並行，當然是在重疊的時間段內執行，但是另外一種執行模式，也屬於在重疊時間段內進行。這就是協程。

使用協程時，程序的執行看起來往往是這個樣子：

task1, task2 是兩段不同的代碼，比如兩個函數，其中黑色塊代表某段代碼正在執行。注意，這裡從始至終，在任何一個時間點上都只有一段代碼在執行，但是，由於 task1 和 task2 在重疊的時間段內執行，所以這是一個支持並發的設計。與並行不同，單核單線程能支持並發。

經常看到這樣一個說法，叫做並發執行。現在我們可以正確理解它。有兩種可能：

1. 原本想說的是「並行執行」，但是用錯了詞

2. 指多個操作可以在重疊的時間段內進行，即，真的並行，或是類似上圖那樣的執行模式。

我的建議是儘可能不使用這個詞，容易造成誤會，尤其是對那些並發並行不分的人。但是讀到這裡的各位顯然能正確區分，所以下面為了簡便，將使用並發執行這個詞。

第二個重點是「可以在重疊的時間段內進行」中的「可以」兩個字。「可以」的意思是，正確的並發設計使並發執行成為可能，但是程序在實際運行時卻不一定會出現多個任務執行時間段 overlap 的情形。比如：我們的程序會為每個任務開一個線程或者協程，只有一個任務時，顯然不會出現多個任務執行時間段重疊的情況，有多個任務時，就會出現了。這裡我們看到，並發並不描述程序執行的狀態，它描述的是一種設計，是程序的結構，比如上面例子裡「為每個任務開一個線程」的設計。並發設計和程序實際執行情況沒有直接關聯，但是正確的並發設計讓並發執行成為可能。反之，如果程序被設計為執行完一個任務再接著執行下一個，那就不是並發設計了，因為做不到並發執行。

那麼，如何實現支持並發的設計？兩個字：拆分。

之所以並發設計往往需要把流程拆開，是因為如果不拆分也就不可能在同一時間段進行多個任務了。這種拆分可以是平行的拆分，比如抽象成同類的任務，也可以是不平行的，比如分為多個步驟。

並發和並行的關係

Different concurrent designs enable different ways to parallelize.

這句話來自著名的talk: Concurrency is not parallelism。它足夠concise，以至於不需要過多解釋。但是僅僅引用別人的話總是不太好，所以我再用之前文字的總結來說明：並發設計讓並發執行成為可能，而並行是並發執行的一種模式。

2. 線程與進程

2.1 什麼是進程？為什麼要有進程？

一個在內存中運行的應用程式。每個進程都有自己獨立的一塊內存空間，一個進程可以有多個線程，比如在Windows系統中，一個運行的xx.exe就是一個進程。

進程有一個相當精簡的解釋：進程是對作業系統上正在運行程序的一個抽象。

這個概念確實挺抽象，仔細想想卻也挺精準。

我們平常使用計算機，都會在同一時間做許多事，比如邊看電影，邊微信聊天，順便打開瀏覽器百度搜索一下，我們所做的這麼多事情背後都是一個個正在運行中的軟體程序；這些軟體想要運行起來，首先在磁碟上需要有各自的程序代碼，然後將代碼加載到內存中，cpu會去執行這些代碼，運行中會產生很多數據需要存放，也可能需要和網卡、顯卡、鍵盤等外部設備交互，這背後其實就涉及到程序對計算機資源的使用，存在這麼多程序，我們當然需要想辦法管理程序資源的使用。並且CPU如果只有一個，那麼還需要作業系統調度CPU分配給各個程序使用，讓用戶感覺這些程序在同時運行，不影響用戶體驗。

理所當然，作業系統會把每個運行中的程序封裝成獨立的實體，分配各自所需要的資源，再根據調度算法切換執行。這個抽象程序實體就是進程。

所以很多對進程的官方解釋中都會提到：進程是作業系統進行資源分配和調度的一個基本單位。

2.2 什麼是線程？為什麼要有線程？

在早期的作業系統中並沒有線程的概念，進程是擁有資源和獨立運行的最小單位，也是程序執行的最小單位。任務調度採用的是時間片輪轉的搶占式調度方式，而進程是任務調度的最小單位，每個進程有各自獨立的內存空間，使得各個進程之間內存地址相互隔離。

後來，隨著計算機行業的發展，程序的功能設計越來越複雜，我們的應用中同時發生著多種活動，其中某些活動隨著時間的推移會被阻塞，比如網絡請求、讀寫文件（也就是IO操作），我們自然而然地想著能不能把這些應用程式分解成更細粒度、能 准並行運行 多個順序執行實體，並且這些細粒度的執行實體可以共享進程的地址空間，也就是可以共享程序代碼、數據、內存空間等，這樣程序設計模型會變得更加簡單。

其實很多計算機世界裡的技術演變，都是模擬現實世界。比如我們把一個進程當成一個項目，當項目任務變得複雜時，自然想著能不能將項目按照業務、產品、工作方向等分成一個個任務模塊，分派給不同人員各自並行完成，再按照某種方式組織起各自的任務成果，最終完成項目。

需要多線程還有一個重要的理由就是：每個進程都有獨立的代碼和數據空間（程序上下文），程序之間的切換會有較大的開銷；線程可以看做輕量級的進程，同一類線程共享代碼和數據空間，每個線程都有自己獨立的運行棧和程序計數器，線程之間切換的開銷小。所以線程的創建、銷毀、調度性能遠遠優於進程。

在引入多線程模型後，進程和線程在程序執行過程中的分工就相當明確了，進程負責分配和管理系統資源，線程負責CPU調度運算，也是CPU切換時間片的最小單位。對於任何一個進程來講，即便我們沒有主動去創建線程，進程也是默認有一個主線程的。進程中的一個執行任務（控制單元），負責當前進程中程序的執行。一個進程至少有一個線程，一個進程可以運行多個線程，多個線程可共享數據。

與進程不同的是同類的多個線程共享進程的堆和方法區資源，但每個線程有自己的程序計數器、虛擬機棧和本地方法棧，所以系統在產生一個線程，或是在各個線程之間作切換工作時，負擔要比進程小得多，也正因為如此，線程也被稱為輕量級進程。

Java 程序天生就是多線程程序，我們可以通過 JMX 來看一下一個普通的 Java 程序有哪些線程，代碼如下。

public class MultiThread {
    public static void main(String[] args) {
        // 獲取 java 線程管理 MXBean
        ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();

        // 不需要獲取同步的 monitor 和 synchronizer 信息，僅獲取線程和線程堆棧信息
        ThreadInfo[] threadInfos = threadMXBean.dumpAllThreads(false, false);

        // 遍歷線程信息，僅列印線程 ID 和線程名稱信息
        for (ThreadInfo threadInfo : threadInfos) {
            System.out.println("[" + threadInfo.getThreadId() + "] " + threadInfo.getThreadName());
        }
    }
}

上述程序輸出如下（輸出內容可能不同，不用太糾結下面每個線程的作用，只用知道 main 線程執行 main 方法即可）：

[6] Monitor Ctrl-Break //監聽線程轉儲或「線程堆棧跟蹤」的線程

[5] Attach Listener //負責接收到外部的命令，而對該命令進行執行的並且把結果返回給發送者

[4] Signal Dispatcher // 分發處理給 JVM 信號的線程

[3] finalizer //在垃圾收集前，調用對象 finalize 方法的線程

[2] Reference Handler //用於處理引用對象本身（軟引用、弱引用、虛引用）的垃圾回收的線程

[1] main //main 線程,程序入口

從上面的輸出內容可以看出：一個 Java 程序的運行是 main 線程和多個其他線程同時運行。

2.3 它們在Linux內核中實現方式有何不同？

在Linux 裡面，無論是進程，還是線程，到了內核裡面，我們統一都叫任務（Task），由一個統一的結構 task_struct 進行管理，這個task_struct 數據結構非常複雜，囊括了進程管理生命周期中的各種信息。

在Linux作業系統內核初始化時會創建第一個進程，即0號創始進程。隨後會初始化1號進程（用戶進程祖宗：/usr/lib/systemd/systemd），2號進程（內核進程祖宗：[kthreadd]），其後所有的進程線程都是在他們的基礎上fork出來的。

我們一般都是通過fork系統調用來創建新的進程，fork 系統調用包含兩個重要的事件，一個是將 task_struct 結構複製一份並且初始化，另一個是試圖喚醒新創建的子進程。

我們說無論是進程還是線程，在內核裡面都是task，管起來不是都一樣嗎？到底如何區分呢？其實，線程不是一個完全由內核實現的機制，它是由內核態和用戶態合作完成的。

創建進程的話，調用的系統調用是 fork，會將五大結構 files_struct、fs_struct、sighand_struct、signal_struct、mm_struct 都複製一遍，從此父進程和子進程各用各的數據結構。而創建線程的話，調用的是系統調用 clone，五大結構僅僅是引用計數加一，也即線程共享進程的數據結構。

2.4 並發與並行的區別？

功能： 進程是作業系統資源分配的基本單位，而線程是任務調度和執行的基本單位

開銷： 每個進程都有獨立的內存空間，存放代碼和數據段等，程序之間的切換會有較大的開銷；線程可以看做輕量級的進程，共享內存空間，每個線程都有自己獨立的運行棧和程序計數器，線程之間切換的開銷小。

運行環境： 在作業系統中能同時運行多個進程；而在同一個進程（程序）中有多個線程同時執行（通過CPU調度，在每個時間片中只有一個線程執行）

創建過程： 在創建新進程的時候，會將父進程的所有五大數據結構複製新的，形成自己新的內存空間數據，而在創建新線程的時候，則是引用進程的五大數據結構數據，但是線程會有自己的私有數據、棧空間。

進程和線程其實在cpu看來都是task_struct結構的一個封裝，執行不同task即可，而且在cpu看來就是在執行這些task時候遵循對應的調度策略以及上下文資源切換定義，包括寄存器地址切換，內核棧切換。所以對於cpu而言，進程和線程是沒有區別的。

並發編程的挑戰

並發編程的目的是為了讓程序運行得更快，但是，並不是啟動更多的線程就能讓程序最大限度地並發執行。在進行並發編程時，如果希望通過多線程執行任務讓程序運行得更快，會面臨非常多的挑戰，比如上下文切換的問題、死鎖的問題，以及受限於硬體和軟體的資源限制問題，本章會介紹幾種並發編程的挑戰以及解決方案。

上下文切換

即使是單核處理器也支持多線程執行代碼，CPU通過給每個線程分配CPU時間片來實現這個機制。時間片是CPU分配給各個線程的時間，因為時間片非常短，所以CPU通過不停地切換線程執行，讓我們感覺多個線程是同時執行的，時間片一般是幾十毫秒（ms）。

CPU通過時間片分配算法來循環執行任務，當前任務執行一個時間片後會切換到下一個任務。但是，在切換前會保存上一個任務的狀態，以便下次切換回這個任務時，可以再加載這個任務的狀態。所以任務從保存到再加載的過程就是一次上下文切換。

這就像我們同時讀兩本書，當我們在讀一本英文的技術書時，發現某個單詞不認識，於是便打開中英文字典，但是在放下英文技術書之前，大腦必須先記住這本書讀到了多少頁的第多少行，等查完單詞之後，能夠繼續讀這本書。這樣的切換是會影響讀書效率的，同樣上下文切換也會影響多線程的執行速度。

多線程一定快嗎？

下面的代碼演示串行和並發執行並累加操作的時間，請分析：下面的代碼並發執行一定比串行執行快嗎？

public class ConcurrencyTest {
    private static final long count = 10000l;

    public static void main(String[] args) throws InterruptedException {
        concurrency();
        serial();
    }

    private static void concurrency() throws InterruptedException {
        long start = System.currentTimeMillis();
        Thread thread = new Thread(new Runnable() {
            @Override
            public void run() {
                int a = 0;
                for (long i = 0; i < count; i++) {
                    a += 5;
                }
            }
        });
        thread.start();
        int b = 0;
        for (long i = 0; i < count; i++) {
            b--;

        }

        long time = System.currentTimeMillis() - start;
        thread.join();

        System.out.println("concurrency :" + time + "ms,b=" + b);

    }

    private static void serial() {

        long start = System.currentTimeMillis();
        int a = 0;

        for (long i = 0; i < count; i++) {
            a += 5;

        }

        int b = 0;

        for (long i = 0; i < count; i++) {
            b--;

        }

        long time = System.currentTimeMillis() - start;
        System.out.println("serial:" + time + "ms,b=" + b + ",a=" + a);
    }
}

上述問題的答案是「不一定」，測試結果如表1-1所示。

表1-1 測試結果

從表1-1可以發現，當並發執行累加操作不超過百萬次時，速度會比串行執行累加操作要慢。那麼，為什麼並發執行的速度會比串行慢呢？這是因為線程有創建和上下文切換的開銷。

測試上下文切換次數和時長

下面我們來看看有什麼工具可以度量上下文切換帶來的消耗。

使用Lmbench3[1]可以測量上下文切換的時長。

使用vmstat可以測量上下文切換的次數。

下面是利用vmstat測量上下文切換次數的示例。

$ vmstat 1

proCS -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----

CS（Content Switch）表示上下文切換的次數，從上面的測試結果中我們可以看到，上下文每1秒切換1000多次。

如何減少上下文切換

減少上下文切換的方法有無鎖並發編程、CAS算法、使用最少線程和使用協程。

·無鎖並發編程。多線程競爭鎖時，會引起上下文切換，所以多線程處理數據時，可以用一些辦法來避免使用鎖，如將數據的ID按照Hash算法取模分段，不同的線程處理不同段的數據。

·CAS算法。Java的Atomic包使用CAS算法來更新數據，而不需要加鎖。

·使用最少線程。避免創建不需要的線程，比如任務很少，但是創建了很多線程來處理，這樣會造成大量線程都處於等待狀態。

·協程：在單線程里實現多任務的調度，並在單線程里維持多個任務間的切換。

減少上下文切換實戰

通過減少線上大量WAITING的線程，來減少上下文切換次數。

第一步：用jstack命令dump線程信息，看看pid為3117的進程里的線程都在做什麼。

sudo -u admin /opt/ifeve/java/bin/jstack 31177 > /home/tengfei.fangtf/dump17

第二步：統計所有線程分別處於什麼狀態，發現300多個線程處於WAITING（onobject- monitor）狀態。

[tengfei.fangtf@ifeve ~]$ grep java.lang.Thread.State dump17 | awk '{print $2$3$4$5}'

| sort | uniq -c

39 RUNNABLE

21 TIMED_WAITING(onobjectmonitor)

6 TIMED_WAITING(parking)

51 TIMED_WAITING(sleeping)

305 WAITING(onobjectmonitor)

3 WAITING(parking)

第三步：打開dump文件查看處於WAITING（onobjectmonitor）的線程在做什麼。發現這些線程基本全是JBOSS的工作線程，在await。說明JBOSS線程池裡線程接收到的任務太少，大量線程都閒著。

"http-0.0.0.0-7001-97" daemon prio=10 tid=0x000000004f6a8000 nid=0x555e in Object.wait() [0x0000000052423000]

java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method)

-waiting on <0x00000007969b2280> (a org.apache.tomcat.util.net.AprEndpoint$Worker) at java.lang.Object.wait(Object.java:485)

at org.apache.tomcat.util.net.AprEndpoint$Worker.await(AprEndpoint.java:1464)

-locked <0x00000007969b2280> (a org.apache.tomcat.util.net.AprEndpoint$Worker) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1489)

at java.lang.Thread.run(Thread.java:662)

第四步：減少JBOSS的工作線程數，找到JBOSS的線程池配置信息，將maxThreads降到

100。

<maxThreads="250" maxHttpHeaderSize="8192" emptySessionPath="false" minSpareThreads="40" maxSpareThreads="75"

maxPostSize="512000" protocol="HTTP/1.1"

enableLookups="false" redirectPort="8443" acceptCount="200" bufferSize="16384" connectionTimeout="15000" disableUploadTimeout="false" useBodyEncodingForURI= "true">

第五步：重啟JBOSS，再dump線程信息，然後統計WAITING（onobjectmonitor）的線程，發現減少了175個。WAITING的線程少了，系統上下文切換的次數就會少，因為每一次從WAITTING到RUNNABLE都會進行一次上下文的切換。讀者也可以使用vmstat命令測試一下。

[tengfei.fangtf@ifeve ~]$ grep java.lang.Thread.State dump17 | awk '{print $2$3$4$5}'

| sort | uniq -c

44 RUNNABLE

22 TIMED_WAITING(onobjectmonitor)

9 TIMED_WAITING(parking)

36 TIMED_WAITING(sleeping)

130 WAITING(onobjectmonitor)

1 WAITING(parking)

死鎖

鎖是個非常有用的工具，運用場景非常多，因為它使用起來非常簡單，而且易於理解。但同時它也會帶來一些困擾，那就是可能會引起死鎖，一旦產生死鎖，就會造成系統功能不可用。讓我們先來看一段代碼，這段代碼會引起死鎖，使線程t1和線程t2互相等待對方釋放鎖。

public class DeadLockDemo {
    privat
    static String A = "A";
    private static String B = "B";

    public static void main(String[] args) {
        new DeadLockDemo().deadLock();

    }

    private void deadLock() {

        Thread t1 = new Thread(new Runnable() {
            @Override
            publicvoid run() {

                synchronized (A) {
                    try {
                        Thread.currentThread().sleep(2000);

                    } catch (InterruptedException e) {
                        e.printStackTrace();

                    }
                    synchronized (B) {
                        System.out.println("1");
                    }
                }
            }
        });

        Thread t2 = new Thread(new Runnable() {
            @Override
            publicvoid run() {
                synchronized (B) {
                    synchronized (A) {
                        System.out.println("2");
                    }
                }
            }
        });
        t1.start();
        t2.start();
    }
}

這段代碼只是演示死鎖的場景，在現實中你可能不會寫出這樣的代碼。但是，在一些更為

複雜的場景中，你可能會遇到這樣的問題，比如t1拿到鎖之後，因為一些異常情況沒有釋放鎖

（死循環）。又或者是t1拿到一個資料庫鎖，釋放鎖的時候拋出了異常，沒釋放掉。

一旦出現死鎖，業務是可感知的，因為不能繼續提供服務了，那麼只能通過dump線程查看到底是哪個線程出現了問題，以下線程信息告訴我們是DeadLockDemo類的第42行和第31行引起的死鎖。

"Thread-2" prio=5 tid=7fc0458d1000 nid=0x116c1c000 waiting for monitor entry [116c1b00 java.lang.Thread.State: BLOCKED (on object monitor)

at com.ifeve.book.forkjoin.DeadLockDemo$2.run(DeadLockDemo.java:42)

-waiting to lock <7fb2f3ec0> (a java.lang.String)

-locked <7fb2f3ef8> (a java.lang.String) at java.lang.Thread.run(Thread.java:695)

"Thread-1" prio=5 tid=7fc0430f6800 nid=0x116b19000 waiting for monitor entry [116b1800 java.lang.Thread.State: BLOCKED (on object monitor)

at com.ifeve.book.forkjoin.DeadLockDemo$1.run(DeadLockDemo.java:31)

-waiting to lock <7fb2f3ef8> (a java.lang.String)

-locked <7fb2f3ec0> (a java.lang.String) at java.lang.Thread.run(Thread.java:695)

現在我們介紹避免死鎖的幾個常見方法。

·避免一個線程同時獲取多個鎖。

·避免一個線程在鎖內同時占用多個資源，儘量保證每個鎖只占用一個資源。

·嘗試使用定時鎖，使用lock.tryLock（timeout）來替代使用內部鎖機制。

·對於資料庫鎖，加鎖和解鎖必須在一個資料庫連接里，否則會出現解鎖失敗的情況。

資源限制的挑戰

（1）什麼是資源限制

資源限制是指在進行並發編程時，程序的執行速度受限於計算機硬體資源或軟體資源。例如，伺服器的帶寬只有2Mb/s，某個資源的下載速度是1Mb/s每秒，系統啟動10個線程下載資 源，下載速度不會變成10Mb/s，所以在進行並發編程時，要考慮這些資源的限制。硬體資源限制有帶寬的上傳/下載速度、硬碟讀寫速度和CPU的處理速度。軟體資源限制有資料庫的連接數和socket連接數等。

（2）資源限制引發的問題

在並發編程中，將代碼執行速度加快的原則是將代碼中串行執行的部分變成並發執行， 但是如果將某段串行的代碼並發執行，因為受限於資源，仍然在串行執行，這時候程序不僅不會加快執行，反而會更慢，因為增加了上下文切換和資源調度的時間。例如，之前看到一段程序使用多線程在辦公網並發地下載和處理數據時，導致CPU利用率達到100%，幾個小時都不能運行完成任務，後來修改成單線程，一個小時就執行完成了。

（3）如何解決資源限制的問題

對於硬體資源限制，可以考慮使用集群並行執行程序。既然單機的資源有限制，那麼就讓程序在多機上運行。比如使用ODPS、Hadoop或者自己搭建伺服器集群，不同的機器處理不同的數據。可以通過「數據ID%機器數」，計算得到一個機器編號，然後由對應編號的機器處理這筆數據。

對於軟體資源限制，可以考慮使用資源池將資源復用。比如使用連接池將資料庫和Socket 連接復用，或者在調用對方webservice接口獲取數據時，只建立一個連接。

（4）在資源限制情況下進行並發編程

如何在資源限制的情況下，讓程序執行得更快呢？方法就是，根據不同的資源限制調整程序的並發度，比如下載文件程序依賴於兩個資源——帶寬和硬碟讀寫速度。有資料庫操作時，涉及資料庫連接數，如果SQL語句執行非常快，而線程的數量比資料庫連接數大很多，則某些線程會被阻塞，等待資料庫連接。