《iOS底层原理文章汇总》
上一篇文章《iOS-底层原理25-GCD(下)》介绍了GCD单例，栅栏函数，同步函数，信号量底层原理，本文接着介绍GCD调度组合dispatch_source以及锁

1.调度组:dispatch_group_enter和dispatch_group_leave要成对出现,如下载两张图片完成后更新UI,两个异步线程任务会进入同一个组，只有等两个线程任务都leave之后才会进行通知

image.png

image.png

若将通知移到前面dispatch_group_notify并不需要保证两个线程组任务都完成,只需保证enter和leave是成对出现的就OK，不管远近

image.png

image.png

若多写一个dispatch_group_leave,则会崩溃,奔溃的位置dispatch_group_leave(group)会最后执行，因为里面的任务有延迟sleep(1)

image.png

image.png

image.png

image.png

2.dispatch_source:有很多种类型如DISPATCH_SOURCE_TYPE_DATA_ADD,DISPATCH_SOURCE_TYPE_DATA_REPLACE,DISPATCH_SOURCE_TYPE_TIMER等并不依赖与runloop,和下层内核workLoop进行交互，调用时DISPATCH_SOURCE_TYPE_TIMER会很准确

image.png

image.png

image.png

3.信号量

image.png

4.锁的性能

• 1.在全局并发队列里面买票，若不能保证原子性同步状态，会发生票絮乱，加上同步锁后，保证数据的原子性

  
  
  image.png

• 2.@synchronized(self)底层原理,先符号断点查看汇编信息发现有两个标记位一个是objc_sync_enter,一个是objc_sync_exit

  
  
  image.png
  
  
  image.png

• 3.clang查看@synchronized(self)源码,objc_sync_enter(_sync_obj)和objc_sync_exit(_sync_obj)分别在哪个源码里面呢？继续看汇编发现源码在libobjc.A.dylib

  
  
  image.png
  
  
  image.png

• 4.递归锁是一种带有递归性质的互斥锁,进入objc_sync_enter和objc_sync_exit源码分析

  
  
  image.png

• I.obj为nil的情况，objc_sync_nil(),下符号断点objc_sync_nil,传入的obj为nil，则什么都没做

  
  
  image.png
  
  
  image.png
  
  
  image.png
  
  
  image.png
  
  
  image.png

• II.objc_sync_enter中obj不为nil的情况SyncData* data = id2data(obj,ACQUIRE)进行data->mutex.lock(),在objc_sync_enter中obj不为nil的情况下进行data->mutex.tryUnlock()解锁,加锁与解锁成对存在

  
  
  image.png
  
  
  image.png

• 递归互斥锁:recursive_mutex_t
• 嵌套 - 可重入 - 递归

• lockCount
  enter:lockCount++,通过lockCount判断任务代码块被锁了多少次,间接验证可嵌套(可重入),可重复被锁

  
  
  image.png

objc_sync_enter : lock
objc_sync_enter : unlock

static SyncData* id2data(id object, enum usage why)底层原理分析

image.png

objc_sync_enter和objc_sync_exit会分别调用SyncData* data = id2data(obj, ACQUIRE)和SyncData* data = id2data(obj, RELEASE)传入ACQUIRE、RELEASE对应lockCount++、lockCount--进行代码复用,代码进出都会调用

image.png

image.png

image.png

若要获取哪个线程的哪个SyncData，需先找到下标,第一次进来后发现result有值，后面就会将*listP赋值给result->nextData

image.png

image.png

image.png

image.png

image.png

2.不是第一次，同一个线程:第二次进入在栈存缓存中能找到,lockCount++,1+1又存到栈存缓存中去

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png

5.@synchronize坑点:@synchronized(self) : 性能 + objc 生命周期,enter 找节点 objc : 查找非常麻烦 - self

1.性能低，链表的查询，缓存下层的代码不断的查找,锁self的节点过多，链表查询变慢

image.png

2.多线程操作数据程序崩溃:_testArray = [NSMutableArray array]相当于进行setter操作，对新值retain,对旧值进行release,某一瞬间同时两个线程对_testArray指向的区域进行release操作，但只进行了一次retain操作，retainCount只为1，不够减，形成野指针,造成崩溃

image.png

image.png

image.png

查看是否为野指针,通过添加Zombie Objects，解决办法是加锁，可以加@synchronized,若用_testArray为锁中的对象，则不能，_testArray还有可能为空，锁self是可以的，为什么呢？self持有testArray,若self释放了为nil,则testArray必定释放了,self伴随了testArray整个生命周期

image.png

image.png

image.png

image.png

还可以用NSLock进行加锁,还有其他锁的类型且看下篇文章分析

image.png