最近突发奇想，想对比下几个不同Cache框架的实现，于是就从项目中在用的PINCache着手分析。PINCache是Pinterest的程序员在Tumblr的TMCache基础上发展而来的，主要的改进是修复了dealock的bug，TMCache已经不再维护了，而PINCache最新版本是v2.2。
PINCache从对象上来划分：
PINCache只是PINDiskCache+PINMemoryCache的封装，具体的操作包括：get，set，remove，trim，都是通过这两个内部对象来完成。
1.PINCache的实现方式
采用Disk(文件) + Memory(其实就是NSDictionary)的双存储方式，在cache数据的管理上，都是采用键值对的方式进行管理，其中Disk文件的存储路径形式为：APP/Library/Caches/com.pinterest.PINDiskCache.(name)，Memory内存对象的存储为键值存储。在执行set操作的同时会记录文件/对象的更新date和成本cost，对于date和cost两个属性，有对应的API允许开发者按照date和cost清除PINCache管理的文件和内存，如清除某个日期之前的cache数据，清除cost大于X的cache数据。
在Cache的操作实现上，PINCache采用dispatch_queue+dispatch_semaphore的方式，dispatch_queue是并发队列，为了保证线程安全采用dispatch_semaphore作锁，从bireme的这篇文章中了解到，dispatch_semaphore的优势在于不会轮询状态的改变，适用于低频率的Disk操作，而像Memory这种高频率的操作，反而会降低性能，所以ibireme 实现的YYCache对MemoryCache的同步机制选用OSSpinLock，而不是dispatch_semaphore，当然OSSpinLock和dispatch_semaphore正好相反，当条件不满足时会轮询，导致CPU占用率升高。
PINCache实现了同步和异步两套操作Cache的API
同步方式阻塞访问线程，直到操作成功：
- (__nullable id)objectForKey:(NSString *)key;
- (void)setObject:(id)object forKey:(NSString *)key;
- (void)removeObjectForKey:(NSString *)key;
异步方式具体操作在并发队列上完成后会根据传入的block把结果返回出来：
- (void)objectForKey:(NSString *)key block:(PINCacheObjectBlock)block;
- (void)setObject:(id)object forKey:(NSString *)key block:(nullable PINCacheObjectBlock)block;
- (void)removeObjectForKey:(NSString *)key block:(nullable PINCacheObjectBlock)block;
2.PINDiskCache
DiskCache有以下属性：
@property (readonly) NSString *name;//指定的cache名称，如MyPINCacheName，在Library/Caches/目录下
@property (readonly) NSURL *cacheURL;//cache目录URL，如Library/Caches/com.pinterest.PINDiskCache.MyPINCacheName，这个才是真实的存储路径
@property (readonly) NSUInteger byteCount;//disk存储的文件大小
@property (assign) NSUInteger byteLimit;//disk上允许存储的最大字节
@property (assign) NSTimeInterval ageLimit;//存储文件的最大生命周期
@property (nonatomic, assign, getter=isTTLCache) BOOL ttlCache;//TTL强制存储，如果为YES，访问操作不会延长该cache对象的生命周期，如果试图访问一个生命超出self.ageLimit的cache对象时，会当做该对象不存在。
为了遵循Cocoa的设计哲学，PINCache还允许用户自定义block用以监听add，remove操作事件，不是KVO，却似KVO：
@property (copy) PINDiskCacheObjectBlock __nullable willAddObjectBlock;
@property (copy) PINDiskCacheObjectBlock __nullable didAddObjectBlock;
@property (copy) PINDiskCacheObjectBlock __nullable willRemoveObjectBlock;
@property (copy) PINDiskCacheObjectBlock __nullable didRemoveObjectBlock;
对应PINCache的同步异步两套API，PINDiskCache也有两套实现，不同之处在于同步操作会在函数开始加锁，函数结尾释放锁，而异步操作只在对关键数据操作时才加锁，执行完后立即释放，这样在一个函数内部可能要完成多次加锁解锁的操作，这样提高了PINCache的并发操作效率，但对性能也是一个考验。
3.PINMemoryCache
PINMemoryCache的属性：
@property (readonly) NSUInteger totalCost;//开销总数
@property (assign) NSUInteger costLimit;//允许的内存最大开销
@property (assign) NSTimeInterval ageLimit;//same as PINDiskCache
@property (nonatomic, assign, getter=isTTLCache) BOOL ttlCache;//same as PINDiskCache
@property (assign) BOOL removeAllObjectsOnMemoryWarning;//内存警告时是否清除memory cache
@property (assign) BOOL removeAllObjectsOnEnteringBackground;//App进入后台时是否清除memory cache
4.操作安全性
(1)PINDiskCache的同步API
- (void)setObject:(id)object forKey:(NSString *)key fileURL:(NSURL **)outFileURL {
...
[self lock];
//1.archive对象
//2.修改对象的访问日期
//3.更新PINDiskCache成员变量
[self unlock];
}
整个操作都是在lock状态下完成的，保证了对disk文件操作的互斥
其他的objectForKey,removeObjectForKey操作也是这种实现方式。
(1)PINDiskCache的异步API
- (void)setObject:(id)object forKey:(NSString *)key block:(PINDiskCacheObjectBlock)block {
__weak PINDiskCache *weakSelf = self;
dispatch_async(_asyncQueue, ^{//向并发队列加入一个task，该task同样是同步执行PINDiskCache的同步API
PINDiskCache *strongSelf = weakSelf;
[strongSelf setObject:object forKey:key fileURL:&fileURL];
if (block) {
[strongSelf lock];
block(strongSelf, key, object, fileURL);
[strongSelf unlock];
}
});
}
(3)PINMemoryCache的同步API
- (void)setObject:(id)object forKey:(NSString *)key withCost:(NSUInteger)cost {
[self lock];
PINMemoryCacheObjectBlock willAddObjectBlock = _willAddObjectBlock;
PINMemoryCacheObjectBlock didAddObjectBlock = _didAddObjectBlock;
NSUInteger costLimit = _costLimit;
[self unlock];
if (willAddObjectBlock)
willAddObjectBlock(self, key, object);
[self lock];
_dictionary[key] = object;//更新key对应的object
_dates[key] = [[NSDate alloc] init];
_costs[key] = @(cost);
_totalCost += cost;
[self unlock];//释放lock，此时在并发队列上的别的操作如objectForKey可以获取同一个key对应的object，但是拿到的都是同一个对象
...
}
PINMemoryCache的并发安全性依赖于PINMemoryCache维护了一个NSMutableDictionary，每一个key-value的读取和设置都是互斥的，即信号量保证了这个NSMutableDictionary的操作是线程安全的，其实Cocoa的容器类如NSArray，NSDictionary，NSSet都是线程安全的，而NSMutableArray，NSMutableDictionary则不是线程安全的，所以这里在对PINMemoryCache的NSMutableDictionary进行操作时需要加锁互斥。
那么假如从PINMemoryCache中根据一个key取到的是一个mutable的Collection对象，就会出现如下情况：
1.线程A和B都读到了一份value，NSMutableDictionary，它们是同一个对象
2.线程A对读出的NSMutableDictionary进行更新操作
3.线程B对读出的NSMutableDictionary进行更新操作
这就有可能导致执行出错，因为NSMutableDictionary不是线程安全的，所以在对PINCache进行业务层的封装时，要保证更新操作的串行化，避免并行更新操作的情况。
参考：Apple线程安全总结