Question

entryRemoved 被 LruCache 调用的场景：

• 1.（put） put 发生 key 冲突时被调用， evicted=false，key=此次 put 的 key，oldValue=被覆盖的冲突 value，newValue=此次 put 的 value 。
• 2.（trimToSize） trimToSize 的时候，只会被调用一次，就是最后一次被删除的最少访问数据带回来。 evicted=true，key=最后一次被删除的 key，oldValue=最后一次被删除的 value，newValue=null（此次没有冲突，只是 remove） 。
• 3.（remove） remove 的时候，存在对应 key，并且被成功删除后被调用。 evicted=false，key=此次 put 的 key，oldValue=此次删除的 value，newValue=null（此次没有冲突，只是 remove） 。
• 4.（get 后半段，查询丢失后处理情景，不过建议忽略） get 的时候，正常的话不实现自定义 create 的话，代码上看 get 方法只会走一半，如果你实现了自定义的 create(K key) 方法，并且在 你 create 后的值放入 LruCache 中发生 key 冲突时被调用， evicted=false，key=此次 get 的 key，oldValue=被你自定义 create(key) 后的 value，newValue=原本存在 map 里的 key-value 。

解释一下第四点：

1. 第四点是这样的，先 get(key)，然后没拿到，丢失。
2. 如果你提供了 自定义的 create(key) 方法，那么 LruCache 会根据你的逻辑自造一个 value，但是当放入的时候发现冲突了，但是已经放入了。
3. 此时，会将那个冲突的值再让回去覆盖，此时调用上述 4. 的 entryRemoved。

因为 HashMap 在数据量大情况下，拿数据可能造成丢失，导致前半段查不到，你自定义的 create(key) 放入的时候发现又查到了**（有冲突）**。然后又急忙把原来的值放回去，此时你就白白 create 一趟，无所作为，还要走一遍 entryRemoved。

综上就如同注释写的一样：

/**
 * 1.当被回收或者删掉时调用。该方法当 value 被回收释放存储空间时被 remove 调用
 * 或者替换条目值时 put 调用，默认实现什么都没做。
 * 2.该方法没用同步调用，如果其他线程访问缓存时，该方法也会执行。
 * 3.evicted=true：如果该条目被删除空间 （表示 进行了 trimToSize or remove）  evicted=false：put 冲突后 或 get 里成功 create 后
 * 导致
 * 4.newValue!=null，那么则被 put() 或 get() 调用。
 */
protected void entryRemoved(boolean evicted, K key, V oldValue, V newValue) {}

可以参考我的 demo 里的 entryRemoved 。