iOS底层 GCD - 一进一出 便成 调度组

这是我参与8月更文挑战的第16天，活动详情查看：8月更文挑战

写在前面： iOS底层原理探究是本人在平时的开发和学习中不断积累的一段进阶之
路的。 记录我的不断探索之旅，希望能有帮助到各位读者朋友。

目录如下：

1. iOS 底层原理探索 之 alloc
2. iOS 底层原理探索 之 结构体内存对齐
3. iOS 底层原理探索 之 对象的本质 & isa的底层实现
4. iOS 底层原理探索 之 isa - 类的底层原理结构（上）
5. iOS 底层原理探索 之 isa - 类的底层原理结构（中）
6. iOS 底层原理探索 之 isa - 类的底层原理结构（下）
7. iOS 底层原理探索 之 Runtime运行时&方法的本质
8. iOS 底层原理探索 之 objc_msgSend
9. iOS 底层原理探索 之 Runtime运行时慢速查找流程
10. iOS 底层原理探索 之 动态方法决议
11. iOS 底层原理探索 之 消息转发流程
12. iOS 底层原理探索 之 应用程序加载原理dyld （上）
13. iOS 底层原理探索 之 应用程序加载原理dyld （下）
14. iOS 底层原理探索 之 类的加载
15. iOS 底层原理探索 之 分类的加载
16. iOS 底层原理探索 之 关联对象
17. iOS底层原理探索 之 魔法师KVC
18. iOS底层原理探索 之 KVO原理｜8月更文挑战
19. iOS底层原理探索 之 重写KVO｜8月更文挑战
20. iOS底层原理探索 之 多线程原理｜8月更文挑战
21. iOS底层原理探索 之 GCD函数和队列
22. iOS底层原理探索 之 GCD原理（上）
23. iOS底层 - 关于死锁，你了解多少？
24. iOS底层 - 单例 销毁 可否 ？
25. iOS底层 - Dispatch Source
26. iOS底层 - 一个栅栏函 拦住了 数
27. iOS底层 - 不见不散 的 信号量

---

以上内容的总结专栏

• iOS 底层原理探索 之 阶段总结

---

细枝末节整理

• iOS开发 细节整理总结

---

前言

在之前的 iOS底层原理探索 之 GCD原理（上） 篇章中，我们重点对 GCD的函数和队列、 GCD的底层数据结构、同步函数底层调用和异步函数底层调用进行了深入的分析。 而 在 后续的 关于死锁，你了解多少？、 销毁 一个 单例、 Dispatch Source 三篇分别对 GCD 使用中导致死锁的问题 、 单例底层实现逻辑 和 Dispatch Source 的应用内容。 今天，我们再来研究一下 GCD 部分的 栅栏函数底层实现，信号量和调度组的应用。 也算是 GCD 篇章的一个结尾。好的，下面就开始今天的内容。

调度组

调度组最直接的作用就是 控制任务执行顺序

调度组的使用

• dispatch_group_create ： 创建调度组
• dispatch_group_async ： 进组任务
• dispatch_group_notify ： 进组任务执行完毕通知
• dispatch_group_wait ： 进组任务执行等待时间

搭配使用

• dispatch_group_enter ： 进组
• dispatch_group_leave ： 出组

例子

    // 自定义并发队列
    dispatch_queue_t queue = dispatch_queue_create("superman", DISPATCH_QUEUE_CONCURRENT);

    // 创建组
    dispatch_group_t group = dispatch_group_create();
    
    // 添加任务
    for (int i = 0; i < 5; i++) {
        
        dispatch_group_async(group, queue, ^{
            NSLog(@"开始执行任务 -- %d", i);
            
            sleep(2);
            NSLog(@"任务-%d执行完毕", i);
        });
        
    }
    
    // 添加任务
    for (int i = 0; i < 3; i++) {
    
        dispatch_group_enter(group);
        dispatch_async(queue, ^{
            NSLog(@"开始执行终极任务 -- %d", i);
            
            sleep(1);
            NSLog(@"终极任务-%d执行完毕", i);
            
            dispatch_group_leave(group);
        });
    }
    
    // 任务执行完毕回调
    dispatch_group_notify(group, queue, ^{
       
        NSLog(@"任务都执行完了哦");
        
    });

