LruCache使用解读

之前在网上有看到一篇文章《2017下半年，一二线互联网公司Android面试题汇总》，整理的知识点还挺全而且也有一些比较深入的点，最初看的时候有些知识点要么答不上来，要么理解的不够深刻，后面也是查阅了很多相关资料才弄明白。正所谓“好记性不如烂笔头”，为了加深自己的理解以及方便以后查阅，所以打算写一些文章记录下来，于是就有了第一个知识点LruCache。这里我们将通过3W（What，Why和How）的方式来说明LruCache。

什么是LruCache?

LruCache是Android在API12上引入的一种缓存机制，这种缓存有个特点，就是当缓存容量达到上限时，会将最近最少使用的对象从cache中清除出去。

那么这种缓存方式跟普通的缓存有什么区别呢？为什我需要使用它？

曾经，在各大缓存图片的框架没流行的时候。有一种很常用的内存缓存技术：SoftReference 和 WeakReference（软引用和弱引用），但是走到了 Android 2.3（Level 9）时代，垃圾回收机制更倾向于回收 SoftReference 或 WeakReference 的对象。后来，又来到了Android3.0，图片缓存在native中，因为不知道要在是什么时候释放内存，没有策略，没用一种可以预见的场合去将其释放，这就造成了内存溢出。
所以LruCache的出现就是为了解决上述问题，它使用强引用来缓存，消除了垃圾回收机制的影响，同时通过设定缓存上限以及著名的LRU算法来管理内存，使得内存的管理变得更加高效和灵活。

如何使用LruCache?

LruCache是通过LinkedHashMap来实现LRU内存管理的，所以我们可以将其当作一个map来使用，如put,get,remove等。但是要注意，LruCache是不允许key和value为空的。

接下来是针对LruCache这个知识点的一些延伸

Lru是什么？

LRU是操作系统内存管理中比较经典的一种缓存淘汰算法，相信学过操作系统的童鞋应该都有耳闻。操作系统里面还存在一些其他的缓存淘汰算法，如LIFO,FIFO,LFU等，它们都是从某一个维度来评估缓存中条目的重要性，从而当缓存不足时淘汰掉其中最不重要的条目。可见当我们在做App开发时，操作系统里面很多的技术思想其实也可以拿来做参考。

LinkedHashMap为什么能实现LruCache中的Lru？

LinkedHashMap跟HashMap一个重要区别就是其内部的entry是有序的，它有两种排序规则：插入排序和访问排序，其实也就是按put调用时间排序还是按get调用时间来排序。LinkedHashMap通过设置访问排序来是实现Lru的。

LruCache在多线程访问时是否需要加同步锁？

LruCache内部使用了synchronized来保证其线程安全。所以当我们在访问lrucache时并不需要加锁，但是在一个线程中如果出现多次读写，则需要对cache额外加锁。比如

synchronized (cache) {
     if (cache.get(key) == null) {
         cache.put(key, value);
     }
}

上面讲到lrucache中使用了synchronized来同步，那么在app开发中有哪些比较常见的同步方式呢？

1. 第一个是synchronized，因为使用起来非常简单所以排在了第一个，并且在jdk1.6以后其性能得到了极大优化使得其使用更加广泛。
2. 第二个是reentrantlock，在jdk1.5之前其相对synchronized具有性能优势，并且由于这种锁的灵活性，比如超时锁，中断锁等，使得其在某些场合下使用更具优势。
3. 第三个是AtomicXXX，准确来说这不算是一种锁，但是由于其操作的原子性，我们经常会在一些场合，比如计数AtomicInteger，标记AtomicBoolean等用到。可能有人会说volatile也可以做到，但是像读后写，自增等操作却是volatile无法做到的，所以对于原始数据的多线程访问，建议优先使用AtomicXXX。