本篇文章作為多線程的一個開篇可能會偏向于概念性和基礎(chǔ)性灯变。因?yàn)槲业挠媱澥菑倪@篇開始接下來幾篇會去探究下GCD的底層源碼實(shí)現(xiàn)橘原。所以有基礎(chǔ)的同學(xué)可以略過這篇文章利赋。
線程和進(jìn)程的定義
線程：
進(jìn)程：
線程和進(jìn)程的關(guān)系
從上面我們知道線程沒有獨(dú)立的地址空間，但是我們又聽說過有一個叫TLS（線程的本地存儲）的東西堡距，那這個是什么呢甲锡？為什么叫線程的暫存空間呢？這里我摘選《程序員的自我修養(yǎng)》一書中的介紹：
* 線程局部存儲（Thread Local Storage,TLS）羽戒。線程局部存儲是某些操作系統(tǒng)為線程單獨(dú)提供的私有空間，但通常只具有很有限的容量易稠。
而且這個TLS在后面我們對GCD底層探究的時候會再次看到它缸废，在同步鎖中主要是對SyncData進(jìn)行一些存儲。
多線程
多線程優(yōu)缺點(diǎn)：
我們都知道iOS的app都是單進(jìn)程的（排除那些所謂的web進(jìn)程啥的）。那在這種情況下多線程的出現(xiàn)就更是解決了燃眉之急企量，因?yàn)槿羰菦]有多線程那么所有任務(wù)只能是一個接一個的去等待完成测萎，效率會很低。這就涉及到多線程的意義或者說優(yōu)缺點(diǎn)届巩。如圖：
在這里也把官方的多線程文檔鏈接發(fā)一下硅瞧，同時把網(wǎng)上經(jīng)常能看到的一個關(guān)于內(nèi)存的官網(wǎng)圖片也發(fā)下：
多線程方案：
多線程原理：
同樣也要明白一個問題就是，多線程并不等于并發(fā)恕汇。并不一定是所有任務(wù)一起執(zhí)行腕唧。這就涉及到多線程的原理。如圖：
時間片概念：
所以從上圖我們可以知道多線程也不一定就是并發(fā)（所有任務(wù)一起執(zhí)行）而是在CPU的調(diào)度下在線程間不停切換瘾英。這樣就能適當(dāng)?shù)谋苊獗荒硞€線程堵死進(jìn)程枣接，也能適當(dāng)?shù)墓?jié)省資源提高效率。當(dāng)然這里所說的CPU都是以單核為例的缺谴。如果是多核那當(dāng)然可以在同一時間調(diào)度處理多個線程月腋。這里就涉及到一個概念-時間片 如圖：
多線程生命周期：
多線程之間的調(diào)度也是有生命周期的，因?yàn)?strong>CPU在多個線程間頻繁切換和調(diào)度的時候就涉及到每個線程都必須有各種狀態(tài)瓣赂，比如從線程創(chuàng)建->線程預(yù)備妥當(dāng)->線程被調(diào)度運(yùn)行->線程死亡榆骚。在這過程中還有可能線程被睡眠、加鎖等操作影響從而進(jìn)入阻塞狀態(tài)煌集。等待這一切操作結(jié)束這條線程又要進(jìn)入到預(yù)備調(diào)度和運(yùn)行的過程中妓肢。用一張圖表示就如下：
多線程調(diào)度線程池和飽和策略：
線程調(diào)度池：
飽和策略：
任務(wù)的執(zhí)行速度的影響因素：
我們了解了下調(diào)度線程池和飽和策略，那我們就不禁會思考我們?nèi)蝿?wù)執(zhí)行速度會受哪些因素的影響呢苫纤？我們大概可以總結(jié)出以下幾點(diǎn)：
1碉钠，CPU的情況
舉個例子：我們?nèi)ツ滩璧曩I奶茶，如果這家店比較小只有一個工作人員和一個窗口來服務(wù)卷拘，那么相比隔壁一家有三個窗口五個服務(wù)員的比較大的奶茶店這家小的奶茶店在硬件上就比不上隔壁的喊废，這也就是CPU的影響±醯埽或者是同一家店你在買奶茶高峰期進(jìn)店買和買奶茶人員稀少的時候進(jìn)店也是不一樣的污筷。同樣也是CPU在不同狀態(tài)下的影響。
2乍赫，任務(wù)的復(fù)雜度
舉個例子：我們?nèi)ツ滩璧曩I奶茶瓣蛀，如果兩個服務(wù)員同時給兩個買奶茶的人制作奶茶，一個人要買十杯一個只需要一杯雷厂，那很明顯兩個人買完奶茶的任務(wù)的速度也是不一樣的惋增。這就是人物復(fù)雜度的影響。
3改鲫，任務(wù)優(yōu)先級
舉個例子：我們還是去奶茶店買奶茶诈皿，如果這家店有VIP服務(wù)林束，兩個人進(jìn)店一個是SVIP一個是普通的顧客。在接待上稽亏，很明顯SVIP會優(yōu)先诊县，而普通的則只能稍加等待。這就是優(yōu)先級的影響措左。
4依痊，線程狀態(tài)
舉個例子：我們還是去奶茶店買奶茶，如果這家店有兩個窗口在賣奶茶怎披，兩個人分別同時到達(dá)各自的窗口點(diǎn)單胸嘁。但是其中一個窗口的工作人員因?yàn)橥蝗挥屑笔滦枰x開兩分鐘，那么這個窗口就必須得暫停服務(wù)凉逛，另一個窗口的顧客就會先拿到奶茶離開性宏。這就是線程狀態(tài)的影響。
優(yōu)先級翻轉(zhuǎn)(IO VS CPU 優(yōu)先級提升)：
當(dāng)我們在執(zhí)行任務(wù)的時候若是一切資源都比較充裕那么任務(wù)會很順利執(zhí)行状飞，但是在遇到資源緊張的時候無論是來自硬件還是任務(wù)的條件都會大大影響任務(wù)執(zhí)行的速度毫胜。甚至在某些情況下還會直接在飽和策略里被處理掉，或者直接被一直掛著诬辈。這種情況就會出現(xiàn)一個名詞-餓死在這種情況下就出現(xiàn)了另一個名詞-優(yōu)先級翻轉(zhuǎn)
一般情況下酵使，IO 密集型 （頻繁等待）的優(yōu)先級是比 CPU 密集型 （很少等待） 低的。也就是會在某種情況下 因?yàn)閮?yōu)先級低的緣故或者其他緣故導(dǎo)致線程餓死 也得不到執(zhí)行焙糟。這個時候就需要利用一些方法來解決這種情況口渔。所以就需要CPU來調(diào)度分配，將那些 頻繁等待的任務(wù)提升優(yōu)先級等穿撮，將資源傾斜一些給那些任務(wù)缺脉。但是并不是提升了優(yōu)先級就一定會執(zhí)行因?yàn)檫€有很多其他因素影響。
優(yōu)先級影響因素：
一般我們會認(rèn)為優(yōu)先級的影響因素有三個：
1悦穿，用戶指定
2攻礼，CPU會根據(jù)進(jìn)入執(zhí)行的等待頻繁度來提高和降低優(yōu)先級
3，當(dāng)有些任務(wù)一直不執(zhí)行的時候也會得到優(yōu)先級提升
以上的三點(diǎn)影響因素是《程序員自我修養(yǎng)》一書中有提到的栗柒。
多線程資源搶奪：
資源搶奪是我們在多線程里經(jīng)常聽到的一個名詞礁扮，舉個簡單而經(jīng)典的例子：
春運(yùn)12306售票系統(tǒng)售票，成千上萬個窗口同時售同一趟列車的票傍衡。但是票數(shù)是有限的比如10000張深员，當(dāng)某個窗口售出去一張后，此時服務(wù)器里只剩下999張了蛙埂，但是第二個窗口和這個窗口去查詢票的時候得到的票數(shù)都是10000，只是第二個窗口出票比第一個窗口慢了一點(diǎn)遮糖，這個時候就造成了數(shù)據(jù)不同步绣的，而造成資源搶奪。因?yàn)樵谀骋粋€時刻多個窗口查詢到的票數(shù)一樣但是在出票的時候后臺數(shù)據(jù)卻因?yàn)槟硞€窗口出票而有所改變，這個時候其他窗口并不知情屡江，所以剩下的票可能就不足以出售這些窗口下的單芭概。這個時候解決的辦法就是加鎖。
今天我們簡單了解下自旋鎖和互斥鎖的區(qū)別
自旋鎖：
同步鎖惩嘉，在發(fā)現(xiàn)其他線程執(zhí)行操作的時候罢洲，當(dāng)前線程進(jìn)入一個 忙等的狀態(tài)，這個狀態(tài)會一直主動詢問文黎，其他線程是否執(zhí)行完畢惹苗，若是執(zhí)行完畢則執(zhí)行當(dāng)前線程。自旋鎖性能耗費(fèi)比較高耸峭，適合用于比較短小簡單的任務(wù)桩蓉。
互斥鎖：
同步鎖，在發(fā)現(xiàn)其他線程執(zhí)行操作的時候劳闹，當(dāng)前線程進(jìn)入 休眠狀態(tài)院究，一直等待收到通知喚醒執(zhí)行（需要主動操作）才會執(zhí)行當(dāng)前線程”咎椋互斥鎖性能消耗比較小业汰，適用于更多場景。
我們先看看自旋鎖
其實(shí)在我們的開發(fā)過程中會常用到一個東西就是 屬性的修飾符 atomic菩颖。我們都知道atomic是原子性 是為多線程開發(fā)準(zhǔn)備的蔬胯，是默認(rèn)屬性。但是在我們探究OC底層的屬性設(shè)置的時候會發(fā)現(xiàn)位他，atomic 其實(shí)就是一個標(biāo)識符氛濒，這個標(biāo)識符系統(tǒng)會自動添加一把自旋鎖。而相對的非原子屬性 的nonatomic 卻沒有鹅髓。這也再次表明nonatomic比atomic性能高舞竿。我們看看部分代碼：
本文到這里就差不多結(jié)束了，本文主要是針對以下概念的東西來簡單分解窿冯，主要目的是為了后面我們用的非常多的GCD篇章做鋪墊骗奖。
遇事不決，可問春風(fēng)醒串。站在巨人的肩膀上學(xué)習(xí)执桌，如有疏忽或者錯誤的地方還請多多指教。謝謝芜赌！
