不管在哪门开发语言中，多线程都是绕不过去的开发方式。多线程本身也不是开发语言的一部分，只是开发语言会对多线程进行语言级别的包装。
多线程属于计算机原理的一部分。每个应用都需要操作系统分配一个进程后才能在进程中执行，为了实现并发效果，才有了多进程方案。而进程切换开销太大，这才有了多线程方案。乃至于多线程也是有不小的内存和 CPU 开销，后面的协程才开始起家。
但是协程已经不属于计算机的范畴，协程是单线程的，需要语言级别实现的。有些语言并没有实现协程，也只能使用多线程的方案对 CPU 资源进行深一步的榨干。

像 iOS 开发里面，每个应用都是独立的沙盒，官方并没有提供多进程的方案 (操作系统级别肯定要支持)，也没有提供协程方案，如果想更有效的利用 CPU 资源，只能从多线程上面入手。

iOS 里面多线程虽然理解起来有点绕，尤其任务和队列嵌套的时候。但只要多使用几次并加以过程分析，多线程的使用也就能很好的过关了。因为 GCD 本身已经对多线程有了非常棒对封装，只要不自己作死，串型队列和同步任务一起处理的时候小心一些，就不会出现队列等待导致死锁。即使死锁了，像这样的系统中断性问题，也很容易排查和处理。

那多线程，难点在哪里呢？显然不是 Api 级别的多线程接口调用。

移动端界面开发，要保障不出现重大事故，很大程度上不在于 UI。因为 UI 是寄托于数据展示的，只要数据不出现大问题，UI 都是写好的机器代码，基本不会出问题。
但如果数据有间歇性的不稳定，那么对于 App 来说就是一个隐藏的地雷，因为谁也不知道哪个时刻会发生数组越界，或者数据为空。
所以，数据的稳定性和完整性，非常重要。

在多线程情况下，我们会操作 UI 吗？显然不会，多线程更多处理的都是数据。所以多线程难点可以从数据下手。如果多线程情况下数据的可靠性无法保证，宁愿放弃多线程 (FMDB 就是一个例子)。
多线程情况下，数据的稳定性和完整性的保障，很复杂吗？其实也并不复杂，因为就两个要素点：原子性粒度的大小和锁。
原子性粒度的大小，不会太难控，有些编程经验，不会处理的太差。
而锁机制翻来覆去就那些，系统能够支持的甚至更少。在 Java 里面就有很多不同的锁，在 iOS 里面算来算去就那么几个，还是新瓶装旧酒。

那多线程，难点主要在哪里呢？其实还是数据。难点在于数据的处理！复杂度上的消耗，计算机时间片的消耗。
多线程编程，最终考量的其实是数据结构和算法！

对于上面的诸多观点，下面一一进行分析：

GCD 线程操作的理解

iOS 下面，官方提供的多线程方案有 Pthreads、NSThread、GCD、NSOperation。

Pthreads 是完全 C 开发的，相关函数调用感觉会非常小巧，感受一下，如pthread_create(x ...)，pthread_exit(NULL)这样。我一直很喜欢这种面向过程式的函数调用开发方式，显然这样的函数也是和面向对象格格不入的。
NSThread 是对 Pthreads 的 OC 封装，方便使用了一些。但是他们两个都需要自行管理线程生命周期。既然已经面向对象开发，连内存都可以自动释放了，我们还是应该使用更加一体化的多线程方式，那就是 GCD 和 NSOperation。

NSOperation 将多线程的面向对象更加具体化，在处理比较复杂和大型的多线程场景下，非常适用，因为代码理解性和可读性非常高。
其实，iOS 开发人员使用的基本都是 GCD，无出其右。因为工作场景下，GCD 完全可以完成多线程任务了，性能也足够好，使用又方便，代码简短易懂。如果不是复杂和大型的多线程场景，基本也不会去用 NSOperation。
而且 GCD 还有一个大杀器，那就是线程安全锁。GCD 将多线程操作和线程安全都涵盖了，我们可以很方便的使用dispatch_barrier_async写出读写锁，也可以使用dispatch_semaphore写出二元和多元信号量锁。
可以说，使用 GCD，把多线程开发的大部分问题一套带走了。当然还有一个没有带走的，就是上面提到的 “数据结构和算法”。

很多人对 GCD 理解困难，其实是被三个方面困住了。一个是不理解队列这种数据结构，一个是不理解任务这种执行方式，一个是不写代码进行测试和分析执行过程。

