YYThreadSafeArray是YYKit中的一個工具類，旨在提供線程安全的數組。YYThreadSafeArray的原理是繼承NSMutableArray的，并且對其中必要的方法加鎖來保證線程安全。但是，雖然YYKit在開源界使用廣泛，但是YYThreadSafeArray依然有一些多線程方面的問題。其中部分問題在我們的項目中暴露和修復。
問題1：調用枚舉方法導致死鎖
調用方式：
YYThreadSafeArray *array = [[YYThreadSafeArray alloc] initWithObjects:@"hello world", nil];
[array enumerateObjectsUsingBlock:^(id _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
[array count];
}];
導致問題：
死鎖。
原因分析：
YYThreadSafeArray使用加鎖的方式保證線程安全。加的鎖是信號量：dispatch_semaphore。
#define LOCK(...) dispatch_semaphore_wait(_lock, DISPATCH_TIME_FOREVER); \
__VA_ARGS__; \
dispatch_semaphore_signal(_lock);
dispatch_semaphore并不是可重入的。因此，遇到重入的情況，就會發(fā)生死鎖問題。舉的例子只是其中一個死鎖場景。
YY選擇使用dispatch_semaphore的原因，可能是判斷dispatch_semaphore的執(zhí)行效率較高。可以參考YY對各種鎖的效率測評：https://blog.ibireme.com/2016/01/16/spinlock_is_unsafe_in_ios/
修復方法：
使用pthread_mutex替代dispatch_semaphore。pthread_mutex有參數可以設置為可重入。在YY測試的執(zhí)行效率上，可重入的pthread_mutex是可重入鎖中效率較高的一個。
問題2：判等導致死鎖
在使用pthread_mutex替代dispatch_semaphore的方式修復了可重入鎖的問題后，我們發(fā)現YYThreadSafeArray在判等處的代碼是有死鎖隱患的。
調用方式：
YYThreadSafeArray *threadSafeArrayA = [[YYThreadSafeArray alloc] init];
YYThreadSafeArray *threadSafeArrayB = [[YYThreadSafeArray alloc] init];
for (int i = 0; i < 1000000; i++) {
[threadSafeArrayA addObject:@(i)];
[threadSafeArrayB addObject:@(i)];
}
for (int i = 0; i < 10000; i++) {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[threadSafeArrayB isEqualToArray:threadSafeArrayA];
});
[threadSafeArrayA isEqualToArray:threadSafeArrayB];
}
如果兩個線程中，同時分別執(zhí)行
[A isEqualToArray:B];
和
[B isEqualToArray:A];
則會有一定概率死鎖。
原因分析：
我們查看YYThreadSafeArray中isEqualToArray方法的源碼：
- (BOOL)isEqualToArray:(NSArray *)otherArray {
if (otherArray == self) return YES;
if ([otherArray isKindOfClass:YYThreadSafeArray.class]) {
YYThreadSafeArray *other = (id)otherArray;
BOOL isEqual;
dispatch_semaphore_wait(_lock, DISPATCH_TIME_FOREVER);
dispatch_semaphore_wait(other->_lock, DISPATCH_TIME_FOREVER);
isEqual = [_arr isEqualToArray:other->_arr];
dispatch_semaphore_signal(other->_lock);
dispatch_semaphore_signal(_lock);
return isEqual;
}
return NO;
}
在線程1中調用
[A isEqualToArray:B];
此時，執(zhí)行完
dispatch_semaphore_wait(_lock, DISPATCH_TIME_FOREVER);
這行，A的_lock鎖進入鎖住狀態(tài)。
同時，線程2調用
[B isEqualToArray:A];
執(zhí)行完
dispatch_semaphore_wait(_lock, DISPATCH_TIME_FOREVER);
這行，B的_lock鎖也進入鎖住狀態(tài)。
那么線程1在執(zhí)行下一行
dispatch_semaphore_wait(other->_lock, DISPATCH_TIME_FOREVER);
時，由于B ->_lock已經被鎖住，線程1不得不阻塞在此，等待B的鎖被解鎖。
而同時，B也在執(zhí)行同一行代碼時，在等待A的鎖被解鎖。
這就造成了死鎖的情形。
代碼類似的isEqual:方法也有一樣的問題。
修復方法：
為了修復這個場景，我們引入了一個新的全局的鎖，將整個方法鎖起來，防止兩個線程同時進入isEqualToArray:方法中。
問題3：for-in循環(huán)的線程不安全
YYThreadSafeArray在只用for-in循環(huán)時，是無法保證線程安全的。
調用方式：
YYThreadSafeArray *threadSafeArray = [[YYThreadSafeArray alloc] init];
for (int i = 0; i < 1000000; i++) {
[threadSafeArray addObject:@(i)];
}
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
for (int i = 0; i < 100000; i++) {
[threadSafeArray removeLastObject];
}
});
for (id obj in threadSafeArray) {
(void)obj;
}
此時大概率會拋出異常：
*** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <YYThreadSafeArray: 0x60000165aa20> was mutated while being enumerated.'
原因分析：
在執(zhí)行for-in循環(huán)時，會調用NSArray的
- (NSUInteger)countByEnumeratingWithState:(NSFastEnumerationState *)state
objects:(id __unsafe_unretained[])stackbuf
count:(NSUInteger)len;
方法。
for-in循環(huán)之所以有更高的效率，是因為在循環(huán)時，它并非每次都訪問NSArray數組，而是直接將一段NSArray數組，當作一個C數組來訪問，直接便利這個C數組。對于NSArray來說，state.itemsPtr字段將返回這個C數組的指針。
但在這個方法中加鎖，鎖住的只是尋找這個C數組的過程，并不能鎖住整個for-in循環(huán)過程。所以，當多線程進入時，會拋出was mutated while being enumerated異常。
修復方法：
這個問題沒有想到優(yōu)雅的修復方法。有2種不怎么優(yōu)雅的方式可選：
- 讓調用方用enumerateObjectsUsingBlock這種遍歷方法替代for-in循環(huán)，但在效率上肯定有折損；
- 將YYThreadSafeArray種的鎖暴露出去，讓業(yè)務方在for-in循環(huán)時自行加鎖。
但這兩種方法都依賴于調用方以一個特定的姿勢來調用。如果調用姿勢無法保證，YYThreadSafeArray也無法保證線程安全了。
