LinkedHashMap与HashMap性能对比

P粉602998670

发布时间：2025-09-21 22:53:01

690人浏览过

来源于php中文网

原创

答案是：若需保持插入或访问顺序，应选 LinkedHashMap，否则选 HashMap。前者因维护双向链表而内存开销略高且基础操作稍慢，但迭代有序；后者无序但性能更快、内存更省。当需要有序遍历时，HashMap 需额外排序，整体效率更低，反而“更慢”。LinkedHashMap 还适用于实现 LRU 缓存，通过 accessOrder 和 removeEldestEntry 实现高效淘汰机制。

linkedhashmap与hashmap性能对比

在选择

LinkedHashMap

还是

HashMap

时，核心考量在于你是否需要保持元素的插入顺序（或访问顺序）。

HashMap

在大多数操作（如插入、查找、删除）上通常提供稍快的平均时间复杂度，因为它没有维护额外的数据结构来保证顺序。而

LinkedHashMap

由于需要维护一个双向链表来记录元素的逻辑顺序，会引入轻微的性能开销和更高的内存占用，但它为你提供了可预测的迭代顺序，这在很多场景下是不可或缺的。

HashMap

基本上是 Java 中最常用的键值对存储结构之一，它的设计哲学就是“快”。它利用哈希表原理，通过键的

hashCode()

方法快速定位到存储位置。这意味着，理论上，无论你的

HashMap

里有多少元素，

put

、

get

、

remove

操作的平均时间复杂度都能达到 O(1)。这听起来很美好，而且在实际应用中，只要哈希冲突处理得当，性能确实非常出色。但它有个“脾气”，就是当你遍历它的时候，元素的顺序是完全不可预测的，甚至在不同的 Java 版本或 JVM 启动时都可能不一样，因为它依赖于哈希桶的内部结构。

LinkedHashMap

呢，它继承自

HashMap

，但在此基础上，它又“悄悄地”在每个

Entry

（也就是键值对）里加了两个指针，分别指向前一个和后一个

Entry

。这样，所有的

Entry

就构成了一个双向链表。这个链表的作用就是维护元素的插入顺序。当你遍历

LinkedHashMap

时，它会按照这个链表的顺序来返回元素，非常规整。当然，它也可以配置成按照访问顺序来排序，这在实现 LRU 缓存时特别有用。

所以，性能对比就变得很清晰了：

基础操作（
put
,
get
,
remove
）:
```
HashMap
```
通常会比
```
LinkedHashMap
```
略快一点点。这个“一点点”体现在常数因子上，因为
```
LinkedHashMap
```
在进行这些操作时，除了
```
HashMap
```
内部的哈希表操作，还需要同步更新那个双向链表。对于单次操作来说，这点差异可能微乎其微，但在高并发、大数据量的场景下，累积起来就可能显现。
内存占用:
```
LinkedHashMap
```
会比
```
HashMap
```
占用更多的内存。每个
```
Entry
```
多了两个引用，这在存储大量对象时，内存开销会显著增加。
迭代操作: 如果你需要按插入顺序（或访问顺序）遍历 Map，那么
```
LinkedHashMap
```
的迭代效率会更高，因为它直接沿着链表走就行了。而
```
HashMap
```
的迭代顺序是混乱的，如果你需要特定顺序，就得先导出到 List 再排序，这会带来额外的开销。

内存占用与迭代效率哪个更关键？

这个问题没有绝对的答案，完全取决于你的具体应用场景和性能瓶颈在哪里。

从内存占用来看，

LinkedHashMap

的确会更高。每个

Entry

对象在

LinkedHashMap

中会比

HashMap

多出两个

Node

类型的引用（

before

和

after

），这在 64 位 JVM 上，每个引用大约是 8 字节。所以，一个

Entry

会多占用 16 字节左右。对于存储几百、几千个元素的 Map 来说，这几乎可以忽略不计。但在处理数百万甚至上亿的键值对时，这额外的 16 字节乘以巨大的数量，累积起来的内存消耗就非常可观了，可能会导致 OOM（Out Of Memory）或者增加 GC（Garbage Collection）的压力，从而影响应用的整体吞吐量和响应时间。在嵌入式系统或者内存受限的环境中，这一点就显得尤为关键。

而迭代效率，这其实是个有点微妙的话题。如果只是单纯地遍历所有元素，

HashMap

和

LinkedHashMap

在遍历的“速度”上，如果哈希分布良好，理论上

HashMap

并不一定就慢。

HashMap

遍历的是它的桶数组，然后是每个桶里的链表或红黑树。

LinkedHashMap

遍历的是它的双向链表。真正的差异在于迭代的顺序。

如果你需要以元素的插入顺序或访问顺序来处理数据，那么

LinkedHashMap

的迭代效率是压倒性的。因为你直接就能得到有序的元素。如果使用

HashMap

，你不得不先将

entrySet()

或

values()

转换成

List

，然后进行一次排序操作（比如

Collections.sort()

），这个排序操作的时间复杂度至少是 O(N log N)，远高于

LinkedHashMap

的 O(N) 迭代。这种情况下，

HashMap

的“慢”就体现在你需要额外付出的排序成本上。

我个人的经验是，除非你明确知道内存是一个极其严格的约束，或者你正在构建一个对每个字节都斤斤计较的底层库，否则在大多数业务应用中，如果需要保持顺序，

LinkedHashMap

带来的便利性和代码清晰度往往比那一点点额外的内存开销更值得。毕竟，程序员的时间也是成本。

LinkedHashMap

的 LRU 实现原理与适用场景

LinkedHashMap

提供了一个非常优雅且高效的方式来构建 LRU（Least Recently Used，最近最少使用）缓存。它的核心在于一个构造函数参数：