同步任务和异步任务

一个任务是同步还是异步，是依靠线程的。因为我们函数执行过程中，只可能在一个线程里面执行。如果是同步任务，那么不可能换线程，如果是异步任务，那么必须要换线程。
函数执行是一个函数调用执行栈空间，通过 rbp 和 rsp 两个寄存器不断上下移动栈指针位置来实现的。而一个函数调用执行栈就专属于一个线程。
如果是同步任务，只能在当前函数调用栈执行，所以开启不了新线程。
如果是异步任务，必须要脱离当前函数调用栈，必须要开启新线程。(不开启新线程也可以，就是协程方案。但是 OC 不支持协程，所以只能开启新线程。)

同步任务要点：

1. 同步任务立刻被放入队尾（但是不一定立刻执行，因为队列里面可能已经有任务 X 和 Y，则必须等 X 和 Y 出队 [如果是同步任务还必须执行完] 后才能执行被放入队尾的同步任务）。
2. 同步任务一定要被执行完后才能继续后面的代码执行。
3. 不具备开启新线程能力。同步任务被调用的时候在 A 线程，执行也一定在 A 线程。

异步任务要点：

1. 异步任务立刻被放入队尾（但是不一定立刻执行，因为队列里面可能已经有任务 X 和 Y，则必须等 X 和 Y 出队后才能执行被放入队尾的异步任务）。
2. 异步任务因为肯定会开启新线程，所以后续代码立刻执行。
3. 具备开启新线程能力，而且一定要开启。但是开启线程数量由队列决定。异步任务被调用的时候在 A 线程，执行一定不在 A 线程。

串行队列和并发队列

队列 (Queue) 是非常基本的数据结构，基于数组或者链表这两种物理结构实现。队列它的特点就是：外部数据从队尾入队，内部数据从队头出队。
比如这个队列：队尾->A->B->C->队头，如果现在加入外部数据D，那么 D 只能添加在 A 的后面，想插队添加到指定 index 是不可能的。而如果内部数据想被删除，只能先删除 C，然后才能继续删除 B 和 A。想插队删除元素，也不可能。

串行队列要点：

1. 允许开启线程，最多开启 1 个线程，是否开启线程由任务决定。
2. 所有任务必须依次出队，必须上一个出队的任务处理完，下一个任务才允许出队并执行。

并发队列要点：

1. 允许开启线程，可以开启多个线程 (100 以上都有可能，依靠系统调度)，是否开启线程由任务决定。
2. 所有任务必须依次出队，但是下一个任务出队不需要上一个任务执行完。

用上面 ABC 队列举例，如果 A、B、C 任务分别需要执行 10s。
相关伪代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// 被外界业务调用的函数
- (void)test {
    /*
     ...
     这里有业务代码执行，标记这块区域为X，此时X执行代码所在线程我们假设为thread_1。（thread_1也就是当前test函数被执行所在的线程。）
     ...
     */
    dispatch_queue_t queue = 队列;
    任务C(queue, ^{
        [NSThread sleepForTimeInterval:10];
    });
    任务B(queue, ^{
        [NSThread sleepForTimeInterval:2];
    });
    任务A(queue, ^{
        [NSThread sleepForTimeInterval:2];
    });
    /*
     ...
     这里有业务代码执行，标记这块区域为Y，此时Y执行代码一定也在thread_1线程
     ...
     */
}

在串行队列下有下面可能：

1. X 为 thread1，任务为 thread1，执行过程为：X_thread1->(C->10s 后 ->B->10s 后 ->A->10s 后)_thread1->Y_thread1（A、B、C 均为同步任务）
2. X 为 thread1，任务为 thread2，执行过程为：X_thread1->(C->10s 后 ->B->10s 后 ->A->10s 后)_thread2->Y_thread1（A、B、C 均为异步任务）
3. X 为 thread1，任务为 thread1 和 thread2，执行过程为：X_thread1->(C->10s 后)_thread1->(B)_thread2->(A->10s 后)_thread1->Y_thread1（A、C 均为同步任务，B 异步）
   1. 分析一下：因为 C 是同步任务，所以必须 C 执行 10s 后，后面的任务才能出队。因为 B 是异步任务，所以 C 执行完后，B 先出队，但 A 不用等 B 执行完即可出队执行。所以 B 和 A 可以说是并发执行的。
   2. A 出队后，只有当 A 被执行完成，后面的业务代码才能继续执行。

