本文轉(zhuǎn)載自微信公眾號「 小姐姐味道」，轉(zhuǎn)載本文請聯(lián)系 小姐姐味道公眾號。

 作為一只鳥，可以邊吃東西邊拉屎么?這對一個養(yǎng)過鸚鵡的人來說，答案是肯定的。

[[329543]]

從鳥嘴到鳥大腸，整個過程是串行的。雖然有些曲折，但方向是單一的，出口是一定的。只要鳥能夠克服一些心理上的不悅，它就能辦得到。

這種情況在一些原始的物種身上顯得有些尷尬。比如水螅，它屬于腔腸動物，無性生殖。這幾個單詞都挺唬人，但它的體內(nèi)只有一個空腔。從哪里吃，就從哪里出。

同是地球上的物種，從長遠(yuǎn)看來，我們還是它的近親。

作為高級哺乳動物，我們能夠在呼吸的時候，同時說話，也能夠同時聽到聲音，看到賞心悅目的風(fēng)景。如果你想的話，也可以辦到鸚鵡做的事。

這些信息被收集之后，一股腦發(fā)送給大腦進(jìn)行處理。有可能是像深度學(xué)習(xí)一樣，存了一堆權(quán)重，但這些信息到底是如何處理的，我們現(xiàn)在還不得而知。

所以程序員們轉(zhuǎn)而研究計算機(jī)，畢竟這個相比起“最后歸途是哲學(xué)”的人類大腦，就像是個玩具。

我們都知道，干一堆事干不好，不如集中精力把一件事干好。這并不是說一個人沒能力把所有的事情干好，而是在不同的事務(wù)之間切換，是要耗費資源的。

你的大腦好不容易熟悉了一個工作場景，結(jié)果突然調(diào)度給它另外一項任務(wù)，它就要花很長時間切換到新的工作場景中。

有時候代碼寫多了，我就連說話都開始口吃。但一直不停的說說說，就又恢復(fù)了。

所以，所有的人都恨零零散散的工作事務(wù)。尤其是恨哪些不斷給你小事情，但又毫不相關(guān)的任務(wù)的領(lǐng)導(dǎo)。

到頭來，感覺做了很多，但一點成果都沒有，感覺人都廢了。

不要怕，我們看看CPU是怎么處理的。

CPU處理任務(wù)時不是一直只處理一個，而是通過給每個線程分配CPU時間片，時間片用完了就切換下一個線程。

時間片非常短，一般只有幾十毫秒，CPU通過不停地切換線程執(zhí)行，但我們幾乎感覺不到任務(wù)的停滯。因為對人類來說，高質(zhì)量的游戲，每秒只需要60幀，就算是流暢了。

這個時間還是相當(dāng)可觀的，特別是在進(jìn)程上下文切換次數(shù)較多的情況下，很容易導(dǎo)致CPU將大量時間消耗在寄存器，內(nèi)核棧以及虛擬內(nèi)存等資源的保存和恢復(fù)上，進(jìn)而大大縮短了真正運行進(jìn)程的時間。

對于Linux來說。程序在執(zhí)行過程中通常有用戶態(tài)和內(nèi)核態(tài)兩種狀態(tài)，CPU對處于內(nèi)核態(tài)根據(jù)上下文環(huán)境進(jìn)一步細(xì)分，因此有了下面三種狀態(tài)：

• 內(nèi)核態(tài)，運行于進(jìn)程上下文，內(nèi)核代表進(jìn)程運行于內(nèi)核空間。
• 內(nèi)核態(tài)，運行于中斷上下文，內(nèi)核代表硬件運行于內(nèi)核空間。
• 用戶態(tài)，運行于用戶空間

我們看一下Linux的top命令，是怎么顯示內(nèi)核態(tài)和用戶態(tài)的。

如上圖，us就是user的意思;sy就是system的意思。分別代表了用戶態(tài)和內(nèi)核態(tài)。

如果sy占用的太高，就有可能是上下文切換和中斷太頻繁了。

那什么是上下文?

所謂的上下文，說白了就是一個環(huán)境。比如你去食堂帶著飯盒，去廁所帶著廁紙。要是搞亂了，去廁所帶著飯盒，感覺上就不正常。操作系統(tǒng)為每一個進(jìn)程，分配了這么一個上下文，用來存放：代碼、數(shù)據(jù)、用戶堆棧、共享存儲區(qū)、寄存器、進(jìn)程控制塊等。

先不要管里面的細(xì)節(jié)了，反正內(nèi)容很多，切換肯定是要有陳本的。比如，廁紙放在家里臥室柜子的第三層小隔間。

vmstat命令顯示的這幾列，就是這么個意思。cs不是csgo的縮寫，它的全拼是context switch。

在每個進(jìn)程里，也可以看到累加的值。

[root@localhost ~]# cat /proc/2788/status 
... 
voluntary_ctxt_switches: 93950 
nonvoluntary_ctxt_switches: 171204 

cs如果太高，那就是線程或者進(jìn)程開的太多了。

上下文切換又分為2種。

讓步式上下文切換和搶占式上下文切換。

下面先說下讓步式上下文切換。我們拿Java中的cas操作來看就可以了。

cas除了 compare and switch原始指令支持以外，還需要一個循環(huán)來保證。

public final long getAndAddLong(Object var1, long var2, long var4) { 
        long var6; 
        do { 
            var6 = this.getLongVolatile(var1, var2); 
        } while(!this.compareAndSwapLong(var1, var2, var6, var6 + var4)); 
        return var6; 
} 

代碼放在循環(huán)里，在并發(fā)量比較高的情況下，如果許多線程反復(fù)嘗試更新某一個變量，卻又一直更新不成功，循環(huán)往復(fù)，會給CPU帶來很大的壓力。所以，讓步式上下文切換，是指執(zhí)行線程主動釋放CPU，與鎖競爭嚴(yán)重程度成正比，可通過減少鎖競爭來避免。

而搶占式上下文切換，是指線程因分配的時間片用盡而被迫放棄CPU，或者被其他優(yōu)先級更高的線程所搶占。一般由于線程數(shù)大于CPU可用核心數(shù)引起，可通過調(diào)整線程數(shù)，適當(dāng)減少線程數(shù)來避免。

那為啥Java的線程就能夠比多進(jìn)程速度快一些呢?因為Java的線程本質(zhì)上也是一種輕量級進(jìn)程，但它的虛擬內(nèi)存等信息是共享的，只需要切換線程的私有數(shù)據(jù)，寄存器等不共享的數(shù)據(jù)。即使這樣，也會耗費不少時間。

使用perf命令同樣能夠觀測到這個上下文切換到過程和數(shù)量。比如：

# 跟蹤所有上下文切換，直到Ctrl-C： 
perf record -e context-switches -c 1 -a 
 
# 包括使用的原始設(shè)置（請參閱：man perf_event_open）： 
perf record -vv -e context-switches -a 
 
# 使用堆棧跟蹤的示例上下文切換，直到Ctrl-C： 
perf record -e context-switches -ag 

使用perf report即可查看相關(guān)結(jié)果。

對于計算機(jī)來說，效率最高的依然是專心做一件事。一定程度上，你也算是計算機(jī)的老板。如果你一直讓它干一些雜活，把它當(dāng)牛使，那你的計算機(jī)效率不一定會高。

有些人很聰明，他一定知道這種來回切換的方式對你的工作效率影響巨大。排除他愚蠢的屬性，就只剩下壞：給你一堆爛七八糟的事，搞得你身心疲憊，最后又和你講結(jié)果導(dǎo)向的---一定是你的領(lǐng)導(dǎo)故意為之。

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進(jìn)一步交流。