多线程原理本文的目的在于了解进程、线程、多线程、线程池等的基本概念及原理线程和进程线程和进程的定义线程线程时

iOS 底层原理文章汇总

本文的目的在于了解进程、线程、多线程、线程池等的基本概念及原理

线程和进程

线程和进程的定义

线程

线程时进程的基本执行单元，一个进程的所有任务都在线程中执行
进程要想执行任务，必须的有线程，进程至少要有一条线程
程序启动会默认开启一条线程，这条线程被称为 主线程 或者 UI线程

进程

进程是指在系统中正在运行的一个应用程序
每个进程之间是独立的，每个进程均运行在其专用的且受保护的内存空间内
通过“活动监视器”可以查看mac系统中所开启的线程

所以，可以简单的理解为：进程是线程的容器，而线程用来执行任务。在iOS中是单进程开发，一个进程就是一个app，进程之间是相互独立的，如支付宝、微信、qq等，这些都是属于不同的进程

进程与线程的关系

进程与线程之间的关系主要涉及两个方面：

地址空间
- 同一个进程的线程共享本进程的地址空间
- 而进程之间则是独立的地址空间
资源拥有
- 同一个进程内线程共享本进程的资源，如内存、I/O、cpu等
- 但是进程之间资源是独立的

两个之间的关系就相当于工厂与流水线的关系，工厂与工厂之间是相互独立的，而工厂中的流水线是共享工厂的资源的，即 进程相当于一个工厂，线程相当于工厂中的一条流水线

针对进程和线程，还有以下几点说明：

1: 多进程要比多线程健壮
- 一个进程崩溃后，在保护模式下不会对其他进程产生影响
- 而一个线程崩溃整个进程都死掉
2: 使用场景：频繁切换、并发操作
- 进程切换时，消耗的资源大，效率高。所以涉及到频繁的切换时，使用线程要好于进程。
- 同样如果要求同时进行并且又要共享某些变量的并发操作，只能用线程不能用进程
3: 执行过程
- 每个独立的进程有一个程序运行的入口、顺序执行序列和程序入口
- 但是 线程不能独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。
4: 线程是处理器调度的基本单位，但是进程不是。
5: 线程没有地址空间,线程包含在进程地址空间中

线程和Runloop的关系

1:runloop与线程是一一对应的，一个runloop对应一个核心的线程，为什么说是核心的，是因为runloop是可以嵌套的，但是核心的只能有一个，他们的关系保存在一个全局的字典里。
2:runloop是来管理线程的，当线程的runloop被开启后，线程会在执行完任务后进入休眠状态，有了任务就会被唤醒去执行任务。
3:runloop在第一次获取时被创建，在线程结束时被销毁。
4:对于主线程来说，runloop在程序一启动就默认创建好了。
5:对于子线程来说，runloop是懒加载的，只有当我们使用的时候才会创建，所以在子线程用定时器要注意:确保子线程的runloop被创建，不然定时器不会回调。

多线程

多线程原理

对于单核CPU，同一时间，CPU只能处理一条线程，即只有一条线程在工作，
iOS中的多线程同时执行的本质是 CPU在多个任务直接进行快速的切换，由于CPU调度线程的时间足够快，就造成了多线程的“同时”执行的效果。其中切换的时间间隔就是时间片

多线程意义

优点

能适当提高程序的执行效率
能适当提高资源的利用率，如CPU、内存
线程上的任务执行完成后，线程会自动销毁

缺点

开启线程需要占用一定的内存空间，默认情况下，每一个线程占用512KB
如果开启大量线程，会占用大量的内存空间，降低程序的性能
线程越多，CPU在调用线程上的开销就越大
程序设计更加复杂，比如线程间的通信，多线程的数据共享

多线程生命周期

多线程的生命周期主要分为5部分：新建 - 就绪 - 运行 - 阻塞 - 死亡，如下图所示

多线程声明周期

