如何把握編程世界的那把鎖
1.共享變量惹得禍
我們這里是個(gè)典型的弱肉強(qiáng)食的世界， 人口多而資源少，為了爭(zhēng)搶有限的資源，大家都在自己能運(yùn)行的CPU時(shí)間片里拼了老命，經(jīng)常為了一個(gè)變量的修改而打的頭破血流。
100納秒以前， 我有幸占據(jù)了CPU，從內(nèi)存中讀取了一個(gè)變量x == 100, 我把它加了1， 休息了一會(huì)兒后我打算把它寫回內(nèi)存， 但是驚奇的發(fā)現(xiàn)： 內(nèi)存中的x 已經(jīng)變成102了。
估計(jì)是哪個(gè)不著調(diào)的線程在我休息的時(shí)候也讀取并且修改了x， 有不少好心的線程在沖我喊：不要寫回了! 但是寫回內(nèi)存是我的指令啊， 你不讓我執(zhí)行，難道讓我退出? 我只能毫不客氣的把101寫入內(nèi)存， 把那個(gè)不符合我邏輯的值102給覆蓋掉， 這樣我才能執(zhí)行下一條指令。
你看，單線程的邏輯正確并不表示多線程并發(fā)運(yùn)行時(shí)的邏輯也能正確。
這樣的事情發(fā)生的多了，程序總是無(wú)法正確運(yùn)行， 引起了人類的強(qiáng)烈不滿，小道消息說(shuō)他們?cè)诳紤]kill掉我們， 換編程語(yǔ)言了。
但是換編程語(yǔ)言有什么用，只要有共享變量，多線程讀寫的時(shí)候就是會(huì)出現(xiàn)不一致啊。
除非你消除共享變量，讓每個(gè)線程只訪問(wèn)一個(gè)函數(shù)內(nèi)的局部變量， 這些局部變量我們每個(gè)線程都會(huì)有一份， 函數(shù)結(jié)束以后就會(huì)銷毀，所以線程之間就隔離了，就安全了。
消除共享變量談何容易， 人類使用的很多語(yǔ)言例如C++, Java，那些共享變量大多數(shù)一個(gè)對(duì)象的字段， 你想把字段去掉， 只留下函數(shù)， 那類也沒(méi)有存在的必要了， 就類似于函數(shù)式編程了， 一切都是函數(shù)。 有時(shí)候我挺羨慕函數(shù)式的世界， 那種無(wú)狀態(tài)應(yīng)該是一種非常美妙的感覺(jué)吧。
2.爭(zhēng)搶吧，線程
既然共享變量是無(wú)法消除的，那就想想別的辦法吧， 線程元老院的那幫家伙們哼哧了半天，終于公布了一個(gè)方案： 加鎖！
任何線程，只要你想操作一個(gè)共享變量，對(duì)不起， 先去申請(qǐng)一把鎖， 拿到這把鎖才能讀取x的值 ， 修改x的值， 把x寫回內(nèi)存， ***釋放鎖，讓別人去玩。
元老院設(shè)計(jì)的這把鎖非常簡(jiǎn)單， 類似于一個(gè)boolean 變量， boolean lock = false. 誰(shuí)能搶先把這個(gè)變量改成true, 就意味著獲取了這把鎖。
來(lái)吧，哥幾個(gè)，快來(lái)?yè)尠?!
我運(yùn)行的時(shí)候， 就去檢查lock這個(gè)變量是否可以設(shè)置為true, 如果被別的家伙給搶到了(已經(jīng)變成true了)， 我就在這里***循環(huán)，拼命的搶， 除非我的時(shí)間片到了，被迫讓出CPU, 但是我不會(huì)阻塞， 還是就緒狀態(tài)，等待下一次的調(diào)度， 進(jìn)入CPU繼續(xù)搶。
看到某人把它變成false, 我眼疾手快迅速出手， 終于搶到了，趕緊把lock改成true, 這把鎖現(xiàn)在屬于我了， 趕快去干活，干完活要記住把lock 改成false, 讓別的家伙們?nèi)尅?/p>
我想正是由于這種***循環(huán)的特點(diǎn)， 元老院把他命名為“自旋鎖”吧!
列位看官，可能你已經(jīng)想到了， 假設(shè)有兩個(gè)線程，都讀到了lock == false, 都把lock 改成true, 那這個(gè)鎖算誰(shuí)的?
這個(gè)問(wèn)題元老院的大佬們?cè)缇涂紤]到了， 他們和操作系統(tǒng)(我聽說(shuō)還有硬件)都商量好了， 這個(gè)檢測(cè)lock是否為false, 以及設(shè)置lock 為true 的操作 其實(shí)被合并了， 叫做test_and_set(lock), 操作系統(tǒng)鄭重承諾，這是一個(gè)不可分割的原子操作， 在這個(gè)test_and_set執(zhí)行的時(shí)候，總線都被鎖住了， 別人不能訪問(wèn)內(nèi)存， 即使有多個(gè)CPU在執(zhí)行也不會(huì)亂掉。
如果你感興趣，可以看看下面的實(shí)現(xiàn)， 否則直接無(wú)視跳過(guò)：
3.改進(jìn)
有了自旋鎖， 至少可以保證程序的正確運(yùn)行了， 我們大家都玩的不亦樂(lè)乎。
有一天我遇到了一個(gè)遞歸函數(shù)， 我是挺喜歡遞歸的， 因?yàn)檫壿嫼?jiǎn)單， 只要遞歸的層次別太深， 別搞出棧溢出就好。
這個(gè)遞歸函數(shù)中需要獲得自旋鎖，做點(diǎn)事情， 然后繼續(xù)調(diào)用自己， 類似于這樣：
我***次調(diào)用doSomething, 獲取了自旋鎖， 然后第二次調(diào)用doSomething, 還要獲取自旋鎖， 可是這個(gè)鎖已經(jīng)在我***次調(diào)用的時(shí)候持有了， 現(xiàn)在第二次調(diào)用只有***的等待了!
這下尷尬了， 我進(jìn)退不得， 自己把自己搞成了死鎖!
看來(lái)這個(gè)自旋鎖雖然能實(shí)現(xiàn)互斥的訪問(wèn)， 但是不能重新進(jìn)入同一個(gè)函數(shù)(簡(jiǎn)稱不可重入)啊!
我趕緊把這個(gè)問(wèn)題向元老院做了匯報(bào)， 修改方案很快就下來(lái)了： 每次成功的申請(qǐng)鎖以后，要記錄下到底是誰(shuí)申請(qǐng)的， 還要用一個(gè)計(jì)數(shù)器記錄重入的次數(shù)， 下一次持有鎖的家伙再次申請(qǐng)鎖只是給計(jì)數(shù)器加一而已。
釋放的時(shí)候也是一樣， 把計(jì)數(shù)器減一， 如果等于0了才真正的釋放鎖。
可重入性就這么解決了， 但是這么多線程都在那里拼命的搶也不是辦法， 空耗CPU也是巨大的浪費(fèi)啊。
于是元老院又發(fā)布了新的鎖 ReentrantLock， 這個(gè)鎖可以重入，如果你搶不到， 不要***循環(huán)了， 乖乖的到等待隊(duì)列里待著去， 等到鎖被別人釋放了再通知你去搶。(在Java 中最初是synchronzied關(guān)鍵字，可以用在一個(gè)方法上或者一個(gè)代碼塊上， 后來(lái)又改進(jìn)為更加靈活的ReentrantLock)
很快就有線程還抱怨說(shuō)， 明明是我先發(fā)出獲得鎖的申請(qǐng)啊， 為什么隔壁老王卻先拿到了鎖? 這不公平啊，不行，以后得排隊(duì)， 先來(lái)先得。 好吧， 只好加上一個(gè)是否公平的參數(shù)。
還有線程說(shuō)， 我是個(gè)急性子，申請(qǐng)鎖的時(shí)候只想等待5秒鐘， 5秒之內(nèi)得不到鎖我就放棄了， 能不能支持? 那就再加上一個(gè)參數(shù)：等待時(shí)間。
4.發(fā)揚(yáng)光大
體會(huì)到鎖帶來(lái)的甜頭以后， 各種各樣樣的需求紛至沓來(lái)：
（1）有時(shí)候需要多個(gè)線程都獲得同一把鎖，去做一件事情，那怎么辦呢?
沒(méi)關(guān)系，信號(hào)量(Semaphore)出馬，創(chuàng)建信號(hào)量的時(shí)候得指定一個(gè)整數(shù)(例如10)， 表明同一時(shí)刻最多有10個(gè)線程可以獲得鎖：
Semaphore lock= new Semaphore(10);
當(dāng)然每個(gè)線程都需要調(diào)用lock.aquire(), lock.release()去申請(qǐng)/釋放鎖。
（2）一個(gè)線程要寫共享變量， 可是還有幾個(gè)線程要同時(shí)讀， 怎么辦? 你寫的時(shí)候可以鎖住， 但總不能讀的時(shí)候也只允許一個(gè)線程吧?
只好來(lái)一個(gè)讀寫鎖了ReadWriteLock， 為了保證可重入性， 元老院體貼的實(shí)現(xiàn)了ReentrantReadWriteLock。
（3）一個(gè)線程需要等待其他多個(gè)線程完工以后才能干活，怎么辦?
CountDownLatch前來(lái)救駕， 搞一個(gè)計(jì)數(shù)器，某個(gè)線程干完了就把計(jì)數(shù)器減去1， 如果計(jì)數(shù)器為0了，那個(gè)一直耐心等待的線程就可以開始了。
（4）還有幾個(gè)線程必須互相等待， 就像100米賽跑那樣， 所有人都準(zhǔn)備好了才能開閘放水， 不，是起跑， 就那就賞你一個(gè)CyclicBarrier吧。
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)作者微信公眾號(hào)coderising獲取授權(quán)】
