一、多線程簡述

線程是程序執行流的最小單元，一個線程包括：獨有ID，程序計數器 (Program Counter)，寄存器集合，堆棧。同一進程可以有多個線程，它們共享進程的全局變量和堆數據。

這里的 PC (Program Counter) 指向的是當前的指令地址，通過 PC 的更新來運行我們的程序，一個線程同一時刻只能執行一條指令。當然我們知道線程和進程都是虛擬的概念，實際上 PC 是 CPU 核心中的寄存器，它是實際存在的，所以也可以說一個 CPU 核心同一時刻只能執行一個線程。

不管是多處理器設備還是多核設備，開發者往往只需要關心 CPU 的核心數量，而不需關心它們的物理構成。CPU 核心數量是有限的，也就是說一個設備并發執行的線程數量是有限的，當線程數量超過 CPU 核心數量時，一個 CPU 核心往往就要處理多個線程，這個行為叫做線程調度。

線程調度簡單來說就是：一個 CPU 核心輪流讓各個線程分別執行一段時間。當然這中間還包含著復雜的邏輯，后文再來分析。

二、多線程的優化思路

在移動端開發中，因為系統的復雜性，開發者往往不能期望所有線程都能真正的并發執行，而且開發者也不清楚 XNU 何時切換內核態線程、何時進行線程調度，所以開發者要經常考慮到線程調度的情況。

1、減少線程切換

當線程數量超過 CPU 核心數量，CPU 核心通過線程調度切換用戶態線程，意味著有上下文的轉換（寄存器數據、棧等），過多的上下文切換會帶來資源開銷。雖然內核態線程的切換理論上不會是性能負擔，開發中還是應該盡量減少線程的切換。

2、線程優先級權衡

通常來說，線程調度除了輪轉法以外，還有優先級調度的方案，在線程調度時，高優先級的線程會更早的執行。有兩個概念需要明確：

IO 密集型線程：頻繁等待的線程，等待的時候會讓出時間片。 CPU 密集型線程：很少等待的線程，意味著長時間占用著 CPU。

特殊場景下，當多個 CPU 密集型線程霸占了所有 CPU 資源，而它們的優先級都比較高，而此時優先級較低的 IO 密集型線程將持續等待，產生線程餓死的現象。當然，為了避免線程餓死，系統會逐步提高被“冷落”線程的優先級，IO 密集型線程通常情況下比 CPU 密集型線程更容易獲取到優先級提升。

雖然系統會自動做這些事情，但是這總歸會造成時間等待，可能會影響用戶體驗。所以筆者認為開發者需要從兩個方面權衡優先級問題：

讓 IO 密集型線程優先級高于 CPU 密集型線程。 讓緊急的任務擁有更高的優先級。

比如一個場景：大量的圖片異步解壓的任務，解壓的圖片不需要立即反饋給用戶，同時又有大量的異步查詢磁盤緩存的任務，而查詢磁盤緩存任務完成過后需要反饋給用戶。

圖片解壓屬于 CPU 密集型線程，查詢磁盤緩存屬于 IO 密集型線程，而后者需要反饋給用戶更加緊急，所以應該讓圖片解壓線程的優先級低一點，查詢磁盤緩存的線程優先級高一點。

值得注意的是，這里是說大量的異步任務，意味著 CPU 很有可能滿負荷運算，若 CPU 資源綽綽有余的情況下就沒那個必要去處理優先級問題。

3、主線程任務的優化

有些業務只能寫在主線程，比如 UI 類組件的初始化及其布局。其實這方面的優化就比較多了，業界所說的性能優化大部分都是為了減輕主線程的壓力，似乎有些偏離了多線程優化的范疇了，下面就基于主線程任務的管理大致羅列幾點吧：

內存復用

通過內存復用來減少開辟內存的時間消耗，這在系統 UI 類組件中應用廣泛，比如 UITableViewCell 的復用。同時，減少開辟內存意味著減少了內存釋放，同樣能節約 CPU 資源。

懶加載任務

既然 UI 組件必須在主線程初始化，那么就需要用時再初始化吧，swift 的寫時復制也是類似的思路。

任務拆分排隊執行