我们发现 dispatch_group_async = dispatch_group_enter + dispatch_group_leave， 不知你有没有发现，并且 出组 进组 搭配不对称的话，会奔溃掉。并且调度组是如何来实现所有的任务都执行完毕再执行最后的通知的呢？带着这些疑问，我们看下其内部实现是怎样的。

dispatch_group_create

dispatch_group_t
dispatch_group_create(void)
{
	return _dispatch_group_create_with_count(0);
}

_dispatch_group_create_with_count

static inline dispatch_group_t
_dispatch_group_create_with_count(uint32_t n)
{
	dispatch_group_t dg = _dispatch_object_alloc(DISPATCH_VTABLE(group),
			sizeof(struct dispatch_group_s));
	dg->do_next = DISPATCH_OBJECT_LISTLESS;
	dg->do_targetq = _dispatch_get_default_queue(false);
	if (n) {
		os_atomic_store2o(dg, dg_bits,
				(uint32_t)-n * DISPATCH_GROUP_VALUE_INTERVAL, relaxed);
		os_atomic_store2o(dg, do_ref_cnt, 1, relaxed); // <rdar://22318411>
	}
	return dg;
}

...

#define os_atomic_store2o(p, f, v, m) \
os_atomic_store(&(p)->f, (v), m)

...