在并发队列下有下面可能：

1. X 为 thread1，任务为 thread1，执行过程为：X_thread1->(C->10s 后 ->B->10s 后 ->A->10s 后)_thread1->Y_thread1（A、B、C 均为同步任务）
2. X 为 thread1，任务为 threadx，执行过程为：X_thread1->Y_thread1->(C)_threadx->(B)_threadx->(A)_threadx（A、B、C 均为异步任务）
   1. 分析一下：首先 ABC 都是异步任务，在并发队列里面都会开启新线程，所以 X 执行完后把 ABC 添加到队列后，不会等 ABC 的执行过程，直接就会执行 Y 了。为什么呢？因为 ABC 在其他线程，由其他线程负责执行，ABC 的代码执行调用栈都不在 thread1 上面，而是在他们各自对应的线程。
   2. 其次，ABC 三个任务，C 会先出队，然后是 B，然后是 A。他们出队顺序是固定的，但是因为他们各自在各自的执行线程，所以执行的先后顺序是不确定的。
   3. ABC 是否开启多个线程有系统决定。如果系统开启 3 个线程，那么 ABC 会各自在自己的线程执行，没有先后顺序。如果系统仅仅开启 2 个线程，那么 A 会被分配到 C 或者 B 的执行线程，这个时候 A 就必须要等 C 或者 B 执行完才能执行（代码执行依靠调用栈，当前在执行 C 或者 B，就不可能执行 A，只能等 C 或者 B 执行完，当前调用栈结束，才能继续执行 A）。
3. X 为 thread1，任务为 thread1 和 thread2，执行过程为：X_thread1->(C->10s 后)_thread1->(B)_thread2->(A->10s 后)_thread1->Y_thread1（A、C 均为同步任务，B 异步）
   1. 分析过程和串行队列一致

上面的结果都只是一小部分。因为任务可能会有多个同步和异步穿插，所以整体执行过程会更复杂 (如 A 同步 + B 异步 + C 同步 + D 异步等)。但只要记住上面同步异步及串行并发的要点部分，整体抽丝剥茧来分析，过程并不难理解。

多写测试代码多分析

多写一些测试代码并分析过程，GCD 的内容很快就能理解。
多写一些串行队列嵌套同步任务，很容易出现死锁，很快就能根据上面的几个要点分析出来死锁原因。
所以死锁和主队列没多大关系，只要是串行队列嵌套同步任务，都可能出现死锁。
主队列就是串行队列的特殊形式，因为主队列比串行队列更严苛，主队列不能开启新线程，只能在主线程运行，这就是主队列的要点，其他和串行队列一致。

比如下面这个多线程代码分析：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// 被外界业务调用的函数
- (void)test {
    /*
     ...
     这里有业务代码执行，标记这块区域为X，此时X执行代码所在线程我们假设为thread_1。（thread_1也就是当前test函数被执行所在的线程。）
     ...
     */
    dispatch_queue_t queue = dispatch_queue_create("", DISPATCH_QUEUE_SERIAL);
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        // C
        dispatch_sync(queue, ^{
            [NSThread sleepForTimeInterval:1];
        });
    });
    // B
    dispatch_async(queue, ^{
        [NSThread sleepForTimeInterval:2];
    });
    // A
    dispatch_sync(queue, ^{
        [NSThread sleepForTimeInterval:2];
    });
    /*
     ...
     这里有业务代码执行，标记这块区域为Y，此时Y执行代码一定也在thread_1线程
     ...
     */
}

它的执行流程是：X_thread1->(C->1s)_thread1->(B->2s->C->2s)_thread1->Y_thread1。
分析：C 被异步加入到串行队列里面，所以这个时候队列里面已经有 C。因为 C 是异步加入的，所以 B 代码也会立刻执行并被立刻加入串行队列。但是 B 没有办法执行，因为 C 需要 1s 才能执行完成。当 1s 过后，B 才能出队并执行。所以代码会在 B 处停 3s 然后才能将 A 加入队列并执行。

多线程数据处理之原子性粒度

如果上面 GCD 你已经能够熟练的分析并使用了，可能会有种大悟的感觉，原来多线程也不过如此。
可千万不要认为，上面 GCD 的使用，就是多线程的全部，相关多线程的坑来说，上面都是皮毛，多线程的坑完全不是串行队列死锁那么简单。

