线程安全是怎么产生的
比如线程内操作了一个线程外的非线程安全变量，就要考虑线程的安全和同步。
- (void)getIamgeName:(NSMutableArray *)imageNames{//假如每个进来的都是一个线程
/*1.imageNames是线程外的变量，这个时候就需要考虑线程安全，
因为，假如我们当前imageNames的个数是1，线程A和B同时进来发现个数是大于0的，
都会去执行remove操作，结果肯定会有一个线程崩溃掉。
*/
/*2.NSMutableArray *array = [[NSMutableArray alloc]initWithArray:imageNames];
这里如果新生成一个array，下面也把imageNames换成array就不需要考虑线程安全，
但是这样array.count判断永远大于0，也就是永远等于imageNames.count
*/
NSString *imageName;
if(imageNames.count>0) {
imageName = [imageNames lastObject];
[imageNamesremoveObject:imageName];
}
}
锁的同步方案
锁的概念：
锁是最常用的同步工具。一段代码段在同一个时间只能允许被一个线程访问，比如一个线程A进入加锁代码之后由于已经加锁，另一个线程B就无法访问，只有等待前一个线程A执行完加锁代码后解锁，B线程才能访问加锁的代码。
NSLock
在Cocoa程序中NSLock中实现了一个简单的互斥锁，实现了NSLocking protocol。
lock：加锁，unlock：解锁
tryLock：尝试加锁，如果失败了，并不会阻塞线程，只是立即返回NO，使用tryLock并不能成功加锁，如果获取锁失败就不会执行加锁的代码了。
noLockBeforeDate: 在指定的date之前暂时阻塞线程（如果没有获取锁的话），如果到期还没有获取锁，则线程被唤醒，线程从阻塞状态变为非阻塞状态，函数立即返回NO。
- (void)getIamgeName:(NSMutableArray *)imageNames{
NSString *imageName;
[lock lock];
if(imageNames.count>0) {
imageName = [imageNames lastObject];
[imageNames removeObject:imageName];
}
[lock unlock];
}
@synchronized代码
每个iOS开发最早接触的线程锁就是@synchronized。它的作用是创建一个互斥锁，保证此时没有其它的线程对self对象进行修改。这个是OC的一个锁定令牌，防止self对象在同一个时间内被其它的线程访问，起到线程保护的作用。一般在公用变量的时候使用，如单例模式或者操作类的static变量中使用，大概就是如果线程A访问一对象时，线程B才能够去操作。@synchronized(id anyObject)是最简单的方法，会自动对参数对象加锁，保证临界区内代码线程的安全
- (void)myMethod:(id)anObj{
@synchronized(anObj){
// Everything between the braces is protected by the @synchronized directive.
}}
创建给@synchronized指令的对象是一个用来区别保护块的唯一标示符。如果你在两个不同的线程里面执行上述方法，每次在一个线程传递了一个不同的对象给anyObject参数，那么每次都将会拥有它的锁，并持续处理，中间不被其他线程阻塞。然而，如果你传递的是同一个对象，那么多个线程中的一个线程会首先获得该锁，而其他线程将会被阻塞直到第一个线程完成它的临界区。
作为一种预防措施，@synchronized块隐式的添加一个异常处理例程来保护代码。该处理例程会在异常抛出的时候自动的释放互斥锁。这意味着为了使用@synchronized指令，你必须在你的代码中启用异常处理。如果你不想让隐式的异常处理例程带来额外的开销，你应该考虑使用锁的类。
条件锁NSCondition
NSCondition同样实现了NSLocking协议，所以它和NSLock一样，也有NSLocking协议的lock和unlock方法，可以当作NSLock来使用解决线程同步的问题，用法完全一样。
同时，NSCondition提供更高级的用法。wait和signal，和条件信号量类似。
比如我们要监听imageNames数组的个数，当imageNames的个数大于0的时候就执行清空操作。思路是这样的，当imageNames个数大于0时执行清空操作，否则，wait等待执行清空操作。当imageNames个数增加的时候发生signal信号，让等待的线程唤醒继续执行。
NSCondition和NSLock、@synchronized等是不同的是，NSCondition可以给每个线程分别加锁，加锁后不影响其他线程进入临界区。这是非常强大。
但是正是因为这种分别加锁的方式，NSCondition使用wait并使用加锁后并不能真正的解决资源的竞争。比如我们有个需求：不能让m<0。假设当前m=0,线程A要判断到m>0为假,执行等待；线程B执行了m=1操作，并唤醒线程A执行m-1操作的同时线程C判断到m>0，因为他们在不同的线程锁里面，同样判断为真也执行了m-1，这个时候线程A和线程C都会执行m-1,但是m=1，结果就会造成m=-1.
当我用数组做删除试验时，做增删操作并不是每次都会出现，大概3-4次后会出现。单纯的使用lock、unlock是没有问题的。
条件锁NSConditionLock
NSConditionLock同样实现了NSLocking协议，试验过程中发现性能很低。
NSConditionLock也可以像NSCondition一样做多线程之间的任务等待调用，而且是线程安全的。
递归锁NSRecursiveLock
有时候“加锁代码”中存在递归调用，递归开始前加锁，递归调用开始后重复执行此方法以至于反复执行加锁代码最终造成死锁，这个时候可以使用递归锁来解决。使用递归锁可以在一个线程中反复获取锁而不造成死锁，这个过程中会记录获取锁和释放锁的次数，只有最后两者平衡锁才会被最终的释放。
NSDistributedLock
NSDistributedLock是mac开发中跨进程的分布式锁，底层是用文件系统实现的互斥锁。NSDistributedLock没有实现NSLocking协议，所以没有lock方法，取而代之的是非阻塞的tryLock方法。
NSDistributedLock *lock= [[NSDistributedLock alloc] initWithPath:@"/Users/mac/Desktop/lock.lock"];
while(![locktryLock]) {
sleep(1);
}
//do something
[lockunlock];
当执行到do something时程序退出，程序再次启动之后tryLock就再也不能成功了，陷入死锁状态。其它应用也不能访问受保护的共享资源。在这种情况下，你可以使用breakLock方法来打破现存的锁以便你可以获取它。但是通常应该避免打破锁，除非你确定拥有进程已经死亡并不可能再释放该锁。