accessOrder

。

聚彩手机网店系统免费版

聚彩手机商城系统，是一款专业于手机销售的独立手机网店系统，他拥有众多的手机参数选项，以及傻瓜式的设置选项，让您可以在５分钟内建立起专业而强大的手机销售网站。他拥有多套模版可以实时切换，前台拥有新闻中心、手机中心、配件中心、软件下载、手机报价、发货查询、保修查询、分店查询、产品的对比功能，代理与加盟的申请等功能，他拥有完善的会员中心，会员等级设置等，集成在线支付接口，超强ＳＥＯ，可以设置所有页面的t

下载

当

LinkedHashMap

的

accessOrder

参数设置为

true

时，它的内部双向链表就不再是简单的“插入顺序”了。每当你通过

get()

方法访问一个键值对，或者通过

put()

方法更新一个键值对时，这个被访问或更新的

Entry

就会被移动到链表的末尾。这样，链表的头部始终是“最不经常使用”的元素，而尾部则是“最近使用”的元素。

要实现一个固定大小的 LRU 缓存，你只需要继承

LinkedHashMap

并重写

removeEldestEntry(Map.Entry eldest)

方法。这个方法会在每次

put()

新元素之后被调用，它接收链表头部的

eldest

元素作为参数。你在这个方法里判断当前 Map 的大小是否超过了你设定的缓存容量，如果超过了，就返回

true

，

LinkedHashMap

就会自动移除这个

eldest

元素。

一个简单的 LRU 缓存实现示例（概念性）：

public class LRUCache extends LinkedHashMap {
    private final int capacity;

    public LRUCache(int capacity) {
        // initialCapacity, loadFactor, accessOrder = true
        super(capacity, 0.75f, true); 
        this.capacity = capacity;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry eldest) {
        // 当Map大小超过容量时，移除最老的Entry
        return size() > capacity; 
    }

    // 可以在这里添加一些其他缓存特有的方法，例如 getOrDefault 等
}

适用场景：

数据库查询缓存： 缓存最近查询过的数据库结果，避免频繁访问数据库。
Web 页面片段缓存： 缓存用户最近访问的页面或组件，提高响应速度。
对象池： 管理一组可复用的对象，当对象池满时，回收最久未使用的对象。
文件句柄或连接池： 保持一定数量的活跃连接，当连接数达到上限时，关闭最久未使用的连接。
DNS 缓存： 缓存最近解析的域名到 IP 地址的映射。

我曾在一个高并发的后端服务中，用

LinkedHashMap

实现了一个轻量级的本地缓存，用来存储一些不经常变化但访问频率极高的配置数据。它避免了每次请求都去数据库查询，显著降低了数据库压力，同时由于其 LRU 特性，内存占用也得到了有效控制。这种内置的机制，比自己从头写一个 LRU 逻辑要简洁和可靠得多。

什么时候

HashMap

会比

LinkedHashMap

更“慢”？

这是一个很好的反向思考问题，因为我们通常认为

HashMap

更快。但“慢”是一个相对概念，它可能不是指单次操作的绝对速度，而是指在特定场景下，为了达到某种目的，使用

HashMap

会导致整体效率下降，或者需要付出额外代价。

需要有序迭代时，
```
HashMap
```
会“慢”： 这是最直接的情况。如果你的业务逻辑要求你以特定的顺序（比如插入顺序）遍历 Map 中的元素，而你却使用了
```
HashMap
```
，那么你不得不先将
```
HashMap
```
的
```
entrySet()
```
或
```
values()
```
转换为
```
List
```
，然后对其进行排序。这个排序操作的时间复杂度是 O(N log N)，相比
```
LinkedHashMap
```
直接的 O(N) 迭代，显然是“慢”了很多。这里的“慢”不是
```
HashMap
```
本身慢，而是为了弥补
```
HashMap
```
缺乏顺序的特性，你不得不引入额外且耗时的操作。
当
```
HashMap
```
内部结构变得低效时（极少见但可能）： 虽然
```
HashMap
```
的平均时间复杂度是 O(1)，但在最坏情况下，如果哈希函数设计得非常糟糕，或者遇到“哈希碰撞攻击”，导致所有元素都落入同一个桶，那么
```
HashMap
```
就会退化成一个链表（在 Java 8 之后会退化成红黑树），此时操作的时间复杂度会变成 O(N)。虽然
```
LinkedHashMap
```
也基于
```
HashMap
```
，但其额外的链表结构在遍历时，可以保证只遍历实际存在的元素，而
```
HashMap
```
在遍历时可能需要跳过大量的空桶。如果
```
HashMap
```
的底层数组非常稀疏（比如你设置了非常大的初始容量，但只放了很少的元素），那么遍历
```
HashMap
```
的所有桶（包括空桶）可能会比遍历
```
LinkedHashMap
```
的链表要慢。当然，这是一种比较极端的情况，在正常使用下不太可能发生。
频繁 rehashing 导致性能抖动：
```
HashMap
```
和
```
LinkedHashMap
```
都会在达到负载因子阈值时进行 rehashing，也就是扩容并重新计算所有元素的哈希值并放入新的数组。这个操作的成本是 O(N)。如果
```
HashMap
```
的容量规划不合理，导致频繁 rehashing，那么在这些时刻，
```
HashMap
```
会出现明显的性能抖动。虽然
```
LinkedHashMap
```
也会有 rehashing 的开销，但如果你的应用场景对顺序有强需求，且
```
LinkedHashMap
```
避免了额外的排序开销，那么从整体应用性能来看，
```
LinkedHashMap
```
可能会带来更平稳的性能曲线，避免了因排序而导致的周期性高峰。