GCD中的信号量

理解这个概念之前,先抛出一个问题

问题描述:

假设现在系统有两个空闲资源可以被利用,但同一时间却有三个线程要进行访问,这种情况下,该如何处理呢?

或者

我们要下载很多图片,并发异步进行,每个下载都会开辟一个新线程,可是我们又担心太多线程肯定cpu吃不消,那么我们这里也可以用信号量控制一下最大开辟线程数。

定义:

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

其实,这有点类似锁机制了,只不过信号量都是系统帮助我们处理了,我们只需要在执行线程之前,设定一个信号量值,并且在使用时,加上信号量处理方法就行了。

2、信号量主要有3个函数,分别是:

//创建信号量,参数:信号量的初值,如果小于0则会返回NULL
dispatch_semaphore_create(信号量值)

//等待降低信号量
dispatch_semaphore_wait(信号量,等待时间)

//提高信号量
dispatch_semaphore_signal(信号量)
  
注意,正常的使用顺序是先降低然后再提高,这两个函数通常成对使用。 (具体可参考下面的代码示例) 

3、那么就开头提的问题,我们用代码来解决

-(void)dispatchSignal{
//crate的value表示,最多几个资源可访问
dispatch_semaphore_t semaphore = dispatch_semaphore_create(2);
dispatch_queue_t quene = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

//任务1
dispatch_async(quene, ^{
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
NSLog(@”run task 1″);
sleep(1);
NSLog(@”complete task 1″);
dispatch_semaphore_signal(semaphore);
});
//任务2
dispatch_async(quene, ^{
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
NSLog(@”run task 2″);
sleep(1);
NSLog(@”complete task 2″);
dispatch_semaphore_signal(semaphore);
});
//任务3
dispatch_async(quene, ^{
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
NSLog(@”run task 3″);
sleep(1);
NSLog(@”complete task 3″);
dispatch_semaphore_signal(semaphore);
});
}

执行结果:
run task 1
run task 2
complete task 2
complete task 1  
run task 3
complete task 3

总结:由于设定的信号值为2,先执行两个线程,等执行完一个,才会继续执行下一个,保证同一时间执行的线程数不超过2。

这里我们扩展一下,假设我们设定信号值=1
dispatch_semaphore_create(1)
那么结果就是:
run task 1
complete task 1 
run task 2
complete task 2
run task 3
complete task 3

如果设定信号值=3
dispatch_semaphore_create(3)
那么结果就是:
run task 3
run task 2
run task 1
complete task 3
complete task 2
complete task 1  

其实设定为3,就是不限制线程执行了,因为一共才只有3个线程。

以上只是举的比较简单的例子,在一些特殊场景下,合理利用信号量去控制,能够方便的解决我们的难题哦

NSRunLoop理解

1.NSRunLoop是IOS消息机制的处理模式
NSRunLoop的主要作用:控制NSRunLoop里面线程的执行和休眠,在有事情做的时候使当前NSRunLoop控制的线程工作,没有事情做让当前NSRunLoop的控制的线程休眠。

2.NSRunLoop 就是一直在循环检测,从线程start到线程end,检测inputsource(如点击,双击等操作)同步事件,检测timesource同步事件,检测到输入源会执行处理函数,首先会产生通知,corefunction向线程添加runloop observers来监听事件,意在监听事件发生时来做处理。

3.runloopmode是一个集合,包括监听:事件源,定时器,以及需通知的runloop observers

模式包括:

default模式:几乎包括所有输入源(除NSConnection) NSDefaultRunLoopMode模式

mode模式:处理modal panels

connection模式:处理NSConnection事件,属于系统内部,用户基本不用

event tracking模式:如组件拖动输入源 UITrackingRunLoopModes 不处理定时事件

common modes模式:NSRunLoopCommonModes 这是一组可配置的通用模式。将input sources与该模式关联则同时也将input sources与该组中的其它模式进行了关联。

4.每次运行一个run loop,你指定(显式或隐式)run loop的运行模式。当相应的模式传递给run loop时,只有与该模式对应的 input sources才被监控并允许run loop对事件进行处理(与此类似,也只有与该模式对应的observers才会被通知)

5.NSTimer默认添加到当前NSRunLoop中,也可以手动制定添加到自己新建的NSRunLoop的中
[NSTimer schduledTimerWithTimeInterval: target:selector:userInfo:repeats];

