C语言iOS中的“锁事”

抛砖引玉

说交锁不得不提线程安全,说交线程安全,作为iOS程序员又不得不提
nonatomicatomic

  • nonatomic 不会见针对转移的 gettersetter 方法加同步锁(非原子性)
  • atomic 会对转移的 gettersetter 加一起锁(原子性)

setter / getteratomic
修饰的性能时,该属性是读写安全之。然而读写安全并无代表线程安全。

线程安全概念(thread safety)

  • 线程安全就是多线程访问时,采用了加锁机制,当一个线程访问该类的某部数常常,进行维护,其他线程不能够进行访问直到该线程读取了,其他线程才可下。不见面面世数量不均等或数额传。
  • 线程不安全就是是勿提供数据访问保护,有或出现多个线程先后更改数据造成所取的多少是污染数据。

验证 atomic 非线程安全

  • 说明代码

#import "ViewController.h"

@interface ViewController ()

@property (strong, atomic) NSString *name;

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];

    //atomic非线程安全验证
    //Jack
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        while (1) {
            self.name = @"Jack";
            NSLog(@"Jack is %@", self.name);
        }
    });

    //Rose
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        while (1) {
            self.name = @"Rose";
            NSLog(@"Rose is %@", self.name);
        }
    });
}
  • 证结果

2017-11-29 11:21:27.713446+0800 LockDemo[42637:1199500] Jack is Jack
2017-11-29 11:21:27.713487+0800 LockDemo[42637:1199499] Rose is Rose
2017-11-29 11:21:27.713638+0800 LockDemo[42637:1199500] Jack is Jack
2017-11-29 11:21:27.713659+0800 LockDemo[42637:1199499] Rose is Rose
2017-11-29 11:21:27.713840+0800 LockDemo[42637:1199500] Jack is Jack
2017-11-29 11:21:27.714050+0800 LockDemo[42637:1199499] Rose is Rose
2017-11-29 11:21:27.714205+0800 LockDemo[42637:1199500] Jack is Jack
2017-11-29 11:21:27.718069+0800 LockDemo[42637:1199499] Rose is Rose
2017-11-29 11:21:27.718069+0800 LockDemo[42637:1199500] Jack is Rose
2017-11-29 11:21:27.718199+0800 LockDemo[42637:1199500] Jack is Jack
2017-11-29 11:21:27.718199+0800 LockDemo[42637:1199499] Rose is Jack

末尾一行和倒数第三实践得看出,atomic 非线程安全证明了。

  • 也就是说 atomic
    只能完成读写安全并无可知得线程安全,若一旦实现线程安全还索要以更深层的锁定机制才实施。
  • iOS开发时一般都见面动用 nonatomic
    属性,因为以iOS中动用同步锁的开支比较生,这会带性能问题,但是当Mac
    OS X程序时,使用 atomic 属性通常还不见面产生性瓶颈。

絮之概念

以处理器是中,锁是同样栽共同机制,用于在存在多线程的环境面临施行对资源的顾限制。

絮的作用

  • 初步来讲:就是为防备在多线程的状态下本着共享资源的脏读或者脏写。
  • 为可掌握也:执行多线程时用来强行限制资源访问的一道机制,即并作控制着保证互斥的要求。

iOS开发被常用之锁

  • @synchronized
  • NSLock 对象锁
  • NSRecursiveLock 递归锁
  • NSConditionLock 条件锁
  • pthread_mutex 互斥锁(C语言)
  • dispatch_semaphore 信号量实现加锁(GCD
  • OSSpinLock 自旋锁

特性图来源:ibireme

@synchronized

@synchronized 其实是一个 OC 层面的锁,
主要是由此牺牲性能换来语法上之简要和可读性。
@synchronized 是咱平常使用最多的可性能最差之。
OC写法:

@synchronized(self) {
    //需要执行的代码块
}

swift写法:

objc_sync_enter(self)
//需要执行的代码块
objc_sync_exit(self)

代码示例:

    //线程1
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        @synchronized(self) {
            NSLog(@"第一个线程同步操作开始");
            sleep(3);
            NSLog(@"第一个线程同步操作结束");
        }
    });
    //线程2
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        sleep(1);
        @synchronized(self) {
            NSLog(@"第二个线程同步操作");
        }
    });

