前语

之前,咱们在探求动画及烘托相关原理的时分,咱们输出了几篇文章,解答了iOS动画是怎么烘托,特效是怎么作业的疑问。咱们深感体系设计者在创造这些体系框架的时分,是如此脑洞大开,也 深深意识到了解一门技能的底层原理关于从事该方面作业的重要性。

因此咱们决议 进一步探求iOS底层原理的使命。继上一篇文章对GCD的 主行列、串行行列&&并行行列、大局并发行列探求之后,本篇文章将继续对GCD多线程底层原理的探求

一、 dispatch_get_global_queue大局并发行列+dispatch_sync同步函数

dq->dq_width == 1 为串行行列，那么并发行列该怎么走呢？如下图，走的是下面的框框中流程

18-探究iOS底层原理|多线程技术【GCD源码分析1:dispatch_get_global_queue与dispatch_(a)sync、单例、线程死锁】

可是这么多的分支，到底是走的哪一个呢？经过对_dispatch_sync_f_slow、 _dispatch_sync_recurse 、_dispatch_introspection_sync_begin 、_dispatch_sync_invoke_and_complete办法下符号断点，进行盯梢调试。

符号断点调试

经过下符号断点盯梢，发现走了_dispatch_sync_f_slow，如下图所示：

经过阅读源码，发现一个有意思的作业，便是_dispatch_sync_invoke_and_complete办法

_dispatch_sync_invoke_and_complete

在这个_dispatch_sync_invoke_and_complete办法的第三个参数是func 也是需求履行的使命，可是 func 的后边的全体也是一个参数，也便是 DISPATCH_TRACE_ARG( _dispatch_trace_item_sync_push_pop(dq, ctxt, func, dc_flags)) 全体为一个参数，这就有意思了，中心居然没有逗号分离隔。老铁，你这很特别啊！够长的啊！

那么去DISPATCH_TRACE_ARG界说看看

在DISPATCH_TRACE_ARG的宏界说里边，你们有没有发现，这儿居然把逗号放在了里边，好家伙，宏界说里边还能够这么玩，苹果工程师还真有意思哈！

经过大局的查找，发现这个宏界说有两处，一个有逗号，一个没有逗号，这便是依据不同的条件，进行设置，适当于是一个可选的参数，这一波操作又是十分的细节了！

既然下符号断点会走_dispatch_sync_f_slow办法，现在就去看看这个办法

_dispatch_sync_f_slow

这儿又是许多的分支，又经过下符号断点，发现走的是_dispatch_sync_function_invoke办法里边

_dispatch_sync_function_invoke

static void
_dispatch_sync_function_invoke(dispatch_queue_class_t dq, void *ctxt,
		dispatch_function_t func)
{
	_dispatch_sync_function_invoke_inline(dq, ctxt, func);
}

_dispatch_sync_function_invoke_inline

static inline void
_dispatch_sync_function_invoke_inline(dispatch_queue_class_t dq, void *ctxt,
		dispatch_function_t func)
{
	dispatch_thread_frame_s dtf;
	_dispatch_thread_frame_push(&dtf, dq);
	_dispatch_client_callout(ctxt, func);
	_dispatch_perfmon_workitem_inc();
	_dispatch_thread_frame_pop(&dtf);
}

push 之后调用callout履行，最后再 pop，所以能够同步的履行使命

二、 dispatch_async异步函数

dispatch_async异步函数的使命，是包装在 qos里边的，那么现在盯梢流程，去看看

dispatch_async

_dispatch_continuation_async

dx_push

查找dx_push调用的地方

这儿就先去看看并发行列里边的dq_push吧，

_dispatch_lane_concurrent_push

这儿if里边有对栅门函数（_dispatch_object_is_barrier）的判别，栅门函数这儿就不剖析了，后续的博客里边会剖析的。

在_dispatch_lane_concurrent_push里边会去调用_dispatch_lane_push办法，在上面查找dx_push的图里边，能够看到，在串行行列里边是直接调用了_dispatch_lane_push，也便是说串行和并发都会走这个办法。

_dispatch_lane_push

最后去调用dx_wakeup，再去查找看看

dx_wakeup 是一个宏界说，看看dq_wakeup哪里调用了

如上图能够发现，串行和并发都是_dispatch_lane_wakeup，大局的是_dispatch_root_queue_wakeup