我们看最简单的一种情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

@interface VC ()  {
    int _number;
}
@end

@implementation VC
- (void)test {
	_number = 0;
    dispatch_queue_t queue = dispatch_queue_create("", DISPATCH_QUEUE_CONCURRENT);
    dispatch_group_t group = dispatch_group_create();
    for (int i = 0; i < 10000; ++i) {
        dispatch_group_async(group, queue, ^{
            self->_number = self->_number + 1;
        });
    }
    for (int i = 0; i < 10000; ++i) {
        dispatch_group_async(group, queue, ^{
            self->_number = self->_number - 1;
        });
    }
    dispatch_group_notify(group, queue, ^{
        printf("the _number is %d\n", self->_number);// 很少会打印0，有可能是-12，有可能是10，反正很少为0
    });
}
@end

上面，我们多个异步线程操作_number 成员变量，分别进行 10000 次增减 1，最后结果不是 0。这就是多线程的一个坑。
出现上面的原因就是，self->_number = self->_number + 1;这行代码不是原子的。
你可能会觉得，那这样的等号赋值可能有问题，那++self->_number;这样的方式进行增 1 操作会不会正常？
结果就是，一样不正常。不正常的原因，依旧因为++self->_number;这行代码也不是原子的。
那什么是原子的操作？
一条 CPU 执行的一个单指令，就是原子的。++、--这样的高级语言，在汇编后都会被编译成好几个操作指令。当计算机把操作指令执行了一半的时候，另一个线程也会开始执行，这个时候前一个线程就会被系统调度打断，去执行下一个线程的指令。所以，数据这个时候就产生了紊乱，导致++、--操作完全乱套了。

问题已经讲述清楚了，那该怎么解决呢？就是要手动制造原子性。一个操作指令是原子的，但是我们不可能把高级语言写出操作指令的形式，那样就回到汇编时代了。所以我们需要在外部制造更大的原子性区域，在这个区域里面，同一时间只能有一个线程操作。这样，就不会出现区域里面的代码执行一半转而另一个线程闯进来了。

原子性是有粒度大小的，如果粒度过大，则多线程间接变成单线程。如果粒度过小，则可能不足以保障原子性。
下面举例分析：

粒度过大：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

- (void)test {
    _number = 0;
    dispatch_queue_t queue = dispatch_queue_create("", DISPATCH_QUEUE_CONCURRENT);
    dispatch_group_t group = dispatch_group_create();
    for (int i = 0; i < 10000; ++i) {
        dispatch_group_async(group, queue, ^{
            @synchronized (self) {// 这里为了测试方便，使用了self，开发过程中不要这么用，应该维持一个私有对象用来做标记
                [self add];
            }
        });
    }
    for (int i = 0; i < 10000; ++i) {
        dispatch_group_async(group, queue, ^{
            @synchronized (self) {
                [self sub];
            }
        });
    }
    dispatch_group_notify(group, queue, ^{
        printf("the _number is %d\n", self->_number);
    });
}

- (void)add {
    /*
     ...
     这里有很多代码逻辑，预计1000行
     ...
     */
    ++_number;
    /*
    ...
    这里有很多代码逻辑，预计1000行
    ...
    */
}

- (void)sub {
    /*
     ...
     这里有很多代码逻辑，预计1000行
     ...
     */
    --_number;
    /*
    ...
    这里有很多代码逻辑，预计1000行
    ...
    */
}

上面我们的多线程操作主要是 add 和 sub 两个函数，业务处理也都在这两个函数里面。但是我们在调用 add 和 sub 函数的时候，通过 synchronized 锁临时添加了原子性区域，这就导致 add 和 sub 里面的 2000 多行代码，同一时间只能一条线程执行，变成了单线程操作。多线程形同实亡。

粒度过小：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@property (atomic) int num;

- (void)test {
    self.num = 0;
    dispatch_queue_t queue = dispatch_queue_create("", DISPATCH_QUEUE_CONCURRENT);
    dispatch_group_t group = dispatch_group_create();
    for (int i = 0; i < 10000; ++i) {
        dispatch_group_async(group, queue, ^{
            ++self.num;
        });
    }
    for (int i = 0; i < 10000; ++i) {
        dispatch_group_async(group, queue, ^{
            --self.num;
        });
    }
    dispatch_group_notify(group, queue, ^{
        printf("the _number is %d\n", self.num);// 依旧不为0
    });
}

