《iOS底層原理文章匯總》
上一篇文章《iOS-底層原理24-GCD(上)》介紹了異步函數(shù)disasync的包裝和調(diào)用流程剖淀，本文介紹線程是怎么被GCD封裝創(chuàng)建的

1.隊列的創(chuàng)建以模板進(jìn)行處理:基礎(chǔ)模板的基礎(chǔ)上進(jìn)行修改

DISPATCH_ALWAYS_INLINE
static inline dispatch_introspection_queue_s
_dispatch_introspection_lane_get_info(dispatch_lane_class_t dqu)
{
    dispatch_lane_t dq = dqu._dl;
    bool global = _dispatch_object_is_global(dq);
    uint64_t dq_state = os_atomic_load2o(dq, dq_state, relaxed);

    dispatch_introspection_queue_s diq = {
        .queue = dq->_as_dq,
        .target_queue = dq->do_targetq,
        .label = dq->dq_label,
        .serialnum = dq->dq_serialnum,
        .width = dq->dq_width,
        .suspend_count = _dq_state_suspend_cnt(dq_state) + dq->dq_side_suspend_cnt,
        .enqueued = _dq_state_is_enqueued(dq_state) && !global,
        .barrier = _dq_state_is_in_barrier(dq_state) && !global,
        .draining = (dq->dq_items_head == (void*)~0ul) ||
                (!dq->dq_items_head && dq->dq_items_tail),
        .global = global,
        .main = dx_type(dq) == DISPATCH_QUEUE_MAIN_TYPE,
    };
    return diq;
}

image.png

怎么知道如下進(jìn)入_dispatch_continuation_redirect_push還是_dispatch_lane_push,通過下符號斷點的方式知道進(jìn)入_dispatch_continuation_redirect_push之后進(jìn)入_dispatch_root_queue_push

image.png

image.png

image.png

image.png

2.pthread創(chuàng)建線程過程

以上程序進(jìn)入_dispatch_root_queue_push后進(jìn)入_dispatch_root_queue_push_inline(rq, dou, dou, 1)符號斷點驗證進(jìn)入_dispatch_root_queue_poke_slow

image.png

image.png

3.GCD單例:流程如何控制一次?怎么保證線程安全?

單例dispatch_once.png

線程安全,第一次還沒訪問到這把鎖适瓦，第二次又進(jìn)入會進(jìn)入等待狀態(tài),始終返回不了珍德，可以對延遲做設(shè)置_dispatch_once_wait(l)

4.上節(jié)課的堆棧信息中pthread創(chuàng)建線程后libsystem_pthread.dylib_pthread_wqthread,怎么調(diào)用到libdispatch.dylib_dispatch_worker_thread2的呢挪挤？

在_dispatch_root_queues_init_once方法中注冊_dispatch_worker_thread2,經(jīng)過系統(tǒng)級別的os_atomic_load2o(dq, dgq_thread_pool_size, ordered)進(jìn)行調(diào)用,之后還有回調(diào)completeHandler

* thread #4, queue = 'cooci', stop reason = breakpoint 1.1
  * frame #0: 0x000000010b60b157 001---函數(shù)與隊列`__29-[ViewController viewDidLoad]_block_invoke(.block_descriptor=0x000000010b60e0e8) at ViewController.m:42:9
    frame #1: 0x000000010b876f11 libdispatch.dylib`_dispatch_call_block_and_release + 12
    frame #2: 0x000000010b877e8e libdispatch.dylib`_dispatch_client_callout + 8
    frame #3: 0x000000010b87a7a3 libdispatch.dylib`_dispatch_continuation_pop + 552
    frame #4: 0x000000010b879bbb libdispatch.dylib`_dispatch_async_redirect_invoke + 771
    frame #5: 0x000000010b889399 libdispatch.dylib`_dispatch_root_queue_drain + 351
    frame #6: 0x000000010b889ca6 libdispatch.dylib`_dispatch_worker_thread2 + 135
    frame #7: 0x00007fff523019f7 libsystem_pthread.dylib`_pthread_wqthread + 220
    frame #8: 0x00007fff52300b77 libsystem_pthread.dylib`start_wqthread + 15

image.png

image.png

image.png

5.柵欄函數(shù)dispatch_barrier_async(異步柵欄函數(shù)不會堵塞當(dāng)前所在線程后面語句)和dispatch_barrier_sync(同步柵欄函數(shù)會堵塞當(dāng)前所在線程后面語句)，堵塞傳入的隊列(只能是自定義并發(fā)隊列)棺榔，直到前面的任務(wù)執(zhí)行完，后面的柵欄函數(shù)中的block才會執(zhí)行

