從Java視角理解系統結構連載, 關注我的微博(連結)瞭解最新動態

在高效能程式設計時,經常接觸到多執行緒. 起初我們的理解是, 多個執行緒並行地執行總比單個執行緒要快, 就像多個人一起幹活總比一個人幹要快. 然而實際情況是, 多執行緒之間需要競爭IO裝置, 或者競爭鎖資源，導致往往執行速度還不如單個執行緒. 在這裡有一個經常提及的概念就是: 上下文切換(Context Switch).

上下文切換的精確定義可以參考: http://www.linfo.org/context_switch.html. 下面做個簡單的介紹. 多工系統往往需要同時執行多道作業.作業數往往大於機器的CPU數, 然而一顆CPU同時只能執行一項任務, 如何讓使用者感覺這些任務正在同時進行呢? 作業系統的設計者巧妙地利用了時間片輪轉的方式, CPU給每個任務都服務一定的時間, 然後把當前任務的狀態儲存下來, 在載入下一任務的狀態後, 繼續服務下一任務. 任務的狀態儲存及再載入, 這段過程就叫做上下文切換. 時間片輪轉的方式使多個任務在同一顆CPU上執行變成了可能, 但同時也帶來了儲存現場和載入現場的直接消耗.
(Note. 更精確地說, 上下文切換會帶來直接和間接兩種因素影響程式效能的消耗. 直接消耗包括: CPU暫存器需要儲存和載入, 系統排程器的程式碼需要執行, TLB例項需要重新載入, CPU 的pipeline需要刷掉; 間接消耗指的是多核的cache之間得共享資料, 間接消耗對於程式的影響要看執行緒工作區操作資料的大小).


在linux中可以使用vmstat觀察上下文切換的次數. 執行命令如下:
Shell程式碼  

1. $ vmstat 1
2. procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----  
3.  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa  
4.  100459394445356011181920014122383061921
5.  0004593212453568111881600096958110841942
6.  0004593360453568
   11184560000895104431950
7.  100459340845356811184560000929107341950
8.  0004593496453568111845600001133136361930
9.  000459356845356811184760000992119041950

vmstat 1指每秒統計一次, 其中cs列就是指上下文切換的數目. 一般情況下, 空閒系統的上下文切換每秒大概在1500以下.

對於我們經常使用的搶佔式作業系統來說, 引起上下文切換的原因大概有以下幾種: 1. 當前執行任務的時間片用完之後, 系統CPU正常排程下一個任務 2. 當前執行任務碰到IO阻塞, 排程器將掛起此任務, 繼續下一任務 3. 多個任務搶佔鎖資源, 當前任務沒有搶到,被排程器掛起, 繼續下一任務 4. 使用者程式碼掛起當前任務, 讓出CPU時間 5. 硬體中斷. 前段時間發現有人在使用futex的WAIT和WAKE來測試context switch的直接消耗(

連結), 也有人使用阻塞IO來測試context switch的消耗(連結).那麼Java程式怎麼測試和觀察上下文切換的消耗呢?

我做了一個小實驗, 程式碼很簡單, 有兩個工作執行緒. 開始時，第一個執行緒掛起自己; 第二個執行緒喚醒第一個執行緒，再掛起自己; 第一個執行緒醒來之後喚醒第二個執行緒, 再掛起自己. 就這樣一來一往,互相喚醒對方, 掛起自己. 程式碼如下:
Java程式碼  

1. import java.util.concurrent.atomic.AtomicReference;  
2. import java.util.concurrent.locks.LockSupport;  
3. publicfinalclass ContextSwitchTest {  
4.     staticfinalint RUNS = 3;  
5.     staticfinalint ITERATES = 1000000;  
6.     static AtomicReference turn = new AtomicReference();  
7.     staticfinalclass WorkerThread extends Thread {  
8.         volatile Thread other;  
9.         volatileint nparks;  
10.         publicvoid run() {  
11.             final AtomicReference t = turn;  
12.             final Thread other = this.other;  
13.             if (turn == null || other == null)  
14.                 thrownew NullPointerException();  
15.             int p = 0;  
16.             for (int i = 0; i < ITERATES; ++i) {  
17.                 while (!t.compareAndSet(other, this)) {  
18.                     LockSupport.park();  
19.                     ++p;  
20.                 }  
21.                 LockSupport.unpark(other);  
22.             }  
23.             LockSupport.unpark(other);  
24.             nparks = p;  
25.             System.out.println("parks: " + p);  
26.         }  
27.     }  
28.     staticvoid test() throws Exception {  
29.         WorkerThread a = new WorkerThread();  
30.         WorkerThread b = new WorkerThread();  
31.         a.other = b;  
32.         b.other = a;  
33.         turn.set(a);  
34.         long startTime = System.nanoTime();  
35.         a.start();  
36.         b.start();  
37.         a.join();  
38.         b.join();  
39.         long endTime = System.nanoTime();  
40.         int parkNum = a.nparks + b.nparks;  
41.         System.out.println("Average time: " + ((endTime - startTime) / parkNum)  
42.                 + "ns");  
43.     }  
44.     publicstaticvoid main(String[] args) throws Exception {  
45.         for (int i = 0; i < RUNS; i++) {  
46.             test();  
47.         }  
48.     }  
49. }  