我们定义了一个原子性 (atomic) 的 num 变量，但是最后打印的 num 依旧不为 0。原因就是 num 虽然已经在 set 和 get 方法里面添加了 synchronized 锁，但这个锁只能保障 num 变量在读和取的时候是原子性的。如果两个线程同时读，这个时候两个线程获取到的值是一样的，但是一个线程增 1，一个线程减 1，最后两个线程原子性调用 set 方法赋值。显然，num 的值这个时候就以最后调用 set 方法的线程值为准，不在准确了。
这个时候就是原子性粒度过小，导致虽然添加了锁，但依旧值不准确。

所以为了多线程处理能力最大化 (足够榨干 CPU 资源)，也为了数据依旧稳定和准确，原子性的粒度需要考量一个合适的区域。

多线程数据处理之锁

原子性粒度考量完成后，下面就是如何保障这个原子性区域的问题了。上面我们简化说明都使用了 synchronized 锁，但是多线程本身还有其他各种锁，synchronized 只是其中使用最方便但是效率也最低的一种。
iOS 下锁比较好理解，因为不像 JAVA，iOS 下锁就那么多，下面根据多线程锁机制来分析。

《程序员的自我修养 - 链接、装载与库》一书中，在说到线程安全锁机制的时候，概括说了 5 种锁，而 iOS 里面所有锁就是基于其中 4 种来的。
5 种线程锁分别是：信号量、互斥量、临界区、读写锁、条件变量。
信号量：是线程级别的，任何一个线程均可以自行加锁和解锁，任何一个线程也可以对另一个线程已加的锁进行解锁。
互斥量：也是线程级别的，但是比信号量严苛一些。任何一个线程均可以自行加锁和解锁，但是 A 线程不能对 B 线程已加的锁进行解锁，必须有 B 线程自己解锁。(iOS 里面，A 也可以解 B 加的锁，没有报错。)
临界区：进程级别的。比互斥量严苛了一些。加锁解锁被称作进入临界区、离开临界区。A 进程创建的临界区，只有 A 进程可以进出，其他进程不能操作。因为 iOS 是沙盒机制，对于单个 App 来说，不存在多进程，所以临界区在 iOS 开发里面用不到。不过系统肯定是需要临界区的，不过那是操作系统的事情了。
读写锁：读的时候数据不需要保障稳定性，所以可以并发读，但是写一定要独立，写的时候只能一个一个写，而且写的时候不能有读操作。也叫共享-独占锁。
条件变量：在达到某个特定的条件下，线程才能加锁和解锁。条件可以预先设置好，后面的加锁和解锁就根据条件来触发。

iOS 的锁有二十种左右，但更多都是对几个特定锁对封装。举例来说：

1. OSSpinLock 自旋锁（特别说明，虽然性能非常高，但是已经被废弃）。本质是互斥锁，ABC 同时访问对时候，C 先进去并加锁，然后 AB 不断循环访问是否解锁，如果解锁，立刻进入并加锁。所以被挡在锁外面对线程没有休息，而是不停对查询。
   1. CPU 消耗很大，因为挡在锁外面对线程一直在不停查询。
   2. 因为优先级反转原因，该锁已经被苹果弃用。比如优先级为：A > B>C。这个时候 C 提前进入加锁并执行代码，但是 A 优先级太高，导致 A 不停查询并占用了非常多对时间片，最后 C 用了很久才执行完并解锁。这个过程中，有太多时间片都浪费在了查询上。
2. os_unfair_lock 互斥锁的一种，OSSpinLock 的替代品。自旋锁会不停的查询并忙等，os_unfair_lock 会在加锁的情况下，对线程进行休眠。当解锁后继续执行。
   1. 只要是锁，优先级反转都会出现。但是不同于自旋锁，互斥锁会让挡在外面对线程处于休眠状态，在解锁后激活并执行。这样对 CPU 的消耗会很低。
