LruCache源码解析
lrucache，最近最少使用缓存策略，源码其实很简单，没有多少行。下面我们分两个部分来解析：
第一部分：如何使用
/**
* 存储的key类型
* 存储的value类型
* 设置最大存储容量
* 计算每个存储内容大小
*/
LruCache<String, Bitmap> bitmapLruCache=new LruCache<String, Bitmap>(1024*1024){
@Override
protected int sizeOf(String key, Bitmap value) {
return value.getByteCount();
}
};
public void useLruCache(){
//保存数据
bitmapLruCache.put("111",bitmap);
//获取数据
Bitmap bitmap = bitmapLruCache.get("111");
if(null!=bitmap){
//使用数据
}
}第二部分：源码分析
首先我们先来翻译一下LruCache源码头文件内容：
* A cache that holds strong references to a limited number of values. Each time
* a value is accessed, it is moved to the head of a queue. When a value is
* added to a full cache, the value at the end of that queue is evicted and may
* become eligible for garbage collection.
//这个类是一个强引用的有一定大小限制的缓存类。每次访问这个存储的内容，他都将被放到队列头部
//(这里应该是表述错误，应该是放到队列尾部).如果一个内容想要被添加进一个容量已经满的缓存中
//那么处于缓存队列尾部的内容将会被移除队列，并且被垃圾回收器回收。
*
* <p>If your cached values hold resources that need to be explicitly released,
* override {@link #entryRemoved}.
//如果缓存持有的内容需要被释放掉，那么需要重写entryRemoved方法。
*
* <p>If a cache miss should be computed on demand for the corresponding keys,
* override {@link #create}. This simplifies the calling code, allowing it to
* assume a value will always be returned, even when there's a cache miss.
//如果一个被移除的缓存要求重新回到缓存队列中，那么可以重新create方法。这个方法，允许一个
//将要被回收的内容被重新恢复。
*
* <p>By default, the cache size is measured in the number of entries. Override
* {@link #sizeOf} to size the cache in different units. For example, this cache
* is limited to 4MiB of bitmaps:
//通常情况下，缓存内容的大小根据缓存条目数量来衡量。重新sizeOf方法，可以改变计算缓存内容的方
//法。例如，缓存内容控制在4M以内的缓存bitmap的实例：
* <pre> {@code
* int cacheSize = 4 * 1024 * 1024; // 4MiB
* LruCache<String, Bitmap> bitmapCache = new LruCache<String, Bitmap>(cacheSize) {
* protected int sizeOf(String key, Bitmap value) {
* return value.getByteCount();
* }
* }}</pre>
*
* <p>This class is thread-safe. Perform multiple cache operations atomically by
* synchronizing on the cache: <pre> {@code
* synchronized (cache) {
* if (cache.get(key) == null) {
* cache.put(key, value);
* }
* }}</pre>
* //这个类是线程安全的。
* <p>This class does not allow null to be used as a key or value. A return
* value of null from {@link #get}, {@link #put} or {@link #remove} is
* unambiguous: the key was not in the cache.
//这个类不允许存储的key或者value为null。如果以key保存的内容不存在，那么get put remove方法
//将会返回null通过头文件，我们可以知道：
1.lrucache是线程安全的，关键操作都是枷锁的
2.不允许key或者value为null去缓存数据
3.sizeof方法应该说是必须要重写的，用来计算存储内容大小。如果被缓存的内容移除时需要释放掉，那么entryRemoved 方法中可以释放。当然create方法可以让那些被释放的内容起死回生。
4.上面给出了一个如何使用的示例。
源码分析：
1.创建
/**
* @param maxSize for caches that do not override {@link #sizeOf}, this is
* the maximum number of entries in the cache. For all other caches,
* this is the maximum sum of the sizes of the entries in this cache.
*/
public LruCache(int maxSize) {
this.maxSize = maxSize;
this.map = new LinkedHashMap<K, V>(0, 0.75f, true);
}设置最大缓存容量，初始化LinkedHashMap，双向链表保存数据,特别注意最后一个参数是true，表示如果链表节点每次被访问则会重新排序，将访问的节点放入到链表尾部。
2.存储数据
public final V put(K key, V value) {
V previous;
synchronized (this) {
putCount++;
//获取插入内容大小
size += safeSizeOf(key, value);
//将新内容放入链表中，同时返回旧内容
previous = map.put(key, value);
if (previous != null) {
//如果旧内容存在，则计算新内容和旧内容差值，重新设置给目前缓存内容大小
size -= safeSizeOf(key, previous);
}
}
//如果旧内容存在，则调用这个方法，我们可以在这个方法中做回收处理
if (previous != null) {
entryRemoved(false, key, previous, value);
}
//重新比较目前缓存内容大小和设置最大值，确定是否需要释放缓存
trimToSize(maxSize);
return previous;
}计算存储内容大小，放入链表中，如果之前链表中有内容，则计算新内容和老内容大小差值，并且调用entryRemoved方法，我们可以在这个方法中释放旧内容。计算缓存内容是否超过设定最大值。trimToSize 方法我们看一下:
private void trimToSize(int maxSize) {
//只要目前缓存内容大小超过最大值，则不停的删除头节点
while (true) {
K key;
V value;
synchronized (this) {
//如果内容大小小于最大值，则退出循环
if (size <= maxSize) {
break;
}
//获取头节点
Map.Entry<K, V> toEvict = map.eldest();
if (toEvict == null) {
break;
}
// END LAYOUTLIB CHANGE
if (toEvict == null) {
break;
}
//删除头结点
key = toEvict.getKey();
value = toEvict.getValue();
map.remove(key);
size -= safeSizeOf(key, value);
evictionCount++;
}
entryRemoved(true, key, value, null);
}
}只要目前存储的内容大于设定的最大值，则将链表的头节点数据删除掉，直到小于设置的最大值。
3.获取数据：
public final V get(K key) {
V mapValue;
synchronized (this) {
//获取内容，同时将此节点放到到链表尾部
mapValue = map.get(key);
if (mapValue != null) {
hitCount++;
return mapValue;
}
}
}此方法会获取到节点内容，同时会将节点重新排序，放入到链表尾部。
我们可以看到，lrucache充分利用了linkhashmap源码只要节点被访问则会重新排序，将访问节点放到最后节点的特点。
Lrucache源码分析完了，但是貌似没有说过他的缺点是什么，好像都是优点，那么他的缺点是什么呢？lrucache有一个致命的缺点，那就是被他引用的对象都是强引用，强引用特点就是宁可jvm挂掉，也不释放对象，所以lrucache反而会增大内存消耗，特别是当内存紧张的时候，系统需要释放一些内存来保命时，但是对于lrucache他没有任何办法？那怎么解决呢？我们把他持有的对象换成软引用不就可以了吗？用法如下：
LruCache<String, SoftReference<String>> lruCache=new LruCache<String, SoftReference<String>>(1000){
@Override
protected int sizeOf(String key, SoftReference<String> value) {
if(value.get()!=null){
return value.get().length();
}
return 0;
}
}好像是完美解决了，当内存不足时，被软引用持有的对象就会被回收了。但是，但是，仔细想想，lrucache是用来干什么的？保存最近最多使用对象的，如果你内存不足了，就把我对象给回收掉了，那我的意义在哪呢？本来我A对象刚使用了，结果你给我回收了，是不是跟我的设计初衷不符合了呢？而且还面临着，被回收了之后我就需要重新计算目前占用内存大小问题。所以说，这个方案不可取。那怎么完美解决呢？参考glide源码解决，glide是将三级缓存扩充到了四级，第一级lrucache，第二级弱引用+引用计数法，第三级本地缓存，第四级才是联网。当我们获取图片时，会先从lrucache中获取，如果有，则将图片从lrucache中remove掉，同时添加到弱引用中，同时弱引用中有个计算器，引用数量+1，下次再去lrucache取时，肯定就没有了，会去弱引用中找，引用数量再+1，当不用的时候，引用数量-1，直到为0，则重新将弱引用对象放入到lrucache中。也就是说，lrucache只持有最近使用的，当前正在使用的则用弱引用持有，那么如果内存紧张了，则可以直接将lrucache清空释放掉内存，这就完美解决了这个致命问题。同时，也说明glide实际使用的最大内存比lrucache申请的内存要大，因为正在使用的图片内存没计算在内。