_dispatch_queue_wakeup

经过下符号断点会走_dispatch_lane_class_barrier_complete

_dispatch_lane_class_barrier_complete里边循环递归一些操作，还看到了一个体系的函数os_atomic_rmw_loop2o，在这个办法里边要么回来dx_wakeup或许做其他的一些处理。

#define dx_push(x, y, z) dx_vtable(x)->dq_push(x, y, z)

经过跟流程和下符号断点，会走大局并发行列的_dispatch_root_queue_push办法。经过下符号断点，盯梢源码，最终定位到一个重要的办法_dispatch_root_queue_poke_slow

dispatch_root_queue_push_inline(dispatch_queue_global_t dq,
		dispatch_object_t _head, dispatch_object_t _tail, int n)
{
	struct dispatch_object_s *hd = _head._do, *tl = _tail._do;
	if (unlikely(os_mpsc_push_list(os_mpsc(dq, dq_items), hd, tl, do_next))) {
		return _dispatch_root_queue_poke(dq, n, 0);
	}
}

_dispatch_root_queue_poke

_dispatch_root_queue_poke_slow

_dispatch_root_queues_init办法使用了单例。

static inline void
_dispatch_root_queues_init(void)
{
	dispatch_once_f(&_dispatch_root_queues_pred, NULL,
	_dispatch_root_queues_init_once);
}

在该办法中，选用单例的方式进行了线程池的初始化处理、作业行列的装备、作业行列的初始化等作业。一起这儿有一个要害的设置，履行函数的设置，也便是将使命履行的函数被共同设置成了_dispatch_worker_thread2。见下图：

调用仓库验证

调用履行是经过workloop作业循环调用起来的，也便是说并不是及时调用的，而是经过os完结调用，说明异步调用的要害是在需求履行的时分能够获取对应的办法，进行异步处理，而同步函数是直接调用。

在上面的流程中_dispatch_root_queue_poke_slow 办法，还没有继续剖析，现在就去剖析，假如是大局行列，此时会创立线程进行履行使命

对线程池进行处理，从线程池中获取线程，履行使命，一起判别线程池的变化

remaining能够理解为当时可用线程数，当可用线程数等于0时，线程池已满pthread pool is full，直接return。底层经过pthread完结线程的拓荒

便是_dispatch_worker_thread2是经过pthread完结oc_atmoic原子触发

那么咱们的线程能够拓荒多少线程条呢？

行列线程池的巨细为：dgq_thread_pool_size。dgq_thread_pool_size = thread_pool_size ，默许巨细如下：

255表明理论上线程池的最大数量。可是实际能拓荒多少呢，这个不确定。在苹果官方完整Thread Management中，有相关的说明，辅助线程的最小允许仓库巨细为 16 KB，而且仓库巨细必须是4KB 的倍数。见下图：

也便是说，一个辅助线程的栈空间是512KB，而一个线程所占用的最小空间是16KB，也便是说栈空间一定的状况下，拓荒线程所需的内存越大，所能拓荒的线程数就越小。针对一个4GB内存的iOS真机来说，内存分为内核态和用户态，假如内核态悉数用于创立线程，也便是1GB的空间，也便是说最多能拓荒1024KB / 16KB个线程。当然这也只是一个理论值。

三、单例

上面提到了单例，那么接下来就去剖析一下单例来看看简略的单例使用：

   static dispatch_once_t token;
   dispatch_once(&token, ^{
       // 代码履行
   });

单例的界说如下：

void
_dispatch_once(dispatch_once_t *predicate,
		DISPATCH_NOESCAPE dispatch_block_t block)
{
	if (DISPATCH_EXPECT(*predicate, ~0l) != ~0l) {
		dispatch_once(predicate, block);
	} else {
		dispatch_compiler_barrier();
	}
	DISPATCH_COMPILER_CAN_ASSUME(*predicate == ~0l);
}
#undef dispatch_once
#define dispatch_once _dispatch_once
#endif
#endif // DISPATCH_ONCE_INLINE_FASTPATH

针对不同的状况作了一些特别处理，比如栅门函数等，这儿只剖析dispatch_once，进入dispatch_once完成

单例是只会履行一次，那么这儿便是利用 val参数来进行控制的，接着去dispatch_once_f里边看看

