[seld performSelector:@selector(printLog) withObject:nil afterDelay:0];
方法是需要放在runloop上才可以执行的 儿 我们开启的紫线程默认不开启runloop
实现线程常驻如何实现？
在方法内部开启一个RunLoop
NSLog(@"run －－ 旭宝爱吃鱼");
//添加Port 实时监听
[[NSRunLoop currentRunLoop] addPort:[NSPort port] forMode:NSDefaultRunLoopMode];
//添加runloop
[[NSRunLoop currentRunLoop]run];
while (1) {
//添加runloop
[[NSRunLoop currentRunLoop]run];
}
Thread实现原理？
内部 使用pthread_create线程
当我执行任务执行完成之后 系统会线程的推出管理操作
多线程与锁
1.synchronsized 在单例环境下使用 保证在多线程环境下创建对象是惟一的
2.atomic
3.OSSpinkLock 自旋锁 循环等待的锁，不释放当前资源
4.NSRecuriveLock
5.NSLock
6.dispatch-semaphore_t
self.array = [NSMutableArray array];
可以通过atomic赋值的时候保证线程安全 使用不保证线程安全
OSSpinkLock 主要是防止出现竞争资源这种情况 保证线程安全
自旋锁 循环等待的锁，不释放当前资源
用于轻量级的数据访问，简单的int+1、减一操作
runtime里面对于应用技术 使用自旋锁来加1 减一操作
NSLock 冲入的原因造成死锁
-(void)methodA {
[lock lock];
[self methosB];
[lock lock];
}
-(void)methodB {
[lock lock];
[lock lock];
}
死锁
NSRecuriveLock 递归锁
递归锁专门用于循环或递归中需要同步的代码，但它却不能避免两个线程同时访问锁中代码的情况。而 NSLock 却恰恰相反，它能避免两个线程同时访问锁中的代码，却不能避免在同一线程中，同步代码中嵌套加锁的情况。检查第二段调用递归锁的情况，发现这里根本没有必要使用递归锁，因为代码中既没有递归也没有循环。因此可以放心地将 gopushLock 修改为 NSLock 而不是 NSRecursiveLock。
dispatch-semaphore_t:GCD中可以控制线程的数量 加锁
dispatch_semaphore_t dispatch_semaphore_create(long value);
long dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout); 来了一辆车等待 车位减一
long dispatch_semaphore_signal(dispatch_semaphore_t dsema); 走了一辆车 信号量加1
当信号计数大于0时，每条进来的线程使计数减1，直到变为0，变为0后其他的线程将进不来，处于等待状态；执行完任务的线程释放信号，使计数加1，如此循环下去。
停车场剩余4个车位，那么即使同时来了四辆车也能停的下。如果此时来了五辆车，那么就有一辆需要等待。信号量的值就相当于剩余车位的数目，dispatch_semaphore_wait函数就相当于来了一辆车，dispatch_semaphore_signal。就相当于走了一辆车。停车位的剩余数目在初始化的时候就已经指明了（dispatch_semaphore_create(value:Int)）），调用一次dispatch_semaphore_signal，剩余的车位就增加一个；调用一次dispatch_semaphore_wait剩余车位就减少一个；当剩余车位为0时，再来车（即调用dispatch_semaphore_wait）就只能等待。有可能同时有几辆车等待一个停车位。有些车主。没有耐心，给自己设定了一段等待时间，这段时间内等不到停车位就走了，如果等到了就开进去停车。而有些车主就像把车停在这，所以就一直等下去
进来的线程 是信号量-1 变为0就进不来 完成信号量加1
当信号量变为0 系统会自动阻塞
