多线程应用初探(一)----(概念，安全)

线程是进程的基本执行单元，一个进程的全部任务都在线程中执行 进程要想执行任务，必须得有线程，进程至少要有一条线程 程序启动会默认开启一条线程，这条线程被称为主线程或 UI 线程 进程是指在系统中正在运行的一个应用程序 每一个进程之间是独立的，每一个进程均运行在其专用的且受保护的内存

线程与进程之间的关系

地址空间：同一进程的线程共享本进程的地址空间，而进程之间则是独立的地址空间。
资源拥有：同一进程内的线程共享本进程的资源如内存、I/O、cpu等，可是进程之间的资源是独立的。
一个进程崩溃后，在保护模式下不会对其余进程产生影响，可是一个线程崩溃整个进程都死掉。因此多进程要比多线程健壮。
进程切换时，消耗的资源大，效率高。因此涉及到频繁的切换时，使用线程要好于进程。一样若是要求同时进行而且又要共享某些变量的并发操做，只能用线程不能用进程
执行过程：每一个独立的进程有一个程序运行的入口、顺序执行序列和程序入口。可是线程不能独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。
线程是处理器调度的基本单位，可是进程不是

多线程

优势

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

缺点

• 开启线程须要占用必定的内存空间（默认状况下，每个线程都占 512 KB）
• 若是开启大量的线程，会占用大量的内存空间，下降程序的性能
• 线程越多，CPU 在调用线程上的开销就越大 * 程序设计更加复杂，好比线程间的通讯、多线程的数据共享

原理

多线程在单位时间片内快速在各个线程之间切换

线程生命周期

start ==》 Runable ==》 Runing ==》 blocked(调用sleep方法等待同步锁可调度线程池里移出) ==》 dead
新建 ==》 就绪 ==》 运行(cpu调度当前线程) ==> 堵塞 ==》任务完成强制退出

线程和RunLoop的关系

1. RunLoop与线程是一一对应的，一个Runloop对应一个核心线程,Runloop是能够嵌套的，他们的关系保持在一个全局的字典里
2. RunLoop管理线程
3. 第一获取时被建立，线程结束时被销毁
4. 对于主线程Runloop默认建立好，Runloop在子线程懒加载使用时才建立

多线程安全 ---- 锁和性能

在多线程操做过程当中，每每一个数据同时被多个线程读写，在这种状况下，若是没有相应的机制对数据进行保护，就极可能会发生数据污染的的问题，给程序形成各类难以重现的潜在bug。

多线程安全中相关术语及概念（假设操做的是数据库）：

（1）脏读

指当一个事务正在访问数据，而且对数据进行了修改，而这种修改尚未提交到数据库中。这时，另一个事务也访问这个数据，而后使用了这个数据。由于这个数据是尚未提交的数据，那么另一个事务读到的这个数据是脏数据，依据脏数据所作的操做多是不正确的。

（2）不可重复读

指在一个事务内，屡次读同一数据。在这个事务尚未结束时，另一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，因为第二个事务的修改，那么第一个事务两次读到的的数据多是不同的。这样就发生了在一个事务内两次读到的数据是不同的，所以称为是不可重复读。

（3）幻觉读

指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的所有数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，之后就会发生操做第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉同样。例如： 目前工资为5000的员工有10人，事务A读取全部工资为5000的人数为10人。此时，事务B插入一条工资也为5000的记录。这时，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。

---

线程不安全：就是不提供数据访问保护，有可能出现多个线程前后更改数据形成所获得的数据是脏数据。当多个线程访问同一块资源时，很容易引起数据错乱和数据安全问题。
线程安全：简单来讲就是多个线程同时对共享资源进行访问时，采用了加锁机制，当一个线程访问共享资源，对该资源进行保护，其余线程不能进行访问直到该线程读取完，其余线程才可以使用。

多线程的锁

互斥锁

@synchronized(id anObject)

- (void)myMethod:(id)anObj
{
    @synchronized(anObj)
    {
        //do something here
    }
}
复制代码

指当一个线程在对某个资源进行读取时，另外一条想要读取的线程将要进入等待状态，当该线程放问完毕时，等待的线程在对其进行访问，atomic就是对属性的Set方法加互斥锁，但这并不能彻底保证线程安全，由于他仅仅对set方法进行了加锁

NSLock

NSLock对象实现了NSLocking protocol，包含几个方法： lock——加锁 unlock——解锁 tryLock——尝试加锁，若是失败了，并不会阻塞线程，只是当即返回NO lockBeforeDate:——在指定的date以前暂时阻塞线程（若是没有获取锁的话），若是到期尚未获取锁，则线程被唤醒，函数当即返回NO。 好比：

NSLock *theLock = [[NSLock alloc] init]; 
if ([theLock lock]) 
{
   //do something here
   [theLock unlock]; 
}
复制代码

递归锁

NSRecursiveLock

屡次调用不会阻塞已获取该锁的线程。

NSRecursiveLock *rcsLock = [[NSRecursiveLock alloc] init]; 

void recursiveLockTest(int value) 
{ 
  [rcsLock lock]; 
  if (value != 0) 
  { 
    --value; 
    recursiveLockTest(value); 
  }
  [rcsLock unlock]; 
} 

recursiveLockTest(5)
复制代码

上面若是直接使用NSLock就会形成死锁。NSRecursiveLock类定义的锁能够在同一线程屡次lock，而不会形成死锁。递归锁会跟踪它被多少次lock。每次成功的lock都必须平衡调用unlock操做。只有全部的锁住和解锁操做都平衡的时候，锁才真正被释放给其余线程得到。