对l的底层原子性进行相关，相关到uintptr_t v的一个变量，经过os_atomic_load从底层取出，相关到变量v上。假如v这个值等于DLOCK_ONCE_DONE，也便是现已处理过一次了，就会直接return回来

_dispatch_once_gate_tryenter

static inline bool
_dispatch_once_gate_tryenter(dispatch_once_gate_t l)
{
	return os_atomic_cmpxchg(&l->dgo_once, DLOCK_ONCE_UNLOCKED,
			(uintptr_t)_dispatch_lock_value_for_self(), relaxed);
}

_dispatch_once_gate_tryenter里边是进行原子操作，便是锁的处理，假如之前没有履行过，原子处理会比较它状况，进行解锁，最终会回来一个bool值，多线程状况下，只要一个能够获取锁回来yes。

if (_dispatch_once_gate_tryenter(l)) {
     return _dispatch_once_callout(l, ctxt, func);
}

经过_dispatch_lock_value_for_self上了一把锁，保证多线程安全。假如回来yes，就会履行_dispatch_once_callout办法，履行单例对应的使命，并对外广播

_dispatch_once_callout

static void
_dispatch_once_callout(dispatch_once_gate_t l, void *ctxt,
		dispatch_function_t func)
{
	_dispatch_client_callout(ctxt, func);
	_dispatch_once_gate_broadcast(l);
}

_dispatch_client_callout履行使命
_dispatch_once_gate_broadcast对外广播，标记为 done
_dispatch_once_gate_broadcast广播

将token经过原子比对，假如不是done，则设为done。一起对_dispatch_once_gate_tryenter办法中的锁进行处理。

_dispatch_once_mark_done

os_atomic_cmpxchg 是一个宏界说，先进行比较再改变，先比较 dgo，在设置标记为DLOCK_ONCE_DONE也便是 done

当token标记为done之后，就会直接回来，如存在多线程处理，没有获取锁的状况，就会调用_dispatch_once_wait，如下下：

_dispatch_once_wait，进行等候，这儿开启了自旋锁，内部进行原子处理，在loop过程中，假如发现现已被其他线程设置once_done了，则会进行抛弃处理

那么使命的履行交给谁了呢？

经过打印仓库信息，发现是交给了基层的线程，经过一些包装，给了底层的pthread

这就能够说 GCD底层是封装了pthread ，不管是 iOS还是 Java都是封装了底层的通用线程机制pthread 。

这儿的履行是经过作业循环workloop,作业循环的调起受 OS（受 CPU调度履行的。）管控的，异步线程的异步体现在哪里呢？便是体现在是否能够获得，而不是当即履行，而同步函数是直接调用履行的，而这儿并没有看到异步的直接调用履行。

四、 sync 和 async 的差异

是否能够开启新的线程履行使命
使命的回调是否具有异步行、同步性
是否发生死锁问题

五、死锁源码剖析

在前面篇幅的剖析中,咱们得知,同步 sync函数的流程是:

_dispatch_sync_f — >
_dispatch_sync_f_inline — >
_dispatch_barrier_sync_f

走到_dispatch_barrier_sync_f流程中，这与上篇博客的剖析是共同的，因为这儿dq_width=1，所以是串行行列，假如是并发行列，则会走到_dispatch_sync_f_slow，现在去_dispatch_barrier_sync_f办法里边看看

_dispatch_barrier_sync_f

static void
_dispatch_barrier_sync_f(dispatch_queue_t dq, void *ctxt,
		dispatch_function_t func, uintptr_t dc_flags)
{
	_dispatch_barrier_sync_f_inline(dq, ctxt, func, dc_flags);
}

这个办法又会调用_dispatch_barrier_sync_f_inline办法

在这个办法里边，会对行列进行判别，是否存在等候或许挂起状况

//判别是否挂起、等候
if (unlikely(!_dispatch_queue_try_acquire_barrier_sync(dl, tid))){
    // 添加使命
    return _dispatch_sync_f_slow(dl, ctxt, func, DC_FLAG_BARRIER, dl,
				DC_FLAG_BARRIER | dc_flags);
}

在之前的博客里边也提到了死锁相关的内容，呈现死锁会报和_dispatch_sync_f_slow相关的错误，如下：

