AFNetworking源码中的读写锁
AF网络库里有一个叫做AFAutoPurgingImageCache的类，用来做网络图片的内存缓存。核心原理就是创建一个NSMutableDictionary字典，用键值对来存储图片和相应的URL路径，并且提供了自动管理缓存空间的特性（当缓存空间不足时，自动按时间顺序清理图片）。由于这个缓存类是用来在多线程的环境中使用的，除了使用Foundation提供的锁（如NSLock）以外，源码中采用了GCD的方式，确保字典的线程安全。
串行队列保护锁
如何用GCD来进行锁操作呢？可以使用串行队列，将任务依次添加到一个线程中，每个任务（不管是读/写操作）都要等前面的任务结束后，才可以执行，执行过程中也不用担心被后面的任务抢占资源。
比如创建一个名叫synchronizationQueue的图片存取队列，注意是串行队列！
self.cachedImages = [[NSMutableDictionary alloc] init];
self.synchronizationQueue = dispatch_queue_create("com.example.imagecache", DISPATCH_QUEUE_SERIAL);
然后实现存取方法：
- (void)setImage:(UIImage *)image withURLString:(NSString *)urlString {
dispatch_async(self.synchronizationQueue, ^{
self.cachedImages[urlString] = image;
});
}
- (UIImage *)imageWithURLString:(NSString *)urlString {
__block UIImage *image = nil;
dispatch_sync(self.synchronizationQueue, ^{
image = self.cachedImages[urlString];
});
return image;
}
其中保存图片的操作可以用dispatch_async异步将任务分发到队列中，然后立即返回，不会阻塞当前线程；但是读取图片时，就需要dispatch_sync同步获取图片，所以会立即执行block拿到图片，并且作为方法返回值。于是所有图片的存取操作都放在一个线程中执行，实现了字典的线程安全。
读写锁
不过AF源码并没有用串行队列来存取图片，而是使用了并行队列。下面是真正的源码：
self.cachedImages = [[NSMutableDictionary alloc] init];
NSString *queueName = [NSString stringWithFormat:@"com.alamofire.autopurgingimagecache-%@", [[NSUUID UUID] UUIDString]];
self.synchronizationQueue = dispatch_queue_create([queueName cStringUsingEncoding:NSASCIIStringEncoding], DISPATCH_QUEUE_CONCURRENT);
那么问题来了：
- 相比串行队列锁，改用并行队列有什么好处？
- 如何在并行队列中保证字典读写的线程安全？
先回答第一个问题，串行队列虽然保证了数据的读写安全，但是效率并不高，比如同一时间遇到大量对数据的访问操作时，就需要依次排队，按顺序使用资源。而数据的访问操作本身是安全的，只要数据没有被篡改，其实完全可以通过多线程并发访问。只有遇到写操作时，我们等之前所有数据的访问任务结束后，再开始写入操作，并且确保数据改动过程中，让新的访问操作排队等着就好。这其实是计算机科学中的读写锁(Reader/writer lock或者multiple readers/single-writer lock)的理念。
说完了理论，那么如何在并行队列中保证字典读写安全呢？答案是栅栏barrier，直接看源码，精简以后就是这样：
- (void)addImage:(UIImage *)image withIdentifier:(NSString *)identifier {
// 异步栅栏派发操作
dispatch_barrier_async(self.synchronizationQueue, ^{
AFCachedImage *cacheImage = [[AFCachedImage alloc] initWithImage:image identifier:identifier];
// 如果之前保存了重复图片，删除并从总缓存中减去该图片的占用空间值...
// 保存图片
self.cachedImages[identifier] = cacheImage;
// 将新图片的占用空间计算到总缓存中...
});
// 接着又一个异步栅栏派发操作
dispatch_barrier_async(self.synchronizationQueue, ^{
// 缓存自动计算和清理：
// 如果图片缓存空间大于预设值，就按照访问时间顺序，依次清理掉时间最久远的图片
if (...) {
// ...
for (AFCachedImage *cachedImage in sortedImages) {
[self.cachedImages removeObjectForKey:cachedImage.identifier];
// ...
}
}
});
}
在写入操作时，dispatch_barrier_async中的栅栏任务在添加到并行队列中，会等待队列中之前所有的任务结束后，才开始执行（也就是图片的缓存操作）；而且在执行栅栏任务过程中，后续的新任务（无论读/写）必须等待，直到该栅栏任务结束后才能继续执行。源码在上面的写入方法中连续用了两个异步栅栏，于是队列会完成先前的所有任务，再依次执行栅栏任务1、栅栏任务2，以及后续任务。即使两个栅栏任务中都对字典数据做了改动，依然遵循先后顺序，不会出现资源竞争。再加上这是异步派发，所以写操作将任务加入队列中就会立即返回，而不会阻塞当前的调用线程。
下面是读取图片的实现：
- (nullable UIImage *)imageWithIdentifier:(NSString *)identifier {
__block UIImage *image = nil;
dispatch_sync(self.synchronizationQueue, ^{
AFCachedImage *cachedImage = self.cachedImages[identifier];
// 读取并更新图片的访问时间
image = [cachedImage accessImage];
});
return image;
}
读取操作时，dispatch_sync会立即返回相应图片，由于这是在并发队列中，因此读取操作可以被指派到任意一个新的线程中完成，而不会被限制在单一线程中，这样就保证了并发访问的需求。
再看下缓存清理的实现：
- (BOOL)removeAllImages {
__block BOOL removed = NO;
dispatch_barrier_sync(self.synchronizationQueue, ^{
if (self.cachedImages.count > 0) {
[self.cachedImages removeAllObjects];
self.currentMemoryUsage = 0;
removed = YES;
}
});
return removed;
}
这里使用了dispatch_barrier_sync，不仅保证了清理任务的排它性（也就是上面分析过的barrier特性），而且remove方法会等待block中的清理任务执行完毕后返回结果。
选择Lock还是GCD
当然各种锁的API（比如NSLock, dispatch_semaphore）同样能够实现保护字典线程安全的任务，所以替换成lock()和unlock()之类的方式应该也是可以的，不过像NSLock这类锁只是确保被保护的资源在任何时间只能被一个线程访问，并不具备读写锁的特性；而GCD实现的读写锁不仅允许并发访问，而且使用了异步的缓存操作也不会阻塞调用线程，比如缓存图片时还要及时更新缓存空间，甚至按清理条件删除图片的话，那么读写锁反而更有优势。像SDWebImage在SDMemoryCache中实现了图片内存缓存，就是直接使用锁操作，原因是缓存时没有附加额外的任务（比如管理缓存空间之类的事情都交给了NSCache和内存警告通知处理），确保了缓存任务的快速和轻量，并没有像AFAutoPurgingImageCache对缓存空间个性化的控制要求。所以选择Lock还是GCD，还得看具体的需求。
