前提简述：
常用的线程方案有Pthread，NSThread, GCD,NSOperation。以下是比较：
pthread ： 是一套通用的C语言多线程API，适用于Unix \ Linux\ Windows等系统，可跨平台\可移植性，学习难度大。线程生命周期需要程序员管理。
NSThread： 是OC语言，使用更加面向对象，直接操作线程对象，程序员需要管理生命周期。
GCD： 可替代NSThread等线程技术，C语言实现，系统自动管理。
NSOperation： 基于GCD的封装成OC对象，比GCD多了一些更简单实用的功能，使用更加面向对象，系统自动管理线程生命周期
另附上两个案例：
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSLog(@"1");
[self performSelector:@selector(test) withObject:nil afterDelay:0];
NSLog(@"3");
})
-（void）test { NSLog(@"2") ;}
打印结果是：1、3。
原因：performSelector…afterDelay是向runloop中添加了一个timer定时器，子线程中默认是没有启动runloop的，所以不会执行。
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent*)event {
NSThread*thread = [[NSThreadalloc]initWithBlock:^{
NSLog(@"1");
}];
[threadstart];
BOOLisOk =true;
// isOk 设置为YES时，会导致crash， 因为在子线程runloop未开启，block执行完毕后，Threadj即退出；会提示此信息：performSelector:onThread:withObject:waitUntilDone:modes:]: target thread exited while waiting for the perform'
// 设置为NO，test不执行。
[self performSelector:@selector(test) onThread:thread withObject:nil waitUntilDone:isOk];
}
多线程存在安全隐患，同一个数据可能会被多个线程共享，也就是多个线程可能会访问同一块资源，当多个线程访问同一块资源时，很容易引发数据错乱和数据安全问题。这种情况，我们需要使用线程同步技术（同步，就是协同步调，按预定的先后次序进行）解决。常用的方式是加锁。
iOS线程同步方案:
1, OSSpinLock 自旋锁：
OSSpinLock叫做”自旋锁”，等待锁的线程会处于忙等（busy-wait）状态，一直占用着CPU资源
目前已经不再安全，可能会出现优先级反转问题
如果等待锁的线程优先级较高，它会一直占用着CPU资源，优先级低的线程就无法释放锁
需要导入头文件#import
OSSpinLock lock = OS_SPINLOCK_INIT;
OSSpinLockLock(&_moneyLock);
//coding here
OSSpinLockUnlock(&_moneyLock);
2, os_unfair_lock
nos_unfair_lock用于取代不安全的OSSpinLock ，从iOS10开始才支持
n从底层调用看，等待os_unfair_lock锁的线程会处于休眠状态，并非忙等
n需要导入头文件#import
os_unfair_lock lock = OS_UNFAIR_LOCK_INIT;
os_unfair_lock_lock(&_ticketLock);
// coding here
os_unfair_lock_unlock(&_ticketLock);
3, pthread_mutex
mutex叫做”互斥锁”，等待锁的线程会处于休眠状态。需要导入头文件#import
{ // 静态初始化
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
// 初始化属性
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_DEFAULT);
// 初始化锁
pthread_mutex_init(mutex, &attr);
// 销毁属性
pthread_mutexattr_destroy(&attr);
// 初始化锁 NULL表示默认属性
pthread_mutex_init(mutex, NULL);
}
{
pthread_mutex_lock(&_ticketMutex);
//coding here...
pthread_mutex_unlock(&_ticketMutex);
}
- (void)dealloc{
pthread_mutex_destroy(&mutex);
}
4, pthread_mutex 递归锁
用法和3类似，上述pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE)
5, pthread_mutex – 条件锁
使用方法展示：
pthread_mutex_t mutex;
pthread_mutex_init(&mutex, NULL); //NULL表示使用默认属性
// 初始化条件
pthread_cond_t condition;
pthread_cond_init(&condition, NULL);
// 等待条件(进入休眠，释放mutex锁； 被唤醒后，会再次对mutex加锁)
pthread_cond_wait(&condition, &mutex);
//激活一个等待该条件的线程
pthread_cond_signal(&condition);
//激活所有等待该条件的线程
pthread_cond_broadcast(&condition);
- (void) del{
pthread_mutex_lock(&_mutex);
pthread_cond_wait(&_cond, &_mutex);
// coding here
pthread_mutex_unlock(&_mutex);
}
-(void)append {
pthread_mutex_lock(&_mutex);
// coding here
pthread_cond_signal(&_cond); // 信号
pthread_mutex_unlock(&_mutex);
}
- (void)dealloc {
pthread_mutex_destory(&mutex);
pthread_cond_destory(&condition);
}
6,NSLock
NSLock是对mutex普通锁的封装, 遵守NSLocking协议
7,NSRecursiveLock
NSRecursiveLock也是对mutex递归锁的封装，API跟NSLock基本一致
8，NSCondition
NSCondition是对mutex和cond的封装，使用演示如下：
NSCondition *condition = [[NSCondition alloc] init];
- (void)del{
[condition lock];
[condition wait]; // 等待
// coding here
[condition unlock];
}
- (void)add{
[self.condition lock];
// coding here
[self.condition broadcast];
[self.condition unlock];
}
9, NSConditionLock
NSConditionLock是对NSCondition的进一步封装，可以设置具体的条件值。简列使用如下：
int start = 0; 设置某个启动条件
NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition: start];
[conditionLock lock];
[conditionLock lockWhenCondition: some];
[conditionLock unlockWithCondition:some];
[conditionLock unlock];
10，dispatch_semaphore
semaphore叫做”信号量”，信号量的初始值，可以用来控制线程并发访问的最大数量，信号量的初始值为1，代表同时只允许1条线程访问资源，可以用来保证线程同步。
dispatch_semaphore_t semaphore = dispatch_semaphore_create(x);
//当信号量的值<=0,当前线程就会进入休眠等待（直到信号量的值大于0）
//如果信号量的值>0,就减1，然后执行后面的代码
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
dispatch_semaphore_signal(semaphore);
11， dispatch_queue
直接使用GCD的串行队列，也是可以实现线程同步的。
12，@synchronized
@synchronized是对mutex递归锁的封装；@synchronized(obj)内部会生成obj对应的递归锁，然后进行加锁、解锁操作。
@synchronized (token) {}
13, atomic用于保证属性setter、getter的原子性操作，相当于在getter和setter内部加了线程同步的锁, 它并不能保证使用属性的过程是线程安全的。
线程同步方案性能比较,性能从高到低排序依次是：
os_unfair_lock > OSSpinLock > dispatch_semaphore > pthread_mutex > pdispatch_queue(DISPATCH_QUEUE_SERIAL) > NSLock > NSCondition > ppthread_mutex(recursive) > NSRecursiveLock > NSConditionLock > @synchronized
自旋锁、互斥锁比较:
a, 什么情况使用自旋锁比较划算？
预计线程等待锁的时间很短
加锁的代码（临界区）经常被调用，但竞争情况很少发生
CPU资源不紧张
多核处理器
b,什么情况使用互斥锁比较划算？
预计线程等待锁的时间较长
单核处理器
临界区有IO操作
临界区代码复杂或者循环量大
临界区竞争非常激烈