LruCache使用解读

《LruCache使用解读》 image

之前在网上有看到一篇文章《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。
    原文作者:codeKeeper
    原文地址: https://www.jianshu.com/p/192d81fa229e
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