此方法默认添加到当前NSRunLoop中
NSTimer *timer = [NSTimer timerWithTimeInterval: invocation:repeates:];
NSTimer *timer = [[NSTimer alloc] initWithFireDate:…];
创建timer [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];

注意 timer的释放

例:
1). 在timer与table同时执行情况,当拖动table时,runloop进入UITrackingRunLoopModes模式下,不会处理定时事 件,此时timer不能处理,所以此时将timer加入到NSRunLoopCommonModes模式(addTimer forMode)

2).在滚动一个页面时来松开,此时connection不会收到消息,由于scroll时runloop为UITrackingRunLoopModes模式,不接收输入源,此时要修改connection的mode

[scheduleInRunLoop:[NSRunLoop currentRunLoop]forMode:NSRunLoopCommonModes];

6、子线程中的NSRunLoop需要手动启动,在子线程中使用timer要启动NSRunLoop。
7、关于-(BOOL)runMode:(NSString *)mode beforeDate:(NSDate *)date;方法
指定runloop模式来处理输入源,首个输入源或date结束退出。
暂停当前处理的流程,转而处理其他输入源,当date设置为NSDate distantFuture,所以除非处理其他输入源结束,否则永不退出处理暂停的当前处理的流程。

8.while(A){
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}
当前A为YES时,当前runloop会一直接收处理其他输入源,当前流程不继续处理,出为A为NO,当前流程继续

9 、perform selector在thread中被序列化执行,这样就缓和了许多在同一个thread中运行多个方法所产生的同步问题。perform selector source在运行完selector后自动从run loop中移除。
当 在非main thread中perform selector时,其thread中必须有一个激活的run loop。对于你自己创建的thread而 言,只有你的代码显式的运行一个run loop后该perform selector才能得到执行。Run loop在当loop运行时处理所有已排队 的perform selector,而不是在一个loop循环时只处理某一个perform selector。

10.performSelector 关于内存管理的执行原理是这样的执 行 [self performSelector:@selector(method1:) withObject:self.tableLayer afterDelay:3]; 的 时候,系统会将tableLayer的引用计数加1,执行完这个方法时,还会将tableLayer的引用计数减1,由于延迟这时tableLayer的 引用计数没有减少到0,也就导致了切换场景dealloc方法没有被调用,出现了内存泄露。
利用如下函数:

[NSObject cancelPreviousPerformRequestsWithTarget:self]

当然你也可以一个一个得这样用:

[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(method1:) object:nil]

加上了这个以后,顺利地执行了dealloc方法

在touchBegan里面

[self performSelector:@selector(longPressMethod:) withObject:nil afterDelay:longPressTime]

然后在end 或cancel里做判断,如果时间不够长按的时间调用:

[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(longPressMethod:) object:nil]

取消began里的方法

**********************************以下是我在cocoachina中看到的一份总结 转载过来

线程实现的几种方式:

Operation Objects // NSOperation及相关子类
***** // dispatch_async等相关函数
Idle-time notifications // NSNotificationQueue,低优先级
Asynchronous functions // 异步函数
Timers // NSTimer
Separate processes // 没用过
线程创建的成本:
kernel data structures 约1KB
Stack space 512KB(secondary threads)
1MB(iOS main thread)
Creation time 约90 microseconds

Run Loop和线程的关系:

主线程的run loop默认是启动的,用于接收各种输入sources
对第二线程来说,run loop默认是没有启动的,如果你需要更多的线程交互则可以手动配置和启动,如果线程执行一个长时间已确定的任务则不需要。
Run Loop什么情况下使用:
a. 使用ports 或 input sources 和其他线程通信 // 不了解
b. 在线程中使用timers // 如果不启动run loop,timer的事件是不会响应的
c. 在Cocoa 应用中使用performSelector…方法 // 应该是performSelector…这种方法会启动一个线程并启动run loop吧
d. 让线程执行一个周期性的任务 // 如果不启动run loop, 线程跑完就可能被系统释放了

注:timer的创建和释放必须在同一线程中。
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes]; 此方法会retain timer对象的引用计数

【iOS】weak的底层实现

weak原理概括

weak表其实是一个hash(哈希)表,Key是所指对象的地址,Value是weak指针的地址数组。weak的底层实现的原理是什么?