#define os_atomic_store(p, v, m) \
atomic_store_explicit(_os_atomic_c11_atomic(p), v, memory_order_##m)
...

#define atomic_store_explicit __c11_atomic_store

-------

在头文件<stdatomic.h>中定义                                                     
| --------------------------------------------------------------------------- 
| void atomic_store（volatile A * obj，需要C）;                                 

原子替换`obj`指向的原子变量的值`desired`。该操作是原子写入操作。

------

dispatch_group_enter

void
dispatch_group_enter(dispatch_group_t dg)
{
	// The value is decremented on a 32bits wide atomic so that the carry
	// for the 0 -> -1 transition is not propagated to the upper 32bits.
	uint32_t old_bits = os_atomic_sub_orig2o(dg, dg_bits,
			DISPATCH_GROUP_VALUE_INTERVAL, acquire);
	uint32_t old_value = old_bits & DISPATCH_GROUP_VALUE_MASK;
	if (unlikely(old_value == 0)) {
		_dispatch_retain(dg); // <rdar://problem/22318411>
	}
	if (unlikely(old_value == DISPATCH_GROUP_VALUE_MAX)) {
		DISPATCH_CLIENT_CRASH(old_bits,
				"Too many nested calls to dispatch_group_enter()");
	}
}

dispatch_group_leave

void
dispatch_group_leave(dispatch_group_t dg)
{
	// 该值在64位宽的原子上递增
	// the -1 -> 0 转换以原子的方式递增生成
	uint64_t new_state, old_state = os_atomic_add_orig2o(dg, dg_state,
			DISPATCH_GROUP_VALUE_INTERVAL, release);
	uint32_t old_value = (uint32_t)(old_state & DISPATCH_GROUP_VALUE_MASK);

	if (unlikely(old_value == DISPATCH_GROUP_VALUE_1)) {
		old_state += DISPATCH_GROUP_VALUE_INTERVAL;
		do {
			new_state = old_state;
			if ((old_state & DISPATCH_GROUP_VALUE_MASK) == 0) {
				new_state &= ~DISPATCH_GROUP_HAS_WAITERS;
				new_state &= ~DISPATCH_GROUP_HAS_NOTIFS;
			} else {
				// If the group was entered again since the atomic_add above,
				// we can't clear the waiters bit anymore as we don't know for
				// which generation the waiters are for
				new_state &= ~DISPATCH_GROUP_HAS_NOTIFS;
			}
			if (old_state == new_state) break;
		} while (unlikely(!os_atomic_cmpxchgv2o(dg, dg_state,
				old_state, new_state, &old_state, relaxed)));
                                
                // 唤醒的是 notify
		return _dispatch_group_wake(dg, old_state, true);
	}

	if (unlikely(old_value == 0)) {
		DISPATCH_CLIENT_CRASH((uintptr_t)old_value,
				"Unbalanced call to dispatch_group_leave()");
	}
}

...

#define DISPATCH_GROUP_GEN_MASK         0xffffffff00000000ULL
#define DISPATCH_GROUP_VALUE_MASK       0x00000000fffffffcULL
#define DISPATCH_GROUP_VALUE_INTERVAL   0x0000000000000004ULL
#define DISPATCH_GROUP_VALUE_1          DISPATCH_GROUP_VALUE_MASK
#define DISPATCH_GROUP_VALUE_MAX        DISPATCH_GROUP_VALUE_INTERVAL
#define DISPATCH_GROUP_HAS_NOTIFS       0x0000000000000002ULL
#define DISPATCH_GROUP_HAS_WAITERS      0x0000000000000001ULL

最后，如果 old_value 和 DISPATCH_GROUP_VALUE_1 相等， 最后会唤醒 notify 的执行。

dispatch_group_async

void
dispatch_group_async(dispatch_group_t dg, dispatch_queue_t dq,
		dispatch_block_t db)
{
	dispatch_continuation_t dc = _dispatch_continuation_alloc();
	uintptr_t dc_flags = DC_FLAG_CONSUME | DC_FLAG_GROUP_ASYNC;
	dispatch_qos_t qos;

	qos = _dispatch_continuation_init(dc, dq, db, 0, dc_flags);
	_dispatch_continuation_group_async(dg, dq, dc, qos);
}

代码执行来到了 _dispatch_continuation_group_async

_dispatch_continuation_group_async

在这里调用了 dispatch_group_enter()

static inline void
_dispatch_continuation_group_async(dispatch_group_t dg, dispatch_queue_t dq,
		dispatch_continuation_t dc, dispatch_qos_t qos)
{
	dispatch_group_enter(dg);
	dc->dc_data = dg;
	_dispatch_continuation_async(dq, dc, qos, dc->dc_flags);
}

那么，在调用完block执行后，才会有 leave 的调用所以，我们在 自定义并发队列执行的最后 找到了leave：

static inline void
_dispatch_continuation_with_group_invoke(dispatch_continuation_t dc)
{
	struct dispatch_object_s *dou = dc->dc_data;
	unsigned long type = dx_type(dou);
	if (type == DISPATCH_GROUP_TYPE) {
		_dispatch_client_callout(dc->dc_ctxt, dc->dc_func);
		_dispatch_trace_item_complete(dc);
		dispatch_group_leave((dispatch_group_t)dou);
	} else {
		DISPATCH_INTERNAL_CRASH(dx_type(dou), "Unexpected object type");
	}
}

这也就解释了为什么 dispatch_group_async 使用后 有 dispatch_group_enter + dispatch_group_leave 的效果。

总结

GCD篇章的更文，到这里算是告一段落了。在GCD的系列文章中，

• 我们从 iOS底层原理探索 之 GCD函数和队列 了解了队列与函数的关系；
• 接着 在 iOS底层原理探索 之 GCD原理（上） 中我们了解了GCD的数据结构，以及 同步函数和异步函数调起任务的底层实现；
• 接下来，我们通过 iOS底层 - 关于死锁，你了解多少？ 探索 了 在使用 GCD 时， 串行队列 同步函数调起任务中，可能会引起的死锁问题，我们对死锁问题发生的本质是有了了解；
• 接着，在 iOS底层 - 单例 销毁 可否 ？ 中，我们探索了在日常开发中使用的单例模式的底层实现原理进行了分析，并且扩展了如何对其销毁；
• 再接着，在 iOS底层 - Dispatch Source探索中，我们我们探索了其对于事件的处理器使用，并且自定义了一个Timer 还是很好用的；
• 接着就是 iOS底层 - 一个栅栏函 拦住了 数 对于栅栏函数的探索理解，在队列中执行的底层探索；
• 接着便来到了 iOS底层 - 不见不散 的 信号量对于信号量的使用分析和底层探索；
• 最终，今天我们对于调度组的使用和底层进行了一个探索。这系列内容探索下来，对于GCD内容的探索算是一个结尾吧。

大家， 加油！！