LinkedHashMap removeEldestEntry：删除了多少元素？答案

【问题标题】：LinkedHashMap removeEldestEntry: How many elements are removed?LinkedHashMap removeEldestEntry：删除了多少元素？
【发布时间】：2012-07-26 12:19:10
【问题描述】：

LinkedHashMap 看起来很适合实现 LRU 缓存。它在链表管理方面有一些开销并且不是线程安全的，但是它简化了实现，我可以在我的代码中处理这些。

我的问题是，如果实现 removeEldestEntry 并且 put 发现列表已满，LinkedHashMap 会从列表中删除多少元素。

它是否只删除一个元素？或总大小的某个百分比。我担心的是，如果它只删除一个元素来放置新元素，那么它就是一个真正的性能问题。正如我所见，重新哈希操作的成本非常高。

请有人建议它是如何工作的，如果我可以使用 InitialCapacity、LoadFactor 或任何其他方式管理这些要删除的元素计数。

【问题讨论】：

标签： java linkedhashmap

【解决方案1】：

LinkedHashMap 可以很好地实现最简单的缓存，但对于更高级的需求，它可能并不理想。

从removeEldestEntry 返回true 将导致单个、最老的条目被删除，无法将其调整为多个元素。

可能类似于Guava CacheBuildermight be what you're looking for。

【讨论】：

【解决方案2】：

LinkedHashMap 在实现 LRU 缓存方面看起来很棒。它在链表管理方面有一些开销

所有 LRU 缓存都是如此。

不是线程安全的

你可以使用 Collections.synchronizedMap()

我的问题是，如果实现 removeEldestEntry 并且 put 发现列表已满，LinkedHashMap 会从列表中删除多少元素。

它删除最旧的条目。 IE。一个，只有一个。

来自 LinkedHashMap 的来源

    if (removeEldestEntry(eldest)) {
        removeEntryForKey(eldest.key);

我担心的是，如果它只删除一个元素来放置新元素，那么它就是一个真正的性能问题。

不是。

正如我所见，重新散列操作的成本非常高。

仅在容量增长时才发生重新散列，而不是在删除条目时发生。

【讨论】：

感谢 Jeff，Peter 的回复，然后我不使用 removeEldestEntry，而是保留缓存元素中元素的年龄，每当我的覆盖放置发现缓存已满时，它会删除大约 20%最古老的元素。另外，我不会让 get 方法从缓存中返回任何已经过期的元素。
为什么不删除任何过期的元素，以及删除你得到的任何过期的元素。如果删除 20%，则可以删除尚未过期的元素。
是的，我可以通过这种方式删除未过期的元素。就删除 1 个过期元素而言，我的 get 方法会执行此操作并将 null 返回给调用者。