面試題

• 你理解的多線程？
• iOS的多線程方案有哪幾種？你更傾向于哪一種？
• 你在項目中用過 GCD 嗎？
• GCD 的隊列類型
• 說一下 OperationQueue 和 GCD 的區別，以及各自的優勢
• 線程安全的處理手段有哪些？
• OC你了解的鎖有哪些？在你回答基礎上進行二次提問；
  • 追問一：自旋和互斥對比？
  • 追問二：使用以上鎖需要注意哪些？
  • 追問三：用C/OC/C++，任選其一，實現自旋或互斥？口述即可！

• 請問下面代碼的打印結果是什么？

  
  
  • 打印結果是：1、3
  • 原因
    • performSelector:withObject:afterDelay:的本質是往Runloop中添加定時器
    • 子線程默認沒有啟動Runloop

• 請問下面代碼的打印結果是什么？

  
  

方案

iOS中的常見多線程方案

GCD的常用函數

• GCD中有2個用來執行任務的函數
  • 用同步的方式執行任務dispatch_sync(dispatch_queue_t queue, dispatch_block_t block);
    • queue：隊列
    • block：任務
  • 用異步的方式執行任務dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
• GCD源碼：https://github.com/apple/swift-corelibs-libdispatch

GCD的隊列

GCD的隊列可以分為2大類型

• 并發隊列（Concurrent Dispatch Queue）
  • 可以讓多個任務并發（同時）執行（自動開啟多個線程同時執行任務）
  • 并發功能只有在異步（dispatch_async）函數下才有效
• 串行隊列（Serial Dispatch Queue）
  • 讓任務一個接著一個地執行（一個任務執行完畢后，再執行下一個任務）

容易混淆的術語

有4個術語比較容易混淆：同步、異步、并發、串行

• 同步和異步主要影響：能不能開啟新的線程
  • 同步：在當前線程中執行任務，不具備開啟新線程的能力
  • 異步：在新的線程中執行任務，具備開啟新線程的能力
• 并發和串行主要影響：任務的執行方式
  • 并發：多個任務并發（同時）執行
  • 串行：一個任務執行完畢后，再執行下一個任務

各種隊列的執行效果

使用sync函數往當前串行隊列中添加任務，會卡住當前的串行隊列（產生死鎖）

隊列組

隊列組的使用

思考：如何用gcd實現以下功能

• 異步并發執行任務1、任務2

• 等任務1、任務2都執行完畢后，再回到主線程執行任務3

  
  

多線程的安全隱患

• 資源共享
  • 1塊資源可能會被多個線程共享，也就是多個線程可能會訪問同一塊資源
  • 比如多個線程訪問同一個對象、同一個變量、同一個文件
• 當多個線程訪問同一塊資源時，很容易引發數據錯亂和數據安全問題

多線程安全隱患示例01 – 存錢取錢

多線程安全隱患示例02 – 賣票

多線程安全隱患分析

多線程安全隱患的解決方案

解決方案：使用線程同步技術（同步，就是協同步調，按預定的先后次序進行）
常見的線程同步技術是：加鎖

線程同步方案

iOS中的線程同步方案

OSSpinLock
os_unfair_lock
pthread_mutex
dispatch_semaphore
dispatch_queue(DISPATCH_QUEUE_SERIAL)
NSLock
NSRecursiveLock
NSCondition
NSConditionLock
@synchronized

GNUstep

GNUstep是GNU計劃的項目之一，它將Cocoa的OC庫重新開源實現了一遍
源碼地址：http://www.gnustep.org/resources/downloads.php
雖然GNUstep不是蘋果官方源碼，但還是具有一定的參考價值

OSSpinLock

OSSpinLock叫做”自旋鎖”，等待鎖的線程會處于忙等（busy-wait）狀態，一直占用著CPU資源
目前已經不再安全，可能會出現優先級反轉問題
如果等待鎖的線程優先級較高，它會一直占用著CPU資源，優先級低的線程就無法釋放鎖

需要導入頭文件#import <libkern/OSAtomic.h>

os_unfair_lock

os_unfair_lock用于取代不安全的OSSpinLock ，從iOS10開始才支持
從底層調用看，等待os_unfair_lock鎖的線程會處于休眠狀態，并非忙等
需要導入頭文件#import <os/lock.h>

pthread_mutex

mutex叫做”互斥鎖”，等待鎖的線程會處于休眠狀態
需要導入頭文件#import <pthread.h>

pthread_mutex – 遞歸鎖

pthread_mutex – 條件

NSLock、NSRecursiveLock

• NSLock是對mutex普通鎖的封裝

  
  
• NSRecursiveLock也是對mutex遞歸鎖的封裝，API跟NSLock基本一致

NSCondition

NSCondition是對mutex和cond的封裝

NSConditionLock

NSConditionLock是對NSCondition的進一步封裝，可以設置具體的條件值

dispatch_semaphore

semaphore叫做”信號量”
信號量的初始值，可以用來控制線程并發訪問的最大數量
信號量的初始值為1，代表同時只允許1條線程訪問資源，保證線程同步

dispatch_queue

直接使用GCD的串行隊列，也是可以實現線程同步的

@synchronized

@synchronized是對mutex遞歸鎖的封裝
源碼查看：objc4中的objc-sync.mm文件
@synchronized(obj)內部會生成obj對應的遞歸鎖，然后進行加鎖、解鎖操作

iOS線程同步方案性能比較

性能從高到低排序

• os_unfair_lock
• OSSpinLock
• dispatch_semaphore
• pthread_mutex
• dispatch_queue(DISPATCH_QUEUE_SERIAL)
• NSLock
• NSCondition
• pthread_mutex(recursive)
• NSRecursiveLock
• NSConditionLock
• @synchronized

自旋鎖、互斥鎖比較

什么情況使用自旋鎖比較劃算？

• 預計線程等待鎖的時間很短
• 加鎖的代碼（臨界區）經常被調用，但競爭情況很少發生
• CPU資源不緊張
• 多核處理器

什么情況使用互斥鎖比較劃算？

• 預計線程等待鎖的時間較長
• 單核處理器
• 臨界區有IO操作
• 臨界區代碼復雜或者循環量大
• 臨界區競爭非常激烈

automic

atomic用于保證屬性setter、getter的原子性操作，相當于在getter和setter內部加了線程同步的鎖
可以參考源碼objc4的objc-accessors.mm
它并不能保證使用屬性的過程是線程安全的

讀寫安全

iOS中的讀寫安全方案

思考如何實現以下場景

• 同一時間，只能有1個線程進行寫的操作
• 同一時間，允許有多個線程進行讀的操作
• 同一時間，不允許既有寫的操作，又有讀的操作

上面的場景就是典型的“多讀單寫”，經常用于文件等數據的讀寫操作，iOS中的實現方案有

• pthread_rwlock：讀寫鎖
• dispatch_barrier_async：異步柵欄調用

pthread_rwlock

等待鎖的線程會進入休眠

dispatch_barrier_async

這個函數傳入的并發隊列必須是自己通過dispatch_queue_cretate創建的
如果傳入的是一個串行或是一個全局的并發隊列，那這個函數便等同于dispatch_async函數的效果