Runtime维护了一个weak表,用于存储指向某个对象的所有weak指针。weak表其实是一个hash表,Key是所指对象的地址,value是weak指针的地址(这个地址的值是所指对象指针的地址)数组。

为什么value是数组?因为一个对象可能被多个弱引用指针指向

weak原理实现步骤

weak 的实现原理可概括三步:

1、初始化时:runtime会调用objc_initWeak函数,初始化一个新的weak指针指向对象的地址。
2、添加引用时:objc_initWeak函数会调用 objc_storeWeak() 函数, objc_storeWeak() 的作用是更新指针指向,创建对应的弱引用表。
3、释放时,调用clearDeallocating函数。clearDeallocating函数首先根据对象地址获取所有weak指针地址的数组,然后遍历这个数组把其中的数据设为nil,最后把这个entry从weak表中删除,最后清理对象的记录。

weak实现三步骤详细过程:

1、初始化时:runtime会调用objc_initWeak函数,objc_initWeak函数会初始化一个新的weak指针指向对象的地址。

示例代码:
NSObject *obj = [[NSObject alloc] init];
id __weak obj1 = obj;

当我们初始化一个weak变量时,runtime会调用 NSObject.mm 中的objc_initWeak函数。

这个函数在Clang中的声明如下:

id objc_initWeak(id *object, id value);

而对于 objc_initWeak() 方法的实现如下:
id objc_initWeak(id *location, id newObj) {
// 查看对象实例是否有效,无效对象直接导致指针释放
if (!newObj) {
*location = nil;
return nil;
}
// 这里传递了三个 bool 数值
// 使用 template 进行常量参数传递是为了优化性能
return storeWeakfalse/*old*/, true/*new*/, true/*crash*/>
(location, (objc_object*)newObj);
}

这里先判断了其指针指向的类对象是否有效,无效直接释放返回,不再往深层调用函数。否则,object将通过bjc_storeWeak函数被注册为一个指向value的__weak对象。
注意:objc_initWeak函数有一个前提条件:就是object必须是一个没有被注册为__weak对象的有效指针。而value则可以是null,或者指向一个有效的对象。

2、添加引用时:objc_initWeak函数会调用 objc_storeWeak() 函数, objc_storeWeak() 的作用是更新指针指向,创建对应的弱引用表。
objc_storeWeak的函数声明如下:
id objc_storeWeak(id *location, id value);
objc_storeWeak() 的具体实现,请参考weak弱引用实现的方式,这里的实现很复杂,没看懂,没看懂。

3、释放时,调用clearDeallocating函数。clearDeallocating函数首先根据对象地址获取所有weak指针地址的数组,然后遍历这个数组把其中的数据设为nil,最后把这个entry从weak表中删除,最后清理对象的记录。

当weak引用指向的对象被释放时,又是如何去处理weak指针的呢?当释放对象时,其基本流程如下:
1、调用objc_release
2、因为对象的引用计数为0,所以执行dealloc
3、在dealloc中,调用了_objc_rootDealloc函数
4、在_objc_rootDealloc中,调用了object_dispose函数
5、调用objc_destructInstance
6、最后调用objc_clear_deallocating,详细过程如下:
a. 从weak表中获取废弃对象的地址为键值的记录
b. 将包含在记录中的所有附有 weak修饰符变量的地址,赋值为 nil
c. 将weak表中该记录删除
d. 从引用计数表中删除废弃对象的地址为键值的记录

拓展补充

weak,__unsafe_unretained, unowned 与 assign区别

__unsafe_unretained: 不会对对象进行retain,当对象销毁时,会依然指向之前的内存空间(野指针)

weak: 不会对对象进行retain,当对象销毁时,会自动指向nil

assign: 实质与__unsafe_unretained等同

unsafe_unretained也可以修饰代表简单数据类型的property,weak也不能修饰用来代表简单数据类型的property。

__unsafe_unretained 与 weak 比较,使用 weak 是有代价的,因为通过上面的原理可知,__weak需要检查对象是否已经消亡,而为了知道是否已经消亡,自然也需要一些信息去跟踪对象的使用情况。也正因此,__unsafe_unretained 比 __weak快,所以当明确知道对象的生命期时,选择__unsafe_unretained 会有一些性能提升,这种性能提升是很微小的。但当很清楚的情况下,__unsafe_unretained 也是安全的,自然能快一点是一点。而当情况不确定的时候,应该优先选用 __weak 。

