線程安全
1.線程安全的概念
多條線程同時工作的情況下,通過運用線程鎖,原子性等方法避免多條線程因為同時訪問同一快內存造成的數據錯誤或沖突.
2.多線程數據為什么不安全
每條線程都有自己獨立的棧空間. 但是他們公用了堆. 所以他們可能同時訪問同一塊內存空間. 因此造成數據沖突.
3.解決線程安全的方法
線程鎖, 原子性.
補充
線程安全是相對的概念. 根據蘋果的文檔, 原子性并不能保證線程安全. 只是相對運用了原子性keyword 的屬性來說是線程安全的. 對于類來說則不一定.
使用 atomic 一定是線程安全的么?
不是的。
nonatomic的內存管理語義是非原子性的，非原子性的操作本來就是線程不安全的，而atomic的操作是原子性的，但是并不意味著它是線程安全的，它會增加正確的幾率，能夠更好的避免線程的錯誤，但是它仍然是線程不安全的。
當使用nonatomic的時候，屬性的setter，getter操作是非原子性的，所以當多個線程同時對某一屬性讀和寫操作時，屬性的最終結果是不能預測的。
當使用atomic時，雖然對屬性的讀和寫是原子性的，但是仍然可能出現線程錯誤：當線程A進行寫操作，這時其他線程的讀或者寫操作會因為該操作而等待。當A線程的寫操作結束后，B線程進行寫操作，然后當A線程需要讀操作時，卻獲得了在B線程中的值，這就破壞了線程安全，如果有線程C在A線程讀操作前release了該屬性，那么還會導致程序崩潰。所以僅僅使用atomic并不會使得線程安全，我們還要為線程添加lock來確保線程的安全。
也就是要注意：atomic所說的線程安全只是保證了getter和setter存取方法的線程安全，并不能保證整個對象是線程安全的。如下列所示：
比如：@property(atomic,strong)NSMutableArray *arr;
如果一個線程循環的讀數據，一個線程循環寫數據，那么肯定會產生內存問題，因為這和setter、getter沒有關系。如使用[self.arr objectAtIndex:index]就不是線程安全的。好的解決方案就是加鎖。
據說，atomic要比nonatomic慢大約20倍
探討一下Objective-C中幾種不同方式實現的鎖，在這之前我們先構建一個測試用的類，假想它是我們的一個共享資源，method1與method2是互斥的，代碼如下：
@implementationTestObj
- (void)method1?
{
? ? NSLog(@"%@",NSStringFromSelector(_cmd));
}
- (void)method2
{
? ? NSLog(@"%@",NSStringFromSelector(_cmd));
}
@end
1.使用NSLock實現的鎖
//主線程中
TestObj *obj = [[TestObj alloc] init];
NSLock *lock = [[NSLock alloc] init];
//線程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
? ? [lock lock];
? ? [obj method1];
? ? sleep(10);
? ? [lock unlock];
});
//線程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
? ? sleep(1);//以保證讓線程2的代碼后執行
? ? [lock lock];
? ? [obj method2];
? ? [lock unlock];
});
看到打印的結果了嗎，你會看到線程1鎖住之后，線程2會一直等待走到線程1將鎖置為unlock后，才會執行method2方法。
NSLock是Cocoa提供給我們最基本的鎖對象，這也是我們經常所使用的，除lock和unlock方法外，NSLock還提供了tryLock和lockBeforeDate:兩個方法，前一個方法會嘗試加鎖，如果鎖不可用(已經被鎖住)，剛并不會阻塞線程，并返回NO。lockBeforeDate:方法會在所指定Date之前嘗試加鎖，如果在指定時間之前都不能加鎖，則返回NO。
2.使用synchronized關鍵字構建的鎖
當然在Objective-C中你還可以用@synchronized指令快速的實現鎖：
//主線程中
TestObj *obj = [[TestObj alloc] init];
//線程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
? ? @synchronized(obj){
? ? ? ? [obj method1];
? ? ? ? sleep(10);
? ? }
});
//線程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
? ? sleep(1);
? ? @synchronized(obj){
? ? ? ? [obj method2];
? ? }
});
@synchronized指令使用的obj為該鎖的唯一標識，只有當標識相同時，才為滿足互斥，如果線程2中的@synchronized(obj)改為@synchronized(other),剛線程2就不會被阻塞，@synchronized指令實現鎖的優點就是我們不需要在代碼中顯式的創建鎖對象，便可以實現鎖的機制，但作為一種預防措施，@synchronized塊會隱式的添加一個異常處理例程來保護代碼，該處理例程會在異常拋出的時候自動的釋放互斥鎖。所以如果不想讓隱式的異常處理例程帶來額外的開銷，你可以考慮使用鎖對象。
3.使用C語言的pthread_mutex_t實現的鎖
//主線程中
TestObj *obj = [[TestObj alloc] init];
__block pthread_mutex_t mutex;
pthread_mutex_init(&mutex,NULL);
//線程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
? ? pthread_mutex_lock(&mutex);
? ? [obj method1];
? ? sleep(5);
? ? pthread_mutex_unlock(&mutex);
});
//線程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
? ? sleep(1);
? ? pthread_mutex_lock(&mutex);
? ? [obj method2];
? ? pthread_mutex_unlock(&mutex);
});
pthread_mutex_t定義在pthread.h，所以記得#include
4.使用GCD來實現的”鎖”
以上代碼構建多線程我們就已經用到了GCD的dispatch_async方法，其實在GCD中也已經提供了一種信號機制，使用它我們也可以來構建一把”鎖”(從本質意義上講，信號量與鎖是有區別，具體差異參考信號量與互斥鎖之間的區別):
//主線程中
TestObj *obj = [[TestObj alloc] init];
dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);
//線程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
? ? dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
? ? [obj method1];
? ? sleep(10);
? ? dispatch_semaphore_signal(semaphore);
});
//線程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
? ? sleep(1);
? ? dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
? ? [obj method2];
? ? dispatch_semaphore_signal(semaphore);
});
5.使用自旋鎖OSSpinLock來實現的”鎖”
//主線程中
TestObj *obj = [[TestObj alloc] init];
OSSpinLock spinlock = OS_SPINLOCK_INIT;
//線程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
? ? OSSpinLockLock(&spinlock);
? ? [obj method1];
? ? sleep(10);
? ? OSSpinLockUnlock(&spinlock);
});
//線程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
? ? sleep(1);//以保證讓線程2的代碼后執行
? ? OSSpinLockLock(&spinlock);
? ? [obj method2];
? ? OSSpinLockUnlock(&spinlock);
});
一些高級鎖：詳見Objective-C中不同方式實現鎖(二)
1.NSRecursiveLock遞歸鎖
2.NSConditionLock條件鎖
3.NSDistributedLock分布式鎖
總結：
耗時方面：
OSSpinlock耗時最少;
pthread_mutex其次。
NSLock/NSCondition/NSRecursiveLock 耗時接近，220ms上下居中。
NSConditionLock最差，我們常用synchronized倒數第二。
dispatch_barrier_async也許，性能并不像我們想象中的那么好.推測與線程同步調度開銷有關。單獨block耗時在1ms以下基本上可以忽略不計的。
1、@synchronized
內部會創建一個異常捕獲的handler和其他內部使用的鎖。所以會消耗大量的時間
2、NSLock 和 NSLock+IMP
兩個時間非常接近。他們是pthread mutexes封裝的，但是創建對象的時候需要額外的開銷。
3、pthread_mutex
底層的API，性能比較高。
4、OSSpinLock
自旋鎖幾乎不進入內核，僅僅是重新加載自旋鎖。
如果自旋鎖被占用時間是幾十，上百納秒，性能還是挺高的。減少了代價較高的系統調用和一系列上下文言切換。
但是，該鎖不是萬能的;如果該鎖搶占比較多的時候，不要使用該鎖。會占用較多cpu,導致耗電較多。
這種情況下使用pthread_mutex雖然耗時多一點，但是，避免了電量過多的消耗。是不錯的選擇。