新建：主要是实例化线程对象
就绪：线程对象调用start方法，将线程对象加入可调度线程池，等待CPU的调用，即调用start方法，并不会立即执行，进入就绪状态，需要等待一段时间，经CPU调度后才执行，也就是从就绪状态进入运行状态
运行：CPU负责调度可调度线城市中线程的执行，在线程执行完成之前，其状态可能会在就绪和运行之间来回切换，这个变化是由CPU负责，开发人员不能干预。
阻塞：当满足某个预定条件时，可以使用休眠，即sleep，或者同步锁，阻塞线程执行。当进入sleep时，会重新将线程加入就绪中。下面关于休眠的时间设置，都是NSThread的
- sleepUntilDate: 阻塞当前线程，直到指定的时间为止，即休眠到指定时间
- sleepForTimeInterval: 在给定的时间间隔内休眠线程，即指定休眠时长
- 同步锁：@synchronized(self)：
死亡：分为两种情况
- 正常死亡，即线程执行完毕
- 非正常死亡，即当满足某个条件后，在线程内部（或者主线程中）终止执行（调用exit方法等退出）

简要说明，就是处于运行中的线程拥有一段可以执行的时间（称为时间片），

如果时间片用尽，线程就会进入就绪状态队列
如果时间片没有用尽，且需要开始等待某事件，就会进入阻塞状态队列
等待事件发生后，线程又会重新进入就绪状态队列
每当一个线程离开运行，即执行完毕或者强制退出后，会重新从就绪状态队列中选择一个线程继续执行

线程的exit和cancel说明

- `exit`：一旦强行终止线程，后续的所有代码都不会执行
- `cancel`：取消当前线程，但是不能取消正在执行的线程

【面试题】线程的优先级越高，是不是意味着任务的执行越快？

并不是，线程执行的快慢，除了要看优先级，还需要查看资源的大小（即任务的复杂度）、以及 CPU 调度情况。在NSThread中，线程优先级threadPriority已经被服务质量qualityOfService取代，以下是相关的枚举值

线程池原理

【第一步】判断核心线程池是否都正在执行任务
- 返回NO，创建新的工作线程去执行
- 返回YES，进入【第二步】
【第二步】判断线程池工作队列是否已经饱满
- 返回NO，将任务存储到工作队列，等待CPU调度
- 返回YES，进入【第三步】
【第三步】判断线程池中的线程是否都处于执行状态
- 返回NO，安排可调度线程池中空闲的线程去执行任务
- 返回YES，进入【第四步】
【第四步】交给饱和策略去执行，主要有以下四种（在iOS中并没有找到以下4种策略）
- AbortPolicy：直接抛出RejectedExecutionExeception异常来阻止系统正常运行
- CallerRunsPolicy：将任务回退到调用者
- DisOldestPolicy：丢掉等待最久的任务
- DisCardPolicy：直接丢弃任务

iOS中多线程的实现方案

iOS中的多线程实现方式，主要有四种：pthread、NSThread、GCD、NSOperation，汇总如图所示

多线程实现方案

下面是以上四种方案的简单示例

// *********1: pthread*********
pthread_t threadId = NULL;
//c字符串
char *cString = "HelloCode";
/**
 pthread_create 创建线程
 参数：
 1. pthread_t：要创建线程的结构体指针，通常开发的时候，如果遇到 C 语言的结构体，类型后缀 `_t / Ref` 结尾
 同时不需要 `*`
 2. 线程的属性，nil(空对象 - OC 使用的) / NULL(空地址，0 C 使用的)
 3. 线程要执行的`函数地址`
 void *: 返回类型，表示指向任意对象的指针，和 OC 中的 id 类似
 (*): 函数名
 (void *): 参数类型，void *
 4. 传递给第三个参数(函数)的`参数`
 */
int result = pthread_create(&threadId, NULL, pthreadTest, cString);
if (result == 0) {
    NSLog(@"成功");
} else {
    NSLog(@"失败");
}
    
//*********2、NSThread*********
[NSThread detachNewThreadSelector:@selector(threadTest) toTarget:self withObject:nil];
    
//*********3、GCD*********
dispatch_async(dispatch_get_global_queue(0, 0), ^{
    [self threadTest];
});
    
//*********4、NSOperation*********
[[[NSOperationQueue alloc] init] addOperationWithBlock:^{
    [self threadTest];
}];