结果:

2017-11-29 14:36:52.056457+0800 LockDemo[46145:1306472] 第一个线程同步操作开始
2017-11-29 14:36:55.056868+0800 LockDemo[46145:1306472] 第一个线程同步操作结束
2017-11-29 14:36:55.057261+0800 LockDemo[46145:1306473] 第二个线程同步操作
  • @synchronized(self) 指令以的 self
    为该锁的唯一标识,只有当标识相同时,才为满足互斥,如果线程2丁之
    self 改成为其他对象,线程2尽管非会见于打断。

    NSString *s = [NSString string];
    //线程1
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        @synchronized(self) {
            NSLog(@"第一个线程同步操作开始");
            sleep(3);
            NSLog(@"第一个线程同步操作结束");
        }
    });
    //线程2
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        sleep(1);
        @synchronized(s) {
            NSLog(@"第二个线程同步操作");
        }
    });

2017-11-29 14:43:54.930414+0800 LockDemo[46287:1312173] 第一个线程同步操作开始
2017-11-29 14:43:55.930761+0800 LockDemo[46287:1312158] 第二个线程同步操作
2017-11-29 14:43:57.932287+0800 LockDemo[46287:1312173] 第一个线程同步操作结束
  • @synchronized
    指令实现锁之长就是是咱们不需以代码中显式的开创锁对象,便足以实现锁之机制,但当同种植预防措施,@synchronized
    块会隐式的增长一个百般处理来保护代码,该处理会在大抛来底时候自动的自由互斥锁。所以要是未思叫隐式的雅处理例程带来额外的出,你得设想用锁对象。

NSLock

  • NSLock 中实现了一个简约的互斥锁。通过 NSLocking 协议定义了
    lockunlock 方法。

@protocol NSLocking

- (void)lock;
- (void)unlock;

@end

举个栗子卖冰棍儿

- (void)nslockTest {
    //设置冰棍儿的数量为5
    _count = 5;

    //创建锁
    _lock = [[NSLock alloc] init];

    //线程1
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        [self saleIceCream];
    });

    //线程2
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        [self saleIceCream];
    });
}

- (void)saleIceCream
{
    while (1) {
        sleep(1);
        //加锁
        [_lock lock];
        if (_count > 0) {
            _count--;
            NSLog(@"剩余冰棍儿数= %ld, Thread - %@", _count, [NSThread currentThread]);
        } else {
            NSLog(@"冰棍儿卖光光  Thread - %@",[NSThread currentThread]);
            break;
        }
        //解锁
        [_lock unlock];
    }
}

加锁结果:

2017-11-29 16:21:29.728198+0800 LockDemo[55262:1411318] 剩余冰棍儿数= 4, Thread - <NSThread: 0x604000475dc0>{number = 3, name = (null)}
2017-11-29 16:21:29.728428+0800 LockDemo[55262:1411319] 剩余冰棍儿数= 3, Thread - <NSThread: 0x604000475e00>{number = 4, name = (null)}
2017-11-29 16:21:30.729009+0800 LockDemo[55262:1411318] 剩余冰棍儿数= 2, Thread - <NSThread: 0x604000475dc0>{number = 3, name = (null)}
2017-11-29 16:21:30.729378+0800 LockDemo[55262:1411319] 剩余冰棍儿数= 1, Thread - <NSThread: 0x604000475e00>{number = 4, name = (null)}
2017-11-29 16:21:31.733061+0800 LockDemo[55262:1411318] 剩余冰棍儿数= 0, Thread - <NSThread: 0x604000475dc0>{number = 3, name = (null)}
2017-11-29 16:21:31.733454+0800 LockDemo[55262:1411319] 冰棍儿卖光光  Thread - <NSThread: 0x604000475e00>{number = 4, name = (null)}