3. dispatch_semaphore 信号量。可以实现二元信号量和多元信号量。通过信号量还可以做限制并发操作。
4. pthread_mutex 互斥锁。mutex 是互斥锁的完整体现。基于 mutex 可以实现互斥锁、递归锁、条件锁。效率非常高。
   1. 普通互斥锁：性能很高的锁，挡在锁外面的线程会休眠，不会出现优先级反转后时间片浪费情况。
   2. 递归锁：当 A 线程因为递归等原因，在没有释放锁的情况下，又重新加锁。这个时候互斥锁是不能加锁的，因为之前已经加过锁了。递归锁可以解决这个问题，在递归锁下，同一个线程可以一次加锁，然后一次解锁。
   3. 条件锁：mutex 实现的条件锁，不能根据条件自动加锁解锁。需要动手激活指定条件然后加锁或解锁。
5. NSLock 互斥锁。对 mutex 普通互斥锁的封装，面向对象。
6. NSRecursiveLock 递归锁。对 mutex 递归锁的封装，面向对象。
7. NSCondition 条件锁。对 mutex 条件锁的封装，面向对象。可以预设条件，在条件到达后，自行加锁解锁。相关 mutex 自行实现，代码过程更加自动化。
8. synchronized 递归锁。对 mutex 递归锁的封装，使用最方便，不需要手动加锁和解锁。但是性能也是所有锁里面最低的。
9. dispatch_rwlock 读写锁。可以保障写操作的互斥独立，读操作是重入可并发的。
10. dispatch_barrier_async 栅栏锁。可以分割一段任务队列（警告：必须使用自定义队列，不能使用主队列和全部队列）。也可以用来模拟读写锁，iOS 的属性修饰符 atomic 完全可以通过 dispatch_barrier_async 来实现。
11. dispatch_group_t 栅栏锁。和 barrier 类似，功能方向略有差异，group 栅栏锁可以实现组的操作。

还有其他一些锁，但可以发现，大差不差，都是对多线程 5 种锁的实现和封装，这 5 种锁分别是：信号量、互斥量、临界区（iOS 开发层面没必要使用）、读写锁、条件变量。

在 iOS 开发里面具体使用哪些锁问题已经不大，只要不使用 OSSpinLock，其他锁都可以试一试。目前来看，业务层面开发，NSLock 和 synchronized 用的较多。组件库方面，os_unfair_lock 和 mutex 使用的较多。

多线程数据安全总结

Runtime 源码里面，对于 SideTable 中 weak 表的实现，就是原子性粒度和锁的解释说明。
Runtime 对 weak 表的整个实现，都标记为线程不安全，并且在外部 SizeTable 中定义了 spinlock 自旋锁来限制原子性区域。
所以 weak 表的实现里面，原子性区域还是比较大的，整个 weak 表内部的数据的处理都处于不安全状态，通过最外界的函数调用处，给予自旋锁来保障线程安全。
相关代码如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

struct SideTable {
    // 锁对象 => 自旋锁，用于上锁/解锁 SideTable
    // spinlock_t的最终定义实际上是一个uint32_t类型的非公平的自旋锁。所谓非公平，就是说获得锁的顺序和申请锁的顺序无关，也就是说，第一个申请锁的线程有可能会是最后一个获得到该锁，或者是刚获得锁的线程会再次立刻获得到该锁，造成饥饿等待。 同时，在OC中，_os_unfair_lock_opaque也记录了获取它的线程信息，只有获得该锁的线程才能够解开这把锁。
    spinlock_t slock;
    // 索引哈希表(稠密哈希)   => 对象引用计数map,用来存储OC对象的引用计数(仅在未开启isa优化 或 在isa优化情况下isa_t的引用计数溢出时才会用到)。
    // 是一个以objc_object为key的hash表，其vaule就是OC对象的引用计数。同时，当OC对象的引用计数变为0时，会自动将相关的信息从hash表中剔除。
    RefcountMap refcnts;
    // weak表(核心实现)      => 对象弱引用map
    weak_table_t weak_table;

    // 构造函数
    SideTable() {
        memset(&weak_table, 0, sizeof(weak_table));
    }
    // 析构函数(看看函数体，苹果设计的SideTable其实不希望被析构，不然会引起fatal 错误)
    ~SideTable() {
        _objc_fatal("Do not delete SideTable.");
    }

    // 锁操作 符合StripedMap对T的定义
    void lock() { slock.lock(); }
    void unlock() { slock.unlock(); }
    void forceReset() { slock.forceReset(); }

    // Address-ordered lock discipline for a pair of side tables.

    template<HaveOld, HaveNew>
    static void lockTwo(SideTable *lock1, SideTable *lock2);
    template<HaveOld, HaveNew>
    static void unlockTwo(SideTable *lock1, SideTable *lock2);
};