- (void)threadTest{
    NSLog(@"begin");
    NSInteger count = 1000 * 100;
    for (NSInteger i = 0; i < count; i++) {
        // 栈区
        NSInteger num = i;
        // 常量区
        NSString *name = @"zhang";
        // 堆区
        NSString *myName = [NSString stringWithFormat:@"%@ - %zd", name, num];
        NSLog(@"%@", myName);
    }
    NSLog(@"over");
}

void *pthreadTest(void *para){
    // 接 C 语言的字符串
    //    NSLog(@"===> %@ %s", [NSThread currentThread], para);
    // __bridge 将 C 语言的类型桥接到 OC 的类型
    NSString *name = (__bridge NSString *)(para);
    
    NSLog(@"===>%@ %@", [NSThread currentThread], name);
    
    return NULL;
}

C和OC的桥接

其中涉及C与OC的桥接，有以下几点说明

__bridge只做类型转换，但是不修改对象(内存)管理权
__bridge_retained(也可以使用CFBridgingRetain)将Objective-C的对象转换为 Core Foundation的对象，同时将对象(内存)的管理权交给我们，后续需要使用 CFRelease或者相关方法来释放对象
__bridge_transfer(也可以使用CFBridgingRelease)将Core Foundation的对象转换为Objective-C的对象，同时将对象(内存)的管理权交给ARC。

线程安全问题

当多个线程同时访问一块资源时，容易引发数据错乱和数据安全问题，有以下两种解决方案

互斥锁（即同步锁）：@synchronized
自旋锁

互斥锁

用于保护临界区，确保同一时间，只有一条线程能够执行
如果代码中只有一个地方需要加锁，大多都使用 self，这样可以避免单独再创建一个锁对象
加了互斥锁的代码，当新线程访问时，如果发现其他线程正在执行锁定的代码，新线程就会进入休眠

针对互斥锁，还需要注意以下几点：

互斥锁的锁定范围，应该尽量小，锁定范围越大，效率越差
能够加锁的任意 NSObject 对象
锁对象一定要保证所有的线程都能够访问

自旋锁

自旋锁与互斥锁类似，但它不是通过休眠使线程阻塞，而是在获取锁之前一直处于忙等（即原地打转，称为自旋）阻塞状态
使用场景：锁持有的时间短，且线程不希望在重新调度上花太多成本时，就需要使用自旋锁，属性修饰符atomic，本身就有一把自旋锁
加入了自旋锁，当新线程访问代码时，如果发现有其他线程正在锁定代码，新线程会用死循环的方法，一直等待锁定的代码执行完成，即不停的尝试执行代码，比较消耗性能

【面试题】：自旋锁 vs 互斥锁

同：在同一时间，保证了只有一条线程执行任务，即保证了相应同步的功能
不同：
- 互斥锁：发现其他线程执行，当前线程 休眠（即就绪状态），进入等待执行，即挂起。一直等其他线程打开之后，然后唤醒执行
- 自旋锁：发现其他线程执行，当前线程 一直询问（即一直访问），处于忙等状态，耗费的性能比较高
场景：根据任务复杂度区分，使用不同的锁，但判断不全时，更多是使用互斥锁去处理
- 当前的任务状态比较短小精悍时，用自旋锁
- 反之的，用互斥锁

atomic 原子锁 & nonatomic 非原子锁

atomic 和 nonatomic主要用于属性的修饰，以下是相关的一些说明：

atomic是原子属性，是为多线程开发准备的，是默认属性！
- 仅仅在属性的 setter 方法中，增加了锁(自旋锁)，能够保证同一时间，只有一条线程对属性进行写操作
- 同一时间单(线程)写多(线程)读的线程处理技术
- Mac开发中常用
nonatomic 是非原子属性
- 没有锁！性能高！
- 移动端开发常用

【面试题】atomic与nonatomic 的区别

nonatomic
- 非原子属性
- 非线程安全，适合内存小的移动设备
atomic
- 原子属性(线程安全)，针对多线程设计的，默认值
- 保证同一时间只有一个线程能够写入(但是同一个时间多个线程都可以取值)
- atomic 本身就有一把锁(自旋锁) 单写多读:单个线程写入，多个线程可以读取
- 线程安全，需要消耗大量的资源