通過監聽 Runloop 即將結束等通知，將大量的任務拆分開來，在每次 Runloop 循環周期執行少量任務。其實在實踐這種優化思路之前，應該想想能不能將任務放到異步線程，而不是用這種比較極端的優化手段。

主線程空閑時執行任務

//這里是主線程上下文`dispatch_async(dispatch_get_main_queue(), ^{//等到主線程空閑執行該任務});

三、關于“鎖”

多線程會帶來線程安全問題，當原子操作不能滿足業務時，往往需要使用各種“鎖”來保證內存的讀寫安全。

常用的鎖有互斥鎖、讀寫鎖、空轉鎖，通常情況下，iOS 開發中互斥鎖pthread_mutex_t、dispatch_semaphore_t，讀寫鎖pthread_rwlock_t就能滿足大部分需求，并且性能不錯。

在讀取鎖失敗時，線程有可能有兩種狀態：

空轉狀態：線程執行空任務循環等待，當鎖可用時立即獲取鎖。 掛起狀態：線程掛起，當鎖可用時需要其他線程喚醒。

喚醒線程比較耗時，線程空轉需要消耗 CPU 資源并且時間越長消耗越多，由此可知空轉適合少量任務、掛起適合大量任務。

實際上互斥鎖和讀寫鎖都有空轉鎖的特性，它們在獲取鎖失敗時會先空轉一段時間，然后才會掛起，而空轉鎖也不會永遠的空轉，在特定的空轉時間過后仍然會掛起，所以通常情況下不用刻意去使用空轉鎖，Casa Taloyum 在博客中有詳細的解釋。

1、OSSpinLock 優先級反轉問題

優先級反轉概念：比如兩個線程 A 和 B，優先級 A < B。當 A 獲取鎖訪問共享資源時，B 嘗試獲取鎖，那么 B 就會進入忙等狀態，忙等時間越長對 CPU 資源的占用越大；而由于 A 的優先級低于 B，A 無法與高優先級的線程爭奪 CPU 資源，從而導致任務遲遲完成不了。解決優先級反轉的方法有“優先級天花板”和“優先級繼承”，它們的核心操作都是提升當前正在訪問共享資源的線程的優先級。

2、避免死鎖

很常見的場景是，同一線程重復獲取鎖導致的死鎖，這種情況可以使用遞歸鎖來處理，pthread_mutex_t使用pthread_mutex_init_recursive()方法初始化就能擁有遞歸鎖的特性。

使用pthread_mutex_trylock()等嘗試獲取鎖的方法能有效的避免死鎖的情況

3、最小化加鎖任務

開發者應該充分的理解業務，將鎖包含的代碼區域盡量縮小，不會出現線程安全問題 的代碼就不要用鎖來保護了，這樣才能提高并發時鎖的性能。

4、時刻注意不可重入方法的安全

當一個方法是可重入的時候，可以放心大膽的使用，若一個方法不可重入，開發者應該多留意，思考這個方法會不會有多個線程訪問的情況，若有就老老實實的加上線程鎖。

5、編譯器的過度優化

編譯器可能會為了提高效率將變量寫入寄存器而暫時不寫回，方便下次使用，我們知道一句代碼轉換為指令不止一條，所以在變量寫入寄存器沒來得及寫回的過程中，可能這個變量被其它線程讀寫了。編譯器同樣會為了提高效率對它認為順序無關的指令調換順序。

以上都可能會導致合理使用鎖的地方仍然線程不安全，而volatile關鍵字就可以解決這類問題，它能阻止編譯器為了效率將變量緩存到寄存器而不及時寫回，也能阻止編譯器調整操作volatile修飾變量的指令順序。

原子自增函數就有類似的應用： int32_t OSAtomicIncrement32( volatile int32_t *__theValue ) 。

6、CPU 亂序執行

CPU 也可能為了提高效率而去交換指令的順序，導致加鎖的代碼也不安全，解決這類問題可以使用內存屏障，CPU 越過內存屏障后會刷新寄存器對變量的分配。

以上就是iOS 如何高效使用的多線程的詳細內容，更多關于ios 多線程的資料請關注好吧啦網其它相關文章！