問題一：App重啟后，NSCache中的東西還存在嗎？
一聽到緩存數據，我們腦海里立馬浮現了《印象筆記》這樣“理所當然”的功能：在WIFI環境中保存過的網絡文章，在沒有網絡時（比如出門在外，關閉4G），看過的文章可以繼續閱讀，并不受網絡關閉的影響。
NSCache可以幫助我們實現這樣的功能嗎？
并不能！！！
NSCache中的數據在APP重啟（或重新init）后，都消失了，并不會保存下來。
也就是說，NSCache的正確名字應該叫做NSMemoryCache，只是將數據保存在內存中。
問題二：可以統計出NSCache中已經緩存的數據大小嗎？
答案依然是否
我們可以使用 countLimit 指定緩存中保存的對象數量，
或用 totalCostLimit屬性 +
- (void)setObject:(id)obj forKey:(id)key cost:(NSUInteger)num方法，勉強實現占用內存的控制。
注意：cost并沒有說明必須等于對象占用的字節數。
這意味NSCache到底占用了多少內存，是使用者（就是苦逼的我們）自己計算的！
NSCache奇葩之處三：釋放內存時，并不確定釋放的對象的順序。
這是什么意思呢？假設我們基于NSCache實現一個無限上拉的列表，當上拉到某一頁，我們存入了當前頁的數據對象，結果觸發了內存警告，NSCache會自動釋放，結果可能是剛存入的數據對象被清理了，而不是我們希望的“先進先出”順序。
相信讀到這里，有些童鞋已經出離憤怒了：這個奇葩緩存有什么用？
NSCache 是線程安全的
很多童鞋第一次實現TableView時，都會使用NSMutableArray當數據源，當實現下拉刷新時，何時清理這個數組就很重要了，如果TableView正在刷新，而數組又被清掉時，就會導致數組越界訪問而崩潰，而使用NSCache就不會有此問題。
結合NSDiscardableContent協議使用
實現了這個協議的類需要在被引用之前，必須調用beginContentAccess來標記為可使用的，如果在使用之前沒有調用beiginContentAccess，那么就會拋出異常。在使用結束之后，調用endContentAccess，來標記它為可以被釋放的。如果實現了NSDiscardableContent協議的對象放入了NSCache中，那么，在清除它的時候，會調用discardContentIfPossible方法來判斷引用狀況，沒有引用，則銷毀。
這樣，我們就可以很“精確”地控制對象的釋放，配合NSCache的內存自動釋放，達到既釋放過期數據的目的，又不用擔心對象過早被釋放，如果另外實現這樣的效果，需要做數據有效性判斷，當然是費時費力。
另外，NSCache的KEY是不需要遵循NSCopying協議的，也就是說，作為KEY的對象并不會被拷貝，利用這點，可以做出一些NSDictionary無法實現的效果，請關注溪石iOS，了解更多開發技巧。