編譯後,在我自己的筆記本上( Intel(R) Core(TM) i5 CPU M 460  @ 2.53GHz, 2 core, 3M L3 Cache) 用測試幾輪，結果如下:
Shell程式碼  

1. java -cp . ContextSwitchTest  
2. parks: 953495
3. parks: 953485
4. Average time: 11373ns  
5. parks: 936305
6. parks: 936302
7. Average time: 11975ns  
8. parks: 965563
9. parks: 965560
10. Average time: 13261ns  

我們會發現這麼簡單的for迴圈, 線性執行會非常快,不需要1秒, 而執行這段程式需要幾十秒的耗時. 每個上下文切換需要耗去十幾us的時間,這對於程式吞吐量的影響很大.

同時我們可以執行vmstat 1 觀查一下上下文切換的頻率是否變快
Shell程式碼  

1. $ vmstat 1
2. procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----  
3.  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa  
4.  100442498845796411549120013122528061921
5.  0004420452457964115990000001586206961930
6.  1004407676457964117155200001436188383890
7.  1004402916457964117203200084229824579294852
8.  100441602445796411589120000953821985441710730
9.  1104416096457964115896800011679973159934187740
10.  100442038445796411547760000962651960761510741
11.  100440301245797211710960001521043212135372012662

再使用strace觀察以上程式中Unsafe.park()究竟是哪道系統呼叫造成了上下文切換:
Shell程式碼  

1. $strace -f java -cp . ContextSwitchTest  
2. [pid  5969] futex(0x9571a9c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x9571a98, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
3. [pid  5968] <... futex resumed> )       = 0
4. [pid  5969] futex(0x9571ad4, FUTEX_WAIT_PRIVATE, 949, NULL <unfinished ...>  
5. [pid  5968] futex(0x9564368, FUTEX_WAKE_PRIVATE, 1) = 0
6. [pid  5968] futex(0x9571ad4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x9571ad0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1} <unfinished ...>  
7. [pid  5969] <... futex resumed> )       = 0
8. [pid  5968] <... futex resumed> )       = 1
9. [pid  5969] futex(0x9571628, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>  

果然還是futex.

再使用perf看看上下文對於Cache的影響:
Shell程式碼  

1. $ perf stat -e cache-misses   java -cp . ContextSwitchTest  
2. parks: 999999
3. parks: 1000000
4. Average time: 16201ns  
5. parks: 998930
6. parks: 998926
7. Average time: 14426ns  
8. parks: 998034
9. parks: 998204
10. Average time: 14489ns  
11.  Performance counter stats for 'java -cp . ContextSwitchTest':  
12.          2,550,605 cache-misses                                                  
13.       90.221827008 seconds time elapsed  

1分半鐘內有255萬多次cache未命中.

嗯, 貌似太長了, 可以結束了. 接下來會繼續幾篇博文繼續分析一些有意思的東西.
(1) 從Java視角看記憶體屏障 (Memory Barrier)
(2) 從java視角看CPU親緣性 (CPU Affinity)
等..敬請關注


PS. 其實還做了一個實驗, 測試CPU Affinity對於Context Switch的影響.
Shell程式碼  

1. $ taskset -c 0 java -cp . ContextSwitchTest  
2. parks: 992713
3. parks: 1000000
4. Average time: 2169ns  
5. parks: 978428
6. parks: 1000000
7. Average time: 2196ns  
8. parks: 989897
9. parks: 1000000
10. Average time: 2214ns  

這個命令把程序繫結在0號CPU上,結果Context Switch的消耗小了一個數量級, 什麼原因呢? 賣個關子, 在談到CPU Affinity的博文再說