上一篇文章说说Android LRU缓存算法实现学习笔记(一) 中我们介绍了最常用的实现LRU缓存的数据结构LinkedHashMap，这一节我们会针对LinkedHashMap的数据结构的特性，来自己实现缓存结构和学习Android源码和项目中对缓存的完善。
上一篇说到对于缓存实现，我们很重要的会考虑以下几点：1.访问速度；2.逐出旧的缓存策略；3.最好还能考虑到一定的并发度。LinkedHashMap对哈希表的实现保证了我们缓存的快速访问速度，我们通过源码知道，LinkedHashMap默认缓存无限大，所有的节点永远不过期。实际在手机开发中，内存可是寸土寸金，有时候甚至锱铢必较。因此，我们在Android应用中必须重写逐出旧的缓存策略。我自己的简单实现缓存逐出策略如下：
public class LruCache<K,V> extends LinkedHashMap<K, V> {
private static final long serialVersionUID = 1L;
/** 最大数据存储容量 */
private static final int LRU_MAX_CAPACITY = 1024;
/** 存储数据容量 */
private int capacity;
/**
* 默认构造方法
*/
public LruCache() {
super();
}
/*
* 默认缓存最大值为LRU_MAX_CAPACITY
*/
public LruCache(int initialCapacity, float loadFactor, boolean isLRU) {
super(initialCapacity, loadFactor, isLRU);
capacity = LRU_MAX_CAPACITY;
}
public LruCache(int initialCapacity, float loadFactor, boolean isLRU, int lruCapacity) {
super(initialCapacity, loadFactor, isLRU);
this.capacity = lruCapacity;
}
/**
* 重写removeEldestEntry方法，实现重写默认的缓存逐出策略（默认LinkedHashMap下结点永不过期）
*/
@Override
protected boolean removeEldestEntry(Map.Entry<K,V> eldest) {
if(size() > capacity) {
return true;
}
return false;
}
}以上的代码我们还可以有另外一种写法，我们不是通过继承来重写LinkedHashMap，可以通过委托（个人觉得聚合关系比较准确）来实现，同时我们需要自己实现对Map访问的线程安全。
public class LruCache<K,V> {
/** 最大数据存储容量 */
private static final int LRU_MAX_CAPACITY = 1024;
LinkedHashMap<K, V> map;
/** 存储数据容量 */
private int capacity;
/**
* 默认构造方法
*/
public LruCache() {
super();
}
/*
* 默认缓存最大值为LRU_MAX_CAPACITY
*/
public LruCache(int initialCapacity, float loadFactor, boolean isLRU) {
capacity = LRU_MAX_CAPACITY;
map = new LinkedHashMap<K,V>(initialCapacity, loadFactor, isLRU){
@Override
protected boolean removeEldestEntry(Map.Entry eldest) {
if(size() > capacity) {
return true;
}
return false;
}
};
}
public LruCache(int initialCapacity, float loadFactor, boolean isLRU, int lruCapacity) {
this.capacity = lruCapacity;
map = new LinkedHashMap<K,V>(initialCapacity, loadFactor, isLRU){
@Override
protected boolean removeEldestEntry(Map.Entry eldest) {
if(size() > capacity) {
return true;
}
return false;
}
};
}
public synchronized void put(K key, V value) {
map.put(key, value);
}
public synchronized V get(K key) {
return map.get(key);
}
public synchronized void remove(K key) {
map.remove(key);
}
public synchronized Set<Map.Entry<K, V>> getAll() {
return map.entrySet();
}
public synchronized int size() {
return map.size();
}
public synchronized void clear() {
map.clear();
}
}以上对LinkedHashMap的缓存结构的线程安全的实现，我们会想，我们能不能提高我们缓存的并发度呢？根据我们已有经验，我们会想到读写锁来实现对读写锁定级别的不同约束来达到多线程下同时多读，独占写来提高缓存并发度。我们可以写如下代码：
public class LruCache<K,V> {
/** 最大数据存储容量 */
private static final int LRU_MAX_CAPACITY = 1024;
LinkedHashMap<K, V> map;
private final ReadWriteLock rwlock = new ReentrantReadWriteLock();
private final Lock readLock = rwlock.readLock();
private final Lock writeLock = rwlock.writeLock();
/** 存储数据容量 */
private int capacity;
/**
* 默认构造方法
*/
public LruCache() {
super();
}
/*
* 默认缓存最大值为LRU_MAX_CAPACITY
*/
public LruCache(int initialCapacity, float loadFactor, boolean isLRU) {
capacity = LRU_MAX_CAPACITY;
map = new LinkedHashMap<K,V>(initialCapacity, loadFactor, isLRU){
@Override
protected boolean removeEldestEntry(Map.Entry eldest) {
if(size() > capacity) {
return true;
}
return false;
}
};
}
public LruCache(int initialCapacity, float loadFactor, boolean isLRU, int lruCapacity) {
this.capacity = lruCapacity;
map = new LinkedHashMap<K,V>(initialCapacity, loadFactor, isLRU){
@Override
protected boolean removeEldestEntry(Map.Entry eldest) {
if(size() > capacity) {
return true;
}
return false;
}
};
}
public void put(K key, V value) {
try{
writeLock.lock();
map.put(key, value);
}
finally{
writeLock.unlock();
}
}
public synchronized V get(K key) {
try{
readLock.lock();
return map.get(key);
}
finally{
readLock.unlock();
}
}
public void remove(K key) {
try{
readLock.lock();
map.remove(key);
}
finally{
readLock.unlock();
}
}
public Set<Map.Entry<K, V>> getAll() {
try{
readLock.lock();
return map.entrySet();
}
finally{
readLock.unlock();
}
}
public int size() {
try{
readLock.lock();
return map.size();
}
finally{
readLock.unlock();
}
}
public void clear() {
try{
readLock.lock();
map.clear();
}
finally{
readLock.unlock();
}
}
}public V get(Object key) {
Entry<K,V> e = (Entry<K,V>)getEntry(key);
if (e == null)
return null;
e.recordAccess(this); //If the enclosing Map is access-ordered, it moves the entry
to the end of the list; otherwise, it does nothing.
return e.value;
}void recordAccess(HashMap<K,V> m) {
LinkedHashMap<K,V> lm = (LinkedHashMap<K,V>)m;
if (lm.accessOrder) {
lm.modCount++;
remove();
addBefore(lm.header);
}
}读写锁不能提高对Map的并发度，我们会想到在JDK1.5的java.util.concurrent包下的ConcurrentHashMap 对并发的巧妙设计（不熟悉的可以看看我的另一篇文章 Java多线程学习笔记—从Map开始说说同步和并发），我们能不能借鉴ConcurrentHashMap对并发的设计来提高我们Map的并发度。我们知道我们的LinkedHashMap实际上实现的时候继承的HashMap,同时我们也给HashMap的节点增加了两个字段before和after节点。
private static class Entry<K,V> extends HashMap.Entry<K,V> {
// These fields comprise the doubly linked list used for iteration.
Entry<K,V> before, after;我们回到Google的对Android缓存的设计，我们首先来看Google推荐的内存缓存LruCache的设计。同样，我们对缓存这几个方面考虑：1.访问速度；2.逐出旧的缓存策略；3.最好还能考虑到一定的并发度。访问速度主要由数据结构决定，LruCache通过委托LinkedHashMap能保证对结点的访问速度。下面我们来看LruCache逐出旧的缓存策略和并发度，我们看LruCache的源码知道，LruCache对LinkedHashMap的get和put方法并不是简单的调用实现，自己重新实现了put和get方法实习。我们先看put的实习如下：
public final V put(K key, V value) {
if (key == null || value == null) {
throw new NullPointerException("key == null || value == null");
}
V previous;
synchronized (this) {
putCount++;
size += safeSizeOf(key, value);
previous = map.put(key, value);
if (previous != null) {
size -= safeSizeOf(key, previous); //默认LinkedHashMap的Entry大小不是所占字节大小，默认计数表示大小。如果我们需要精确限定内存大小来逐出旧的eldest节点，我们需要重写safeSizeOf的方法中的SizeOf方法
}
}
if (previous != null) {
entryRemoved(false, key, previous, value); //节点被移除时候的操作，默认什么操作都不做 ，我们可以在子类重写该方法，比如Android2.3.3(API 10)及之前的版本中，Bitmap对象与其像素数据是分开存储,Bitmap对象存储在heap中，而Bitmap对象的像素数据则存储在Native Memory（本地内存）因此，当Bitmap从缓存逐出的时候，我们还需要手动释放掉Bitamp。这个时候，我们重写entryRemoved方法作用就显现出来啦
}
trimToSize(maxSize); //调用该方法通过判断缓存时候达到最大值，尝试去逐出缓存
return previous;
}public void trimToSize(int maxSize) {
while (true) {
K key;
V value;
synchronized (this) {
if (size < 0 || (map.isEmpty() && size != 0)) {
throw new IllegalStateException(getClass().getName()
+ ".sizeOf() is reporting inconsistent results!");
}
if (size <= maxSize || map.isEmpty()) { //当我们的缓存大小小于maxSize时候，我们不执行逐出缓存
break;
}
Map.Entry<K, V> toEvict = map.entrySet().iterator().next(); //我们逐出缓存的策略当我们的缓存大小超过maxSize的时候，我们通过迭代器开始从最旧开始迭代，从map删除节点
key = toEvict.getKey();
value = toEvict.getValue();
map.remove(key);
size -= safeSizeOf(key, value);
evictionCount++;
}
entryRemoved(true, key, value, null);
}
}public final V get(K key) {
if (key == null) {
throw new NullPointerException("key == null");
}
V mapValue;
synchronized (this) {
mapValue = map.get(key);
if (mapValue != null) {
hitCount++;
return mapValue;
}
missCount++;
}
/*
* Attempt to create a value. This may take a long time, and the map
* may be different when create() returns. If a conflicting value was
* added to the map while create() was working, we leave that value in
* the map and release the created value.
*/
V createdValue = create(key); //create方法默认返回null，所以当get没有获得value值的时候默认返回null
if (createdValue == null) {
return null;
}
synchronized (this) {
createCount++;
mapValue = map.put(key, createdValue);
if (mapValue != null) {
// There was a conflict so undo that last put
map.put(key, mapValue);
} else {
size += safeSizeOf(key, createdValue);
}
}
if (mapValue != null) {
entryRemoved(false, key, createdValue, mapValue);
return mapValue;
} else {
trimToSize(maxSize);
return createdValue;
}
}在我们的实际开发中，我们常结合LruCache和Set<SoftReference<Bitmap>>来实现缓存。我们知道从Android2.3开始，用 SoftReference 或者 WeakReference做图片缓存的方法已经不被推荐了。因为DVM 的GC对SoftReference和WeakReference的回收更加频繁，因此我们在使用缓存的时候不能再依赖SoftReference的集合来实现缓存，但是SoftReference仍然可以作为辅助缓存。下面我们以在GitHub上的一个开源实现Android-BitmapCache来学习LruCache强引用和Set<SoftReference<Bitmap>>实现内存缓存。
final class BitmapMemoryLruCache extends LruCache<String, CacheableBitmapDrawable> {
private final Set<SoftReference<CacheableBitmapDrawable>> mRemovedEntries; //此处SoftReference的set集合保存对LruCache的节点Entry执行entryRemoved操作的节点
private final BitmapLruCache.RecyclePolicy mRecyclePolicy;//该处判断当前Bitmap时候执行手动回收策略
BitmapMemoryLruCache(int maxSize, BitmapLruCache.RecyclePolicy policy) {
super(maxSize);
mRecyclePolicy = policy;
mRemovedEntries = policy.canInBitmap()
? Collections.synchronizedSet(new HashSet<SoftReference<CacheableBitmapDrawable>>())
: null;
}
CacheableBitmapDrawable put(CacheableBitmapDrawable value) {
if (null != value) {
value.setCached(true);
return put(value.getUrl(), value);
}
return null;
}
BitmapLruCache.RecyclePolicy getRecyclePolicy() {
return mRecyclePolicy;
}
@Override
protected int sizeOf(String key, CacheableBitmapDrawable value) { //重写该方法，我们获取Bitmap的精确大小，我们的逐出策略会对大小更敏感，默认逐出策略是根据节点数目的大小来逐出
return value.getMemorySize();
}
@Override
protected void entryRemoved(boolean evicted, String key, CacheableBitmapDrawable oldValue,//当节点被逐出的时候，放进我们软引用的集合里
CacheableBitmapDrawable newValue) {
// Notify the wrapper that it's no longer being cached
oldValue.setCached(false);
if (mRemovedEntries != null && oldValue.isBitmapValid() && oldValue.isBitmapMutable()) {
synchronized (mRemovedEntries) {
mRemovedEntries.add(new SoftReference<CacheableBitmapDrawable>(oldValue));
}
}
}
Bitmap getBitmapFromRemoved(final int width, final int height) { //获取被LruCache逐出的软引用集合的节点Value
if (mRemovedEntries == null) {
return null;
}
Bitmap result = null;
synchronized (mRemovedEntries) {
final Iterator<SoftReference<CacheableBitmapDrawable>> it = mRemovedEntries.iterator();
while (it.hasNext()) {
CacheableBitmapDrawable value = it.next().get();
if (value != null && value.isBitmapValid() && value.isBitmapMutable()) {
if (value.getIntrinsicWidth() == width
&& value.getIntrinsicHeight() == height) {
it.remove();
result = value.getBitmap();
break;
}
} else {
it.remove();
}
}
}
return result;
}
void trimMemory() {
final Set<Entry<String, CacheableBitmapDrawable>> values = snapshot().entrySet();
for (Entry<String, CacheableBitmapDrawable> entry : values) {
CacheableBitmapDrawable value = entry.getValue();
if (null == value || !value.isBeingDisplayed()) {
remove(entry.getKey());
}
}
}
}转载请注明出处：http://blog.csdn.net/johnnyz1234/article/details/43958147
1701
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