勿加锁结果:

2017-11-29 16:23:38.702352+0800 LockDemo[55316:1412917] 剩余冰棍儿数= 3, Thread - <NSThread: 0x604000270b80>{number = 3, name = (null)}
2017-11-29 16:23:38.702352+0800 LockDemo[55316:1412919] 剩余冰棍儿数= 4, Thread - <NSThread: 0x604000271040>{number = 4, name = (null)}
2017-11-29 16:23:39.705096+0800 LockDemo[55316:1412919] 剩余冰棍儿数= 2, Thread - <NSThread: 0x604000271040>{number = 4, name = (null)}
2017-11-29 16:23:39.705099+0800 LockDemo[55316:1412917] 剩余冰棍儿数= 1, Thread - <NSThread: 0x604000270b80>{number = 3, name = (null)}
2017-11-29 16:23:40.709617+0800 LockDemo[55316:1412919] 剩余冰棍儿数= 0, Thread - <NSThread: 0x604000271040>{number = 4, name = (null)}
2017-11-29 16:23:40.709617+0800 LockDemo[55316:1412917] 冰棍儿卖光光  Thread - <NSThread: 0x604000270b80>{number = 3, name = (null)}
2017-11-29 16:23:41.714002+0800 LockDemo[55316:1412919] 冰棍儿卖光光  Thread - <NSThread: 0x604000271040>{number = 4, name = (null)}
  • NSLock 类还长了 tryLocklockBeforeDate: 方法

- (BOOL)tryLock;
- (BOOL)lockBeforeDate:(NSDate *)limit;

tryLock
试图获取一个锁,但是如果锁不可用的时,它不会见卡住线程,相反,它仅是返NO。
lockBeforeDate:
方法计算取一个沿,但是只要锁没有在规定的年华外叫拿走,它会让线程从阻塞状态变为不阻塞状态(或者返回NO)。

NSRecursiveLock 递归锁

有时候“加锁代码”中是递归调用,递归开始前加锁,递归调用开始后会更执行这个方法以至于反复实践加锁代码最终致使死锁。

- (void)recursiveLockTest {
    //创建锁
    _lock = [[NSLock alloc] init];

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void(^TestMethod)(int);
        TestMethod = ^(int value)
        {
            [_lock lock];
            if (value > 0)
            {
                [NSThread sleepForTimeInterval:1];
                value--;
                TestMethod(value);
            }
            [_lock unlock];
        };
        TestMethod(5);
        NSLog(@"结束");
    });
}

咱俩发现 “结束”
永远不会见于打印出,这个时候可以用递归锁来化解。使用递归锁得在一个线程中屡获取锁而休招死锁,这个进程中见面记录得锁与释放锁的次数,只有最终双方平衡锁才于最终释放。

- (void)recursiveLockTest {
    //创建锁
    _recursiveLock = [[NSRecursiveLock alloc] init];

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void(^TestMethod)(int);
        TestMethod = ^(int value)
        {
            [_recursiveLock lock];
            if (value > 0)
            {
                [NSThread sleepForTimeInterval:1];
                value--;
                TestMethod(value);
            }
            [_recursiveLock unlock];
        };
        TestMethod(5);
        NSLog(@"结束");
    });
}

这时候 “结束” 5秒后会受打印出。

NSConditionLock 条件锁

NSCoditionLock 做多线程之间的职责等调用,而且是线程安全之。

- (void)conditionLockTest {

    NSInteger HAS_DATA = 1;
    NSInteger NO_DATA = 0;

    _conditionLock = [[NSConditionLock alloc] initWithCondition:NO_DATA];
    NSMutableArray *products = [NSMutableArray array];

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        while (1) {
            [_conditionLock lockWhenCondition:NO_DATA];
            [products addObject:[[NSObject alloc] init]];
            NSLog(@"生产");
            [_conditionLock unlockWithCondition:HAS_DATA];
            sleep(5);
        }
    });

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        while (1) {
            NSLog(@"等待");
            [_conditionLock lockWhenCondition:HAS_DATA];
            [products removeObjectAtIndex:0];
            NSLog(@"售卖");
            [_conditionLock unlockWithCondition:NO_DATA];
        }
    });
}