虽然死锁会走_dispatch_sync_f_slow办法，可是死锁的报错不是_dispatch_sync_f_slow这个报错，而是如下图中所示的0处报错了

真报错的是__DISPATCH_WAIT_FOR_QUEUE__，那么现在去验证一下

_dispatch_sync_f_slow

在_dispatch_sync_f_slow办法内部，咱们发现了刚刚死锁报错的__DISPATCH_WAIT_FOR_QUEUE__，现在去内部看看

__DISPATCH_WAIT_FOR_QUEUE__

在__DISPATCH_WAIT_FOR_QUEUE__内部，发现了和死锁报错信息基本一样，意思是：

dispatch_sync 在当时线程现已具有的行列上调用，对不住兄弟，我现已具有她了，你来晚一步了

if (unlikely(_dq_state_drain_locked_by(dq_state, dsc->dsc_waiter))) {
		DISPATCH_CLIENT_CRASH((uintptr_t)dq_state,
				"dispatch_sync called on queue "
				"already owned by current thread");
}

这个dsc_waiter是由前面_dispatch_sync_f_slow办法里边传过来来的

_dispatch_tid_self()是线程 id，界说如下

_dispatch_thread_port是线程的通道，现在再去看看线程状况的匹配

//状况
uint64_t dq_state = _dispatch_wait_prepare(dq);
if (unlikely(_dq_state_drain_locked_by(dq_state, dsc->dsc_waiter))) {
        DISPATCH_CLIENT_CRASH((uintptr_t)dq_state,
                "dispatch_sync called on queue "
                "already owned by current thread");
}

_dq_state_drain_locked_by

static inline bool
_dq_state_drain_locked_by(uint64_t dq_state, dispatch_tid tid)
{
	return _dispatch_lock_is_locked_by((dispatch_lock)dq_state, tid);
}

_dispatch_lock_is_locked_by

static inline bool
_dispatch_lock_is_locked_by(dispatch_lock lock_value, dispatch_tid tid)
{
	// equivalent to _dispatch_lock_owner(lock_value) == tid
	return ((lock_value ^ tid) & DLOCK_OWNER_MASK) == 0;
}

DLOCK_OWNER_MASK

#define DLOCK_OWNER_MASK			((dispatch_lock)0xfffffffc)

这儿便是死锁的判别：异或再作与操作，也便是成果为0便是死锁。翻译一下便是dq_state ^ dsc->dsc_waiter 的成果为 0再和DLOCK_OWNER_MASK作与操作等于0。

那么dq_state ^ dsc->dsc_waiter 的成果什么状况下会为 0呢？异或是相同为0，因为DLOCK_OWNER_MASK是一个十分大的整数，所以dq_state 和 dsc->dsc_waiter 都是为0。

当时行列里边要等候的线程 id 和我调用的是一样，我现已处于等候状况，你现在有新的使命过来需求使用我去履行，这样发生了对立，进入相互等候状况，从而发生死锁。这便是串行行列履行同步使命发生死锁的原因！

专题系列文章

1.前常识

01-探求iOS底层原理|总述
02-探求iOS底层原理|编译器LLVM项目【Clang、SwiftC、优化器、LLVM】
03-探求iOS底层原理|LLDB
04-探求iOS底层原理|ARM64汇编

2. 根据OC言语探求iOS底层原理