• 1.異步柵欄函數(shù):不會堵塞當(dāng)前所在線程后面語句

  
  
  image.png

• 2.同步柵欄函數(shù):會堵塞當(dāng)前所在線程后面語句

  
  
  image.png

• 3.柵欄函數(shù)傳入的只能是并發(fā)隊列，且只能是自定義的并發(fā)隊列不能是全局并發(fā)隊列

• 4.并發(fā)隊列數(shù)據(jù)安全問題胶哲，可以使用柵欄函數(shù)
  程序奔潰的原因是:self.mArray中不斷加入新元素時，會不斷set設(shè)置新值潭辈，retain新值,release舊值,多線程進(jìn)入時鸯屿，可能會釋放還沒有分配內(nèi)存空間的指針地址,OC可變數(shù)組底層也是一個數(shù)組，數(shù)組大小是固定的10把敢，在add到一定數(shù)量后寄摆，它就需要擴(kuò)容，擴(kuò)容會創(chuàng)建一個新的數(shù)組修赞，把舊數(shù)組的數(shù)據(jù)移到新數(shù)組婶恼，舊的數(shù)組就被釋放了，然后新的數(shù)組再指向給self.mArray柏副，但是異步并發(fā)的情況下勾邦，其它任務(wù)中拿到的還是舊的已經(jīng)被釋放的數(shù)組指針，所以在它要擴(kuò)容時想要釋放這個舊的指針會報這個錯割择，因為舊指針已經(jīng)被釋放了

  
  
  image.png
  
  

  若將數(shù)組self.mArray容量改為500就不會崩潰

  
  
  image.png
  
  為了保障數(shù)據(jù)安全眷篇，必須要給數(shù)據(jù)的存儲加鎖@synchronized(self){}，確保操作數(shù)據(jù)的原子性,通過柵欄函數(shù)保障數(shù)據(jù)安全
  
  image.png

• 5.柵欄函數(shù)不能用全局并發(fā)隊列,全局并發(fā)隊列為系統(tǒng)的,往里面添加?xùn)艡跁踝∠到y(tǒng)的任務(wù),當(dāng)前全局并發(fā)隊列還有系統(tǒng)中的很多任務(wù)在后臺執(zhí)行

  
  
  image.png

• 6.柵欄函數(shù)也無必要用串行隊列,DISPATCH_QUEUE_SERIAL已經(jīng)起到同步有序的作用了,隊列里面的任務(wù)會依次有序執(zhí)行,無需添加?xùn)艡诤瘮?shù),只需添加異步函數(shù)即可,添加?xùn)艡诤瘮?shù)會浪費性能,底層會有柵欄相關(guān)的流程分析以及判別

  
  
  image.png
  
  

  柵欄在某一時刻只有一次,數(shù)組添加前判斷前面是否有同步或柵欄函數(shù)攔截荔泳，沒有則添加add,下次再進(jìn)入蕉饼，若發(fā)現(xiàn)有柵欄則無法進(jìn)入進(jìn)行add,有柵欄說明上一次任務(wù)沒有執(zhí)行完畢娇斩，這一次任務(wù)不會進(jìn)入苍息，只會柵欄一次

6.同步函數(shù)，柵欄函數(shù)，死鎖底層源碼分析

1.同步函數(shù)dispatch_sync哮幢，柵欄函數(shù)dispatch_barrier_async底層原理
2.模擬死鎖:同步函數(shù)堵塞主線程

image.png

死鎖堆棧中信息_dispatch_sync_f_slow

image.png

當(dāng)前任務(wù)要執(zhí)行又要等待桶雀，處于矛盾中唠叛，會死鎖

image.png

image.png

死鎖只需判斷當(dāng)前要執(zhí)行的任務(wù)和要等待的任務(wù)是不是同一個任務(wù)瞎访，而不管是在主線程還是子線程中都有可能發(fā)生死鎖

7.信號量分析

很多時候GCD控制并發(fā)數(shù)比較難，可以通過設(shè)置信號量控制最大并發(fā)數(shù)瓤的，信號量設(shè)置為2,任務(wù)兩兩執(zhí)行

image.png

若信號量設(shè)置為1,則任務(wù)一個一個執(zhí)行,起到同步的效果

image.png

image.png

image.png