NSConditionLock 也和其他的缉一样,是需要 lockunlock
对应的,只是 lock , lockWhenCondition:unlock
unlockWithCondition: 是可以肆意组合的,当然这是暨需要相关的。

POSIX(pthread_mutex)

  • C语言定义下大半线程加锁方式。 pthread_mutex 和 dispatch_semaphore_t
    很像,但是完全两样。pthread_mutex
    是Unix/Linux平台上提供的平模仿条件互斥锁的API。
  • 新建一个大概的 pthread_mutex 互斥锁,引入头文件
    #import <pthread.h> 声明并初始化一个 pthread_mutex_t
    的结构。使用 pthread_mutex_lockpthread_mutex_unlock
    函数。调用 pthread_mutex_destroy 来刑释解教该锁的数据结构。

使用:
#import <pthread.h>

- (void)pthreadTest {
    __block pthread_mutex_t theLock;
    pthread_mutex_init(&theLock, NULL);

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        pthread_mutex_lock(&theLock);
        NSLog(@"第一个线程同步操作开始");
        sleep(3);
        NSLog(@"第一个线程同步操作结束");
        pthread_mutex_unlock(&theLock);

    });

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        sleep(1);
        pthread_mutex_lock(&theLock);
        NSLog(@"第二个线程同步操作");
        pthread_mutex_unlock(&theLock);

    });
}

实践结果:

2017-11-29 17:51:11.901064+0800 LockDemo[56729:1466788] 第一个线程同步操作开始
2017-11-29 17:51:14.904834+0800 LockDemo[56729:1466788] 第一个线程同步操作结束
2017-11-29 17:51:14.905195+0800 LockDemo[56729:1466789] 第二个线程同步操作
  • pthread_mutex 还得创造标准锁,提供了与 NSCondition
    一样的尺度决定,初始化互斥锁同时采取 pthread_cond_init
    来初始化条件数据结构

    // 初始化
    int pthread_cond_init (pthread_cond_t *cond, pthread_condattr_t *attr);
    // 等待(会阻塞)
    int pthread_cond_wait (pthread_cond_t *cond, pthread_mutex_t *mut);
    // 定时等待
    int pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mut, const struct timespec *abstime);
    // 唤醒
    int pthread_cond_signal (pthread_cond_t *cond);
    // 广播唤醒
    int pthread_cond_broadcast (pthread_cond_t *cond);
    // 销毁
    int pthread_cond_destroy (pthread_cond_t *cond);

pthread_mutex 还提供了广大函数,有同一仿完整的API,包含 Pthreads
线程的创控制等等,非常底层,可以手动处理线程的依次状态的变换即管理生命周期,甚至足以实现均等模仿好的多线程,感兴趣之得延续深入摸底。

dispatch_semaphore_t

dispatch_semaphore_t
GCD中信号量,也得以化解资源抢占问题,支持信号通知以及信号等。每当发送一个信号通知,则信号量
+1;每当发送一个等信号时信号量 -1,;如果信号量为 0
则信号会处于等候状态,直到信号量大于 0 开始实践。

api注释:

/*! 
 * @param value
 *信号量的起始值,当传入的值小于零时返回NULL
 * @result
 * 成功返回一个新的信号量,失败返回NULL
 */
dispatch_semaphore_t dispatch_semaphore_create(long value)

/*!
 * @discussion
 * 信号量减1,如果结果小于0,那么等待队列中信号增量到来直到timeout
 * @param dsema
 * 信号量
 * @param timeout
 * 等待时间
 * 类型为dispatch_time_t,这里有两个宏DISPATCH_TIME_NOW、DISPATCH_TIME_FOREVER
 * @result
 * 若等待成功返回0,timeout返回非0
 */
long dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout);

/*!
 * @discussion
 * 信号量加1,如果之前的信号量小于0,将唤醒一条等待线程
 * @param dsema 
 * 信号量
 * @result
 * 唤醒一条线程返回非0,否则返回0
 */
long dispatch_semaphore_signal(dispatch_semaphore_t dsema)

使用:

- (void)semaphoreTest {
    // 创建信号量
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);
    //线程1
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
        NSLog(@"任务1");
        sleep(10);
        dispatch_semaphore_signal(semaphore);
    });

    //线程2
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        sleep(1);
        dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
        NSLog(@"任务2");
        dispatch_semaphore_signal(semaphore);
    });
}

履行结果:

2017-11-30 14:38:11.943521+0800 LockDemo[91493:2075379] 任务1
2017-11-30 14:38:21.946222+0800 LockDemo[91493:2075380] 任务2

OSSpinLock 自旋锁

使用:
#import <libkern/OSAtomic.h>

__block OSSpinLock theLock = OS_SPINLOCK_INIT;
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    OSSpinLockLock(&theLock);
    NSLog(@"第一个线程同步操作开始");
    sleep(3);
    NSLog(@"第一个线程同步操作结束");
    OSSpinLockUnlock(&theLock);
});

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    OSSpinLockLock(&theLock);
    sleep(1);
    NSLog(@"第二个线程同步操作");
    OSSpinLockUnlock(&theLock);
});

执行结果:

2017-11-30 15:12:31.701180+0800 LockDemo[92422:2104479] 第一个线程同步操作开始
2017-11-30 15:12:39.705473+0800 LockDemo[92422:2104479] 第一个线程同步操作结束
2017-11-30 15:12:39.705820+0800 LockDemo[92422:2104478] 第二个线程同步操作开始

OSSpinLock 自旋锁,性能最高的吊。它的瑕疵是当等时见面消耗大量 CPU
资源,不太适用于较长时间的任务。 YY大神在博客 不再安全之
OSSpinLock
中说明了OSSpinLock已经不复安全,暂勿建议使用。

iOS 10 之后,苹果吃来了解决方案,就是之所以 os_unfair_lock 代替
OSSpinLock。

'OSSpinLockLock' is deprecated: first deprecated in iOS 10.0 - Use os_unfair_lock_lock() from <os/lock.h> instead

#import <os/lock.h>

    __block os_unfair_lock  lock = OS_UNFAIR_LOCK_INIT;
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        os_unfair_lock_lock(&lock);
        NSLog(@"第一个线程同步操作开始");
        sleep(8);
        NSLog(@"第一个线程同步操作结束");
        os_unfair_lock_unlock(&lock);
    });

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        sleep(1);
        os_unfair_lock_lock(&lock);
        NSLog(@"第二个线程同步操作开始");
        os_unfair_lock_unlock(&lock);
    });

行结果:

2017-11-30 15:12:31.701180+0800 LockDemo[92422:2104479] 第一个线程同步操作开始
2017-11-30 15:12:39.705473+0800 LockDemo[92422:2104479] 第一个线程同步操作结束
2017-11-30 15:12:39.705820+0800 LockDemo[92422:2104478] 第二个线程同步操作开始

总结

  • @synchronized:适用线程不多,任务量不老的多线程加锁
  • NSLock:性能不算是差,但感到用的口非多。
  • dispatch_semaphore_t:使用信号来做加锁,性能大高跟 OSSpinLock
    差不多。
  • NSConditionLock:多线程处理不同任务的通信建议时用,
    只加锁之说话性能大没有。
  • NSRecursiveLock:性能是,使用状况限制为递归。
  • POSIX(pthread_mutex):C语言的平底api,复杂的多线程处理建议采取,也得以打包好之多线程。
  • OSSpinLock:性能好强,可惜不安全了,使用 os_unfair_lock 来代替。