unowned使用在Swift中,也会分 weak 和 unowned。unowned 的含义跟 __unsafe_unretained 差不多。假如很明确的知道对象的生命期,也可以选择 unowned。

iOS开发中的11种锁以及性能对比

在具体说这些锁之前,先来说几个概念定义:(参考维基百科)

临界区:指的是一块对公共资源进行访问的代码,并非一种机制或是算法。
自旋锁:是用于多线程同步的一种锁,线程反复检查锁变量是否可用。由于线程在这一过程中保持执行,因此是一种忙等待。一旦获取了自旋锁,线程会一直保持该锁,直至显式释放自旋锁。 自旋锁避免了进程上下文的调度开销,因此对于线程只会阻塞很短时间的场合是有效的。
互斥锁(Mutex):是一种用于多线程编程中,防止两条线程同时对同一公共资源(比如全局变量)进行读写的机制。该目的通过将代码切片成一个一个的临界区而达成。
读写锁:是计算机程序的并发控制的一种同步机制,也称“共享-互斥锁”、多读者-单写者锁) 用于解决多线程对公共资源读写问题。读操作可并发重入,写操作是互斥的。 读写锁通常用互斥锁、条件变量、信号量实现。
信号量(semaphore):是一种更高级的同步机制,互斥锁可以说是semaphore在仅取值0/1时的特例。信号量可以有更多的取值空间,用来实现更加复杂的同步,而不单单是线程间互斥。
条件锁:就是条件变量,当进程的某些资源要求不满足时就进入休眠,也就是锁住了。当资源被分配到了,条件锁打开,进程继续运行。

互斥锁

1.NSLock:是Foundation框架中以对象形式暴露给开发者的一种锁,(Foundation框架同时提供了NSConditionLock,NSRecursiveLock,NSCondition)NSLock定义如下:
@protocol NSLocking
– (void)lock;
– (void)unlock;
@end
@interface NSLock : NSObject {
@private
void *_priv;
}
– (BOOL)tryLock;
– (BOOL)lockBeforeDate:(NSDate *)limit;
@property (nullable, copy) NSString *name API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));
@end

tryLock 和 lock 方法都会请求加锁,唯一不同的是trylock在没有获得锁的时候可以继续做一些任务和处理。lockBeforeDate方法也比较简单,就是在limit时间点之前获得锁,没有拿到返回NO。

实际项目中:NSLock在AFNetworking的AFURLSessionManager.m中应用如下:

– (instancetype)initWithSessionConfiguration:(NSURLSessionConfiguration *)configuration {

self.lock = [[NSLock alloc] init];
self.lock.name = AFURLSessionManagerLockName;

}
– (void)setDelegate:(AFURLSessionManagerTaskDelegate *)delegate
forTask:(NSURLSessionTask *)task
{

[self.lock lock];
self.mutableTaskDelegatesKeyedByTaskIdentifier[@(task.taskIdentifier)] = delegate;
[delegate setupProgressForTask:task];
[self addNotificationObserverForTask:task];
[self.lock unlock];
}
2.pthread_mutex:

实际项目中: 在YYKit的YYMemoryCach中可以看到
– (instancetype)init {

pthread_mutex_init(&_lock, NULL);

}
– (void)_trimToCost:(NSUInteger)costLimit {
BOOL finish = NO;
pthread_mutex_lock(&_lock);
if (costLimit == 0) {
[_lru removeAll];
finish = YES;
} else if (_lru->_totalCost <= costLimit) { finish = YES; } pthread_mutex_unlock(&_lock); if (finish) return; NSMutableArray *holder = [NSMutableArray new]; while (!finish) { if (pthread_mutex_trylock(&_lock) == 0) { if (_lru->_totalCost > costLimit) {
_YYLinkedMapNode *node = [_lru removeTailNode];
if (node) [holder addObject:node];
} else {
finish = YES;
}
pthread_mutex_unlock(&_lock);
} else {
usleep(10 * 1000); //10 ms
}
}

}
3.@synchronized:

实际项目中:AFNetworking中 isNetworkActivityOccurring属性的getter方法