iOS 开发的建议

所有属性都声明为 nonatomic
尽量避免多线程抢夺同一块资源尽量将加锁、资源抢夺的业务逻辑交给服务器端处理，减小移动客户端的压力

线程间通讯

在Threading Programming Guide文档中，提及，线程间的通讯有以下几种方式

线程间通讯-官方文档说明

直接消息传递: 通过performSelector的一系列方法，可以实现由某一线程指定在另外的线程上执行任务。因为任务的执行上下文是目标线程，这种方式发送的消息将会自动的被序列化
全局变量、共享内存块和对象: 在两个线程之间传递信息的另一种简单方法是使用全局变量，共享对象或共享内存块。尽管共享变量既快速又简单，但是它们比直接消息传递更脆弱。必须使用锁或其他同步机制仔细保护共享变量，以确保代码的正确性。否则可能会导致竞争状况，数据损坏或崩溃。
条件执行: 条件是一种同步工具，可用于控制线程何时执行代码的特定部分。您可以将条件视为关守，让线程仅在满足指定条件时运行。
Runloop sources: 一个自定义的 Runloop source 配置可以让一个线程上收到特定的应用程序消息。由于 Runloop source 是事件驱动的，因此在无事可做时，线程会自动进入睡眠状态，从而提高了线程的效率
Ports and sockets:基于端口的通信是在两个线程之间进行通信的一种更为复杂的方法，但它也是一种非常可靠的技术。更重要的是，端口和套接字可用于与外部实体（例如其他进程和服务）进行通信。为了提高效率，使用 Runloop source 来实现端口，因此当端口上没有数据等待时，线程将进入睡眠状态。需要注意的是，端口通讯需要将端口加入到主线程的Runloop中，否则不会走到端口回调方法
消息队列: 传统的多处理服务定义了先进先出（FIFO）队列抽象，用于管理传入和传出数据。尽管消息队列既简单又方便，但是它们不如其他一些通信技术高效
Cocoa 分布式对象: 分布式对象是一种 Cocoa 技术，可提供基于端口的通信的高级实现。尽管可以将这种技术用于线程间通信，但是强烈建议不要这样做，因为它会产生大量开销。分布式对象更适合与其他进程进行通信，尽管在这些进程之间进行事务的开销也很高

atomic

atomic 底层是如何实现的？
atomic 绝对安全吗?

带着这些问题我们对 atomic 进行探讨，我们来到 objc源码 处进行查看，atomic 既然是修饰property的，那么必然会跟property的set和get方法相关，我们找到了相关方法的实现：

static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
    if (offset == 0) {
        object_setClass(self, newValue);
        return;
    }

    id oldValue;
    id *slot = (id*) ((char*)self + offset);

    if (copy) {
        newValue = [newValue copyWithZone:nil];
    } else if (mutableCopy) {
        newValue = [newValue mutableCopyWithZone:nil];
    } else {
        if (*slot == newValue) return;
        newValue = objc_retain(newValue);
    }
    // 原子操作判断
    if (!atomic) {
        oldValue = *slot;
        *slot = newValue;
    } else {
        spinlock_t& slotlock = PropertyLocks[slot];
        slotlock.lock();
        oldValue = *slot;
        *slot = newValue;        
        slotlock.unlock();
    }

    objc_release(oldValue);
}

set 方法atomic那块加了判断，如果是原子性就会进行加锁和解锁操作。

再看 get 方法：

id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
    if (offset == 0) {
        return object_getClass(self);
    }

    // Retain release world
    id *slot = (id*) ((char*)self + offset);
    if (!atomic) return *slot;

    // Atomic retain release world
    spinlock_t& slotlock = PropertyLocks[slot];
    slotlock.lock();
    id value = objc_retain(*slot);
    slotlock.unlock();

    // for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.
    return objc_autoreleaseReturnValue(value);
}

很明显，也是对原子操作进行加锁处理。