05-探求iOS底层原理|OC的实质
06-探求iOS底层原理|OC目标的实质
07-探求iOS底层原理|几种OC目标【实例目标、类目标、元类】、目标的isa指针、superclass、目标的办法调用、Class的底层实质
08-探求iOS底层原理|Category底层结构、App启动时Class与Category装载过程、load 和 initialize 履行、相关目标
09-探求iOS底层原理|KVO
10-探求iOS底层原理|KVC
11-探求iOS底层原理|探求Block的实质|【Block的数据类型(实质)与内存布局、变量捕获、Block的种类、内存办理、Block的修饰符、循环引证】
12-探求iOS底层原理|Runtime1【isa详解、class的结构、办法缓存cache_t】
13-探求iOS底层原理|Runtime2【消息处理(发送、转发)&&动态办法解析、super的实质】
14-探求iOS底层原理|Runtime3【Runtime的相关使用】
15-探求iOS底层原理|RunLoop【两种RunloopMode、RunLoopMode中的Source0、Source1、Timer、Observer】
16-探求iOS底层原理|RunLoop的使用
17-探求iOS底层原理|多线程技能的底层原理【GCD源码剖析1:主行列、串行行列&&并行行列、大局并发行列】
18-探求iOS底层原理|多线程技能【GCD源码剖析1:dispatch_get_global_queue与dispatch_(a)sync、单例、线程死锁】
19-探求iOS底层原理|多线程技能【GCD源码剖析2:栅门函数dispatch_barrier_(a)sync、信号量dispatch_semaphore】
20-探求iOS底层原理|多线程技能【GCD源码剖析3:线程调度组dispatch_group、事件源dispatch Source】
21-探求iOS底层原理|多线程技能【线程锁：自旋锁、互斥锁、递归锁】
22-探求iOS底层原理|多线程技能【原子锁atomic、gcd Timer、NSTimer、CADisplayLink】
23-探求iOS底层原理|内存办理【Mach-O文件、Tagged Pointer、目标的内存办理、copy、引证计数、weak指针、autorelease

3. 根据Swift言语探求iOS底层原理

关于函数、枚举、可选项、结构体、类、闭包、特点、办法、swift多态原理、String、Array、Dictionary、引证计数、MetaData等Swift基本语法和相关的底层原理文章有如下几篇:

Swift5中心语法1-根底语法
Swift5中心语法2-面向目标语法1
Swift5中心语法2-面向目标语法2
Swift5常用中心语法3-其它常用语法
Swift5使用实践常用技能点

其它底层原理专题

1.底层原理相关专题

01-计算机原理|计算机图形烘托原理这篇文章
02-计算机原理|移动终端屏幕成像与卡顿

2.iOS相关专题

01-iOS底层原理|iOS的各个烘托框架以及iOS图层烘托原理
02-iOS底层原理|iOS动画烘托原理
03-iOS底层原理|iOS OffScreen Rendering 离屏烘托原理
04-iOS底层原理|因CPU、GPU资源消耗导致卡顿的原因和解决计划

3.webApp相关专题

01-Web和类RN大前端的烘托原理

4.跨渠道开发计划相关专题

01-Flutter页面烘托原理

5.阶段性总结:Native、WebApp、跨渠道开发三种计划功能比较

01-Native、WebApp、跨渠道开发三种计划功能比较

6.Android、HarmonyOS页面烘托专题

01-Android页面烘托原理
02-HarmonyOS页面烘托原理 (待输出)

7.小程序页面烘托专题

01-小程序框架烘托原理

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。

18-探究iOS底层原理|多线程技术【GCD源码分析1:dispatch_get_global_queue与dispatch_(a)sync、单例、线程死锁】

前语

一、 dispatch_get_global_queue大局并发行列+dispatch_sync同步函数

二、 dispatch_async异步函数

三、单例

四、 sync 和 async 的差异

五、死锁源码剖析

专题系列文章

1.前常识

2. 根据OC言语探求iOS底层原理

3. 根据Swift言语探求iOS底层原理

其它底层原理专题

1.底层原理相关专题

2.iOS相关专题

3.webApp相关专题

4.跨渠道开发计划相关专题

5.阶段性总结:Native、WebApp、跨渠道开发三种计划功能比较

6.Android、HarmonyOS页面烘托专题

7.小程序页面烘托专题

近期文章

近期评论

18-探究iOS底层原理|多线程技术【GCD源码分析1:dispatch_get_global_queue与dispatch_(a)sync、单例、线程死锁】

前语

一、 dispatch_get_global_queue大局并发行列+dispatch_sync同步函数

二、 dispatch_async异步函数

三、 单例

四、 sync 和 async 的差异

五、 死锁 源码剖析

专题系列文章

1.前常识

2. 根据OC言语探求iOS底层原理

3. 根据Swift言语探求iOS底层原理

其它底层原理专题

1.底层原理相关专题

2.iOS相关专题

3.webApp相关专题

4.跨渠道开发计划相关专题

5.阶段性总结:Native、WebApp、跨渠道开发三种计划功能比较

6.Android、HarmonyOS页面烘托专题

7.小程序页面烘托专题

近期文章

近期评论

三、单例

五、死锁源码剖析