– (BOOL)isNetworkActivityOccurring {
@synchronized(self) {
return self.activityCount > 0;
}
}
关于 @synchronized推荐扩展阅读 关于 @synchronized,这儿比你想知道的还要多

自旋锁

1.OSSpinLock:
OSSpinLock lock = OS_SPINLOCK_INIT;
OSSpinLockLock(&lock);

OSSpinLockUnlock(&lock);
上面是OSSpinLock使用方式,编译会报警告,已经废弃了,OSSpinLock大家也已经不再用它了,因为它在某一些场景下已经不安全了,可以参考 YY大神的不再安全的 OSSpinLock,在Protocol Buffers项目中你可以看到这样的注释,大家已经用新的方案替换了。

// NOTE: OSSpinLock may seem like a good fit here but Apple engineers have
// pointed out that they are vulnerable to live locking on iOS in cases of
// priority inversion:
// http://mjtsai.com/blog/2015/12/16/osspinlock-is-unsafe/
// https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000372.html
2.os_unfair_lock:

os_unfair_lock 是苹果官方推荐的替换OSSpinLock的方案,但是它在iOS10.0以上的系统才可以调用。

os_unfair_lock_t unfairLock;
unfairLock = &(OS_UNFAIR_LOCK_INIT);
os_unfair_lock_lock(unfairLock);
os_unfair_lock_unlock(unfairLock);
读写锁

上文有说到,读写锁又称共享-互斥锁,

pthread_rwlock:

//加读锁
pthread_rwlock_rdlock(&rwlock);
//解锁
pthread_rwlock_unlock(&rwlock);
//加写锁
pthread_rwlock_wrlock(&rwlock);
//解锁
pthread_rwlock_unlock(&rwlock);
递归锁

递归锁有一个特点,就是同一个线程可以加锁N次而不会引发死锁。

1.NSRecursiveLock:

NSRecursiveLock在YYKit中YYWebImageOperation.m中有用到:

_lock = [NSRecursiveLock new];
– (void)dealloc {
[_lock lock];


[_lock unlock];
}
2.pthread_mutex(recursive):

pthread_mutex锁也支持递归,只需要设置PTHREAD_MUTEX_RECURSIVE即可

pthread_mutex_t lock;
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(&lock, &attr);
pthread_mutexattr_destroy(&attr);
pthread_mutex_lock(&lock);
pthread_mutex_unlock(&lock);
条件锁

1. NSCondition:

定义:
@interface NSCondition : NSObject {
@private
void *_priv;
}
– (void)wait;
– (BOOL)waitUntilDate:(NSDate *)limit;
– (void)signal;
– (void)broadcast;

遵循NSLocking协议,使用的时候同样是lock,unlock加解锁,wait是傻等,waitUntilDate:方法是等一会,都会阻塞掉线程,signal是唤起一个在等待的线程,broadcast是广播全部唤起。

NSCondition *lock = [[NSCondition alloc] init];
//Son 线程
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[lock lock];
while (No Money) {
[lock wait];
}
NSLog(@”The money has been used up.”);
[lock unlock];
});

//Father线程
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[lock lock];
NSLog(@”Work hard to make money.”);
[lock signal];
[lock unlock];
});
2.NSConditionLock:

定义:

@interface NSConditionLock : NSObject {
@private
void *_priv;
}
– (instancetype)initWithCondition:(NSInteger)condition NS_DESIGNATED_INITIALIZER;
@property (readonly) NSInteger condition;
– (void)lockWhenCondition:(NSInteger)condition;
– (BOOL)tryLock;
– (BOOL)tryLockWhenCondition:(NSInteger)condition;
– (void)unlockWithCondition:(NSInteger)condition;
– (BOOL)lockBeforeDate:(NSDate *)limit;
– (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit;

很简单,方法很清晰,基本同上。

信号量

dispatch_semaphore:

dispatch_semaphore在YYKit中的YYThreadSafeArray.m有所应用,YY大神有这样一句注释:

@discussion Generally, access performance is lower than NSMutableArray,
but higher than using @synchronized, NSLock, or pthread_mutex_t.

#define LOCK(…) dispatch_semaphore_wait(_lock, DISPATCH_TIME_FOREVER); \
__VA_ARGS__; \
dispatch_semaphore_signal(_lock);