NSConditionLock 条件锁

有时一把只会lock和unlock的锁未必就能彻底知足咱们的使用。由于普通的锁只能关心锁与不锁，而不在意用什么钥匙才能开锁，而咱们在处理资源共享的时候，多数状况是只有知足必定条件的状况下才能打开这把锁：

//主线程中
NSConditionLock *theLock = [[NSConditionLock alloc] init];

//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    for (int i=0;i<=2;i++)
    {
        [theLock lock];
        NSLog(@"thread1:%d",i);
        sleep(2);
        [theLock unlockWithCondition:i];
    }
});

//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [theLock lockWhenCondition:2];
    NSLog(@"thread2");
    [theLock unlock];
});
复制代码

在线程1中的加锁使用了lock，是不须要条件的，因此顺利的就锁住了。但在unlock的使用了一个整型的条件，它能够开启其它线程中正在等待这把钥匙的临界地，而线程2则须要一把被标识为2的钥匙，因此当线程1循环到最后一次的时候，才最终打开了线程2中的阻塞。但即使如此，NSConditionLock也跟其它的锁同样，是须要lock与unlock对应的，只是lock、lockWhenCondition:与unlock，unlockWithCondition:是能够随意组合的.

分布锁：NSDistributedLock

以上全部的锁都是在解决多线程之间的冲突，但若是赶上多个进程或多个程序之间须要构建互斥的情景该怎么办呢？这个时候咱们就须要使用到NSDistributedLock了，从它的类名就知道这是一个分布式的Lock，NSDistributedLock的实现是经过文件系统的，因此使用它才能够有效的实现不一样进程之间的互斥，但NSDistributedLock并不是继承于NSLock，它没有lock方法，它只实现了tryLock，unlock，breakLock，因此若是须要lock的话，你就必须本身实现一个tryLock的轮询。

GCD中信号量：dispatch_semaphore

假设如今系统有两个空闲资源能够被利用，但同一时间却有三个线程要进行访问，这种状况下，该如何处理呢？这里，咱们就能够方便的利用信号量来解决这个问题。一样咱们也能够用它来构建一把”锁”（从本质上讲，信号量与锁是有区别的，具体的请自行查阅资料）。

信号量：就是一种可用来控制访问资源的数量的标识。设定了一个信号量，在线程访问以前，加上信号量的处理，则可告知系统按照咱们指定的信号量数量来执行多个线程。

在GCD中有三个函数是semaphore的操做： dispatch_semaphore_create 建立一个semaphore dispatch_semaphore_signal 发送一个信号 dispatch_semaphore_wait 等待信号

dispatch_semaphore_create函数有一个整形的参数，咱们能够理解为信号的总量，dispatch_semaphore_signal是发送一个信号，天然会让信号总量+1，dispatch_semaphore_wait等待信号，当信号总量少于0的时候就会一直等待，不然就能够正常的执行，并让信号总量-1，根据这样的原理，咱们即可以快速的建立一个并发控制来同步任务和有限资源访问控制。

GCD中“栅栏函数”：dispatch_barrier_async

dispatch_barrier_async函数的做用与barrier的意思相同，在进程管理中起到一个栅栏的做用，它等待全部位于barrier函数以前的操做执行完毕后执行，而且在barrier函数执行以后，barrier函数以后的操做才会获得执行，该函数须要同dispatch_queue_create函数生成的concurrent Dispatch Queue队列一块儿使用。

自旋锁

它的特色是在线程等待时会一直轮询，处于忙等状态。自旋锁由此得名。 自旋锁看起来是比较耗费cpu的，然而在互斥临界区计算量较小的场景下，它的效率远高于其它的锁。由于它是一直处于running状态，减小了线程切换上下文的消耗。OSSpinLock是一种自旋锁，可是这种锁是不安全的 关于 OSSpinLock 再也不安全，缘由就在于优先级反转问题。

优先级翻转：一个高优先级任务间接被一个低优先级任务所抢先(preemtped)，使得两个任务的相对优先级被倒置。 这每每出如今一个高优先级任务等待访问一个被低优先级任务正在使用的临界资源，从而阻塞了高优先级任务；同时，该低优先级任务被一个次高优先级的任务所抢先，从而没法及时地释放该临界资源。这种状况下，该次高优先级任务得到执行权。
当一个高优先级的任务须要一个资源，可是此时这个资源正在被低优先级任务所占有，这种状况形成高优先级任务须要等待低优先级任务完成以后才能执行，可是次高级别任务并不须要资源，因此他能够在低优先级任务以前执行，因此间接的次优先级任务就在高优先级任务以前被执行了。使得优先级被倒置了。假设高优先级任务等待资源时不是堵塞等待，而是忙着循环，则可能永远没法得到资源，由于低优先级任务没有执行任务的时间片，进而没法释放资源，高优先级任务也永远不会推动。

本节参考文章imlifengfeng

优先级反转解决的办法

1. 优先级继承，故名思义，是将占有锁的线程优先级，继承等待该锁的线程高优先级，若是存在多个线程等待，就取其中之一最高的优先级继承。
2. 优先级天花板，则是直接设置优先级上限，给临界区一个最高优先级，进入临界区的进程都将得到这个高优先级。
3. 禁止中断的特色，在于任务只存在两种优先级：可被抢占的 / 禁止中断的 。 前者为通常任务运行时的优先级，后者为进入临界区的优先级。经过禁止中断来保护临界区，没有其它第三种的优先级，也就不可能发生反转了。