还有 Runtime 里面_read_images 函数里面操作 SEL 的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

    // 将所有SEL都注册到哈希表中，是另外一张哈希表
    static size_t UnfixedSelectors;
    sel_lock();
    for (EACH_HEADER) {
        if (hi->isPreoptimized()) continue;

        bool isBundle = hi->isBundle();
        // 取出的是字符串数组，例如首地址是"class"
        SEL *sels = _getObjc2SelectorRefs(hi, &count);
        UnfixedSelectors += count;
        for (i = 0; i < count; i++) {
            // sel_cname函数内部就是将SEL强转为常量字符串
            const char *name = sel_cname(sels[i]);
            // 注册SEL的操作
            sels[i] = sel_registerNameNoLock(name, isBundle);
        }
    }
    sel_unlock();
---
void sel_lock(void)
{
    selLock.write();
}
void sel_unlock(void)
{
    selLock.unlockWrite();
}
---
rwlock_t selLock;

这里对原子性粒度把控的就很细，用的读写锁。

多线程下数据结构和算法的重要性

到这里，多线程下数据安全基本已经可以告一段落了。但是，还没有结束。
我们之前提过，多线程下数据安全通过原子性粒度的把控和锁机制，已经可以比较好的实现。而粒度控制小心一些，锁就那么多，用的恰当一些，数据安全就没有问题了。
后面的问题，就是原子性区域内部的代码执行效率的问题了。因为原子性区域内部都是单个线程在执行，所以执行效率一定是要很高的。
我们举个例子，如果原子性区域里面，代码耗时需要 1s，那么多线程操作下，是不是有很多线程都会被原地休眠？整个执行效率肯定低下的要死。

所以，这个时候，就要使用合适的数据结构和算法，来提高代码执行的效率。

我们用 YYCache 的内存缓存举例，YYCache 使用 pthread_mutex 互斥锁，原子性粒度控制的很小，在对数据进行操作的时候才开始加锁和解锁。
缓存使用来 LRU 算法，通过双向链表来实现数据对增和删的复杂度为 O (1)。
但是链表的查询复杂度是比较高的，因为链表无法做随机寻址，也没法用数组的空间局部性缓存加速。
所以作者通过空间换时间的方式，引入了 hash map，将缓存数据存入 hash map 中实现查询复杂度为 O (1)。
这样，整体内存缓存的数据的操作复杂度都将为 O (1)。

之前也写过文章说明数组和链表的优缺点，其中重要一点就是链表的增删复杂度为 1，数组的查复杂度为 1。为了更好的使用数组和链表的双方优点，所以 hash map 和链表常一块使用。

Runtime 里面也是各种 hash table 和 hash map table 的使用，甚至 hash 函数都为了高效，尽可能使用位操作来计算索引值。

所以多线程编程，数据安全能通过锁保障的也都能很好保障（像 FMDB 和 iOS UI 主线程，知道多线程数据安全的处理风险太大，索性就不支持多线程了），唯有算法这个环节，诡异且多变，最能体现价值。

今天是五四青年节日，我查了青年的年龄标准，是 14-28 周岁。突然很开心，我明年还能在过一次五四青年节。
历史前进的车轮肯定不会停下来，不管是文明，经济，抑或是网络，甚至自由。后浪必定比前浪更加优秀，这是毋庸置疑的，否则不符合历史规律。
每一波新一代，都拥有更棒的环境，更好的认知，更方便的学习方式。所以后浪们必定更加优秀和杰出，这是必然。
社会这个大团体，也一定会在后浪的推动下，一直向前，稳步向前。
但有一个重点我也想表达，随着历史长河的流逝，社会必然会进步。如果要进步的更快，那思想独立和思想解放必定占据非常大的比重，中国的新一代在这方面有很大短板。
我已经在职场 7 年了，虽然还是青年，但已经没有了青年的气质和气息。即使假装青年的疯癫，但眼角的复杂情绪却无法掩藏，也无法欺骗自己。
我显然不是青年了，很多时候我会无知于自己的未来，也对未来充满恐惧、失措、无助，而青年人不应该有这些拘束思想，他们应该是奔放的，激情四射的。
我想了一下，我脱离青年身份，应该是 3 年前，那年我 24 周岁，本命年。那年，我孩子出生。