我们注意到所有的源码中针对加锁的地方都是定义为spinlock,也就是自旋锁,所以通常被人问到我们atomic底层是什么的时候，我们都回答 自旋锁 ，

内部确如下述代码那样是用os_unfair_lock 来实现的，探其底层执行lock和unlock的其实是mutex_t,也就是互斥锁。

// property的set方法
    if (!atomic) {
        oldValue = *slot;
        *slot = newValue;
    } else {
        spinlock_t& slotlock = PropertyLocks[slot];
        slotlock.lock();
        oldValue = *slot;
        *slot = newValue;        
        slotlock.unlock();
    }
// atomic中用到的锁
using spinlock_t = mutex_tt<LOCKDEBUG>;
// mutex_tt 的结构
class mutex_tt : nocopy_t {
    os_unfair_lock mLock;
 public:
    constexpr mutex_tt() : mLock(OS_UNFAIR_LOCK_INIT) {
        lockdebug_remember_mutex(this);
    }

    constexpr mutex_tt(const fork_unsafe_lock_t unsafe) : mLock(OS_UNFAIR_LOCK_INIT) { }

    void lock() {
        lockdebug_mutex_lock(this);

        os_unfair_lock_lock_with_options_inline
            (&mLock, OS_UNFAIR_LOCK_DATA_SYNCHRONIZATION);
    }

    void unlock() {
        lockdebug_mutex_unlock(this);

        os_unfair_lock_unlock_inline(&mLock);
    }
// 上述lock方法的实现
void 
lockdebug_mutex_lock(mutex_t *lock)
{
    auto& locks = ownedLocks();

    if (hasLock(locks, lock, MUTEX)) {
        _objc_fatal("deadlock: relocking mutex");
    }
    setLock(locks, lock, MUTEX);
}

所以说 atomic 的本质并不是自旋锁，至少当前不是，我查询了 objc 之前的源码发现老版本的 atomic 的实现，确实不一样:

typedef uintptr_t spin_lock_t;
OBJC_EXTERN void _spin_lock(spin_lock_t *lockp);
OBJC_EXTERN int  _spin_lock_try(spin_lock_t *lockp);
OBJC_EXTERN void _spin_unlock(spin_lock_t *lockp);

由此可知：

atomic 原子操作只是对setter 和 getter 方法进行加锁

那么第二个问题来了：atomic绝对安全吗？我们接着分析，首先看下面的代码，最终的 number 会是多少？20000?

@property (atomic, assign) NSInteger number;

- (void)atomicTest {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 10000; i ++) {
            self.number = self.number + 1;
            NSLog(@"A-self.number is %ld",self.number);
        }
    });

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 10000; i ++) {
            self.number = self.number + 1;
            NSLog(@"B-self.number is %ld",self.number);
        }
    });
}

NO 并不是 20000，这是为啥呢？我们的 number 是 atomic 进行加锁了啊，为什么还会出现线程安全问题。其实答案上文已经有了，只是需要我们仔细去品，atomic 只是针对 setter 和 getter 方法进行加锁，上述代码有两个异步线程同时执行，如果某个时间 A线程 执行到getter方法，之后 cpu 立即切换到 线程B 去执行他的get方法那么这个时候他们进行 +1 的处理并执行setter方法，那么两个线程的 number 就会是一样的结果，这样我们的 +1就会出现线程安全问题，就会导致我们的数字出现偏差，出现重复的数值。

atomic 的底层实现，老版本是自旋锁，新版本是互斥锁。
atomic 并不是绝对线程安全，它能保证代码进入 getter 和 setter 方法的时候是安全的，但是并不能保证多线程的访问情况下是安全的，一旦出了 getter 和 setter 方法，其线程安全就要由程序员自己来把握，所以 atomic 属性和线程安全并没有必然联系。

多线程原理

线程 和 进程

线程和进程的定义

进程与线程的关系

线程和Runloop的关系

多线程

多线程原理

多线程意义

多线程生命周期

线程池原理

iOS中多线程的实现方案

线程安全问题

互斥锁

自旋锁

atomic 原子锁 & nonatomic 非原子锁

线程间通讯

atomic

线程和进程