企业官网建设流程全解析

这一节的内容其实是整个容器系列里最让我纠结的一篇。上篇把 Set 和 List 两大接口的实现选项梳理完之后，我本以为把 Map 也按同样套路走一遍就行，直到自己整理 Map 家族的时候才发现，事情没想象中那么简单：Map 的实现虽然都长着相似的脸，底层数据结构的差距能达到“同一行业务代码在不同实现下跑出完全相同的结果，但内存布局和运行速度完全是两个世界”的夸张程度。

如果你是跟着这个系列一路看下来的读者，应该还记得上篇最后我们留了个尾巴：接口在 Java 容器框架里到底是什么角色，以及为什么拿着接口类型去操作容器，比拿着具体实现类去操作要舒服这么多。今天的下篇依然围绕“选择和权衡”这个核心，但主角换成 Map 接口及其实现家族。和上篇不一样，这次我不打算按“每个实现类各写一段”的方式来记流水账，因为如果只是把每个 Map 子类罗列一遍，你读完可能还是会回到默认的 HashMap 里不出来。我希望做的是：让你知道每个 Map 子类在解决什么问题，并且能够用一句话替自己把场景说清楚。

适合读这篇的人，我默认你已经具备两个基础：第一，接口和实现类的关系很清楚，至少知道 Map 是接口、HashMap 是实现类；第二，你写过至少一次用 Map 做数据聚合的代码，哪怕只是统计一个字符串里字符出现的次数。如果你的基础更薄弱一些，建议先把系列前几篇翻出来读一读，不然直接跳进这篇文章，部分概念会觉得干。接下来，我们就从“为什么同一个接口后面可以有这么多不同实现”开始聊。

1. 同一个接口，完全不同的算法容器

对刚上手 Java 的人来说，Map 的世界像一个大家族，每个成员都长着差不多的脸：put、get、containsKey、keySet、entrySet……这些方法签名在所有实现类里几乎一模一样。这是接口的功劳，也是容易被忽略的地方——正因为接口对大家的行为做了统一约束，很多初学者会误以为不同实现之间只是“版本差异”，随便换一个都会得到相同的结果。

这种理解在业务功能层面大体没错，在工程层面却大错特错。Map 接口负责的是语义约定：以键值对形式存储、键唯一、值可以重复、提供基于键的高效查找。至于键怎么存放、查找走什么路径、遍历按什么顺序，接口完全不干涉，交给各实现自己决定。于是出现了存储结构上的大分叉：

看到这张表，你就能意识到关键点：同样是键值对，底层是哈希表还是一棵红黑树，决定了插入、查询、遍历在各种情况下的表现。拿 get 操作举例，HashMap 在均匀分布的哈希情况下接近 O(1)，TreeMap 则稳定在 O(log n)。数据量小的时候根本看不出区别，但当你往里塞了几十万条记录，再叠加一个嵌套循环的算法，这个差距就会被加速放大。

我建议所有认真写 Java 的开发者都刻意做一次练习：把一个方法参数从 HashMap 改成 Map，让自己不再关心传入的到底是哪一个实现，只在真正需要某类行为时，去构造对应的实现实例。这个过程培养的是“接口约束行为，实现决定策略”的思维习惯，这比背下每个实现类的细节更值钱。

1.1 接口为什么值得优先写在左边

Java 里经常看到这样的代码：

HashMap<String, Integer> map = new HashMap<>();

乍看没问题，但很多团队代码规范里会要求写成：

Map<String, Integer> map = new HashMap<>();

后者在编码层面的优势有两层。第一层，它把“我用的是一个 Map”和“我用的是哪一个 Map”分开了。如果后续你发现需要保持插入顺序，把 new HashMap<>() 换成 new LinkedHashMap<>()，左边声明完全不用改，调用方的所有代码零感知。第二层，它防止调用方依赖 HashMap 特有的、不属于 Map 接口契约的能力。比如某些代码里直接调用了 HashMap 的一些非接口方法，后续换成别的实现，编译期就会报错。这其实是好事，它逼着你清理不合理的依赖。

我见过不少实际项目里，明明只有一个“按字符串顺序输出报表”的需求，代码里却直接用了 HashMap，然后自己取数据之后再做 Collections.sort 排序。不是不行，而是绕了远路。如果一开始就意识到“按插入顺序输出”这个诉求本质上属于 LinkedHashMap 的能力范围，整个处理链路会短很多。

1.2 不同实现背后的复杂度差异

从算法层面看，几个主要 Map 实现的理论复杂度分别是：

• HashMap 的 put、get 平均 O(1)，最坏 O(n)，但 Java 8 以后桶内元素超过阈值时会把链表转成红黑树，把最坏情况压到 O(log n)
• TreeMap 的 put、get、remove 都是 O(log n)，因为红黑树的自平衡特性保证树高始终保持在 log2(n) 量级
• LinkedHashMap 复合了 HashMap 的 O(1) 存取和双向链表的 O(1) 节点维护，理论上依然是 O(1)

这个理论复杂度的差异意味着什么？意味着选择一个实现，本质上是选择你愿意在“查找速度”和“顺序保证”之间做怎样的交易。想要查找最快，就得接受无序；想要有序遍历，就要承担有序结构的维护成本；想要插入顺序，就要在每次插入时额外维护一个指针链。天下没有免费的午餐，容器设计尤其如此。

还有一个经常被忽略的点：不同实现在空间占用上差异很大。HashMap 每个键值对除了存数据本身，还要维护 Node 对象、next 指针、hash 值等额外信息；TreeMap 每个节点还要维护左孩子、右孩子、父节点引用和红黑颜色标记，单节点内存开销明显高于哈希结构；EnumMap 则几乎没有任何额外元数据，直接就是数组。在“内存敏感、数据量大”的场景，这个差异会影响你到底能不能把数据装进 JVM。

2. HashMap 能满足大多数需求，但也有必须换掉的理由

HashMap 是 Map 家族里群众基础最广的一个，随便打开一段业务代码，几十个 Map 里可能有三十个是 HashMap。它是绝大多数场景的默认选择，这是合理的，因为哈希表确实是目前综合查询性能最好的通用键值数据结构。但默认选择不等于唯一选择，搞清楚 HashMap 的内部逻辑，你才能真正理解什么时候它不够用。

2.1 背后那只哈希函数

HashMap 的存储原理一句话解释：计算 key 的 hashCode，打散后映射到桶数组的下标，然后把键值对存进这个桶里；如果两个 key 落到了同一个桶，就是一次哈希碰撞，桶内用链表或红黑树容纳冲突元素。

这里有个工程细节值得展开。Java 8 之前，HashMap 的桶内元素只用链表存储；Java 8 开始，当一个桶内元素数量达到 TREEIFY_THRESHOLD=8 时，链表会转成红黑树；当元素数量缩小到 UNTREEIFY_THRESHOLD=6 时，红黑树会退回链表。注意 8 和 6 之间刻意留出两个数字的缓冲，是为了避免桶内元素在阈值附近反复转换造成性能抖动。这个数字不是拍脑袋定的，而是大量统计数据和工程经验沉淀的结果。

还有一个常被忽略的角色是扰动函数。key 的 hashCode 哪怕分布得不够好，HashMap 也会对它做一次位运算扰动，尽量让高位的信息也能参与低位索引计算，从而减少碰撞。这一层处理平时完全无感，但它在统计意义上显著降低了极端 key 模式下的碰撞概率。比如有些对象的 hashCode 实现很差，所有实例的 hashCode 低位都一样，如果没有扰动函数，它们会全部挤到同一个桶里，HashMap 退化成链表；有了扰动操作，至少高位的随机差异会被带进来。

2.2 初始容量与负载因子是最需要手调的两个参数

如果你从不手动调整初始容量和负载因子，HashMap 也能正常工作，但性能上可能付出额外代价。初始容量默认 16，负载因子默认 0.75。当已存储元素数量达到容量乘负载因子时，HashMap 会扩容，把桶数组翻倍，然后重新计算所有元素的新位置。这个过程叫 rehash，是一次全量重排，代价不小。

实际项目里，如果预先知道数据规模，比如要往 Map 里塞 10000 条记录，直接设置合适的初始容量就能避免中间的一次或多次扩容。一个最常见的构造写法是：

Map<String, Record> map = new HashMap<>(expectedSize);

但注意，如果预期元素是 10000 个，初始容量不能只设为 10000，因为 0.75 的负载因子意味着容量 10000 只能容纳 7500 个元素就会触发扩容。更合理的做法是：

Map<String, Record> map = new HashMap<>(expectedSize * 4 / 3 + 1);

也就是把容量按负载因子反向放大一点，留出余量。这个系数不用算得太精细，给个 4/3 的放大再补一个 1，就已经能覆盖绝大多数场景。个人实测下来，这个细节在批处理场景收益最大：避免了多次 rehash 的全量重排，时间损耗可以从秒级优化到毫秒级。

如果把负载因子调小，比如 0.5，桶更多、碰撞更少、查找性能更优，代价是内存占用上去了。反过来调大，比如 1.0，碰撞变多，链表或红黑树变长，查找性能下降。这种调优只在内存紧张且读多写少的特殊场景里值得做，普通项目完全不建议动这个参数。

2.3 并发读写 HashMap 的危险信号

HashMap 本身是线程不安全的。单线程下它表现很好，但多线程场景里，两个线程同时触发 rehash，旧版本 HashMap 可能出现链表成环造成死循环。Java 8 之后修改了扩容逻辑，成环问题基本被消除，但数据丢失、覆盖、size 不准等问题依然存在。所以多线程共享同一个 HashMap 的做法，是低估了问题严重性。

正确姿势是：并发共享场景优先考虑 ConcurrentHashMap，而不是给 HashMap 外面套 synchronizedMap。这一点放到第 5 节专门展开。这里先厘清一个边界：局部变量不会共享，不需要并发措施；只有多线程共享同一个容器实例时才需要并发保护。很多并发 bug 的根源，就是把不需要共享的容器硬生生变成了共享的。

2.4 最应该换掉 HashMap 的信号：顺序

HashMap 有一个特性，几乎所有初学者第一次碰到都会困惑：遍历时输出的顺序和插入顺序不一致，而且多次遍历的顺序也不稳定。原因一句话：桶的位置由哈希决定，哈希与插入顺序无关。

如果业务上根本不在乎顺序，无序就是最小成本。但只要出现“先写先出”“按某种规则排序后输出”之类的需求，HashMap 就不再合适。常见错误是先在 HashMap 里装好数据，输出前再用别的容器做排序。这能解决问题，但相当于把业务语义和数据结构拆开了。更优雅的做法是直接选一个自带顺序语义的 Map 实现：需要插入顺序选 LinkedHashMap，需要排序顺序选 TreeMap。

3. 想让遍历顺序可控，就要学会用 LinkedHashMap 和 TreeMap

顺序这个词在 Map 语境下有两个方向：一个是插入顺序，一个是排序顺序。两者经常被混为一谈，但实现机制完全不同，适用场景也迥异。

3.1 LinkedHashMap：哈希结构之外的“时间轴”

LinkedHashMap 在 HashMap 的存储结构之外，额外维护了一条双向链表。每次插入一个新的键值对，就把这个节点挂在链表尾部；遍历时从链表头开始走，于是可以按插入顺序输出所有元素。这个设计很有意思：它没有改变 HashMap 的哈希存取逻辑，而是像给每个节点贴了一个“入场编号”，用一条独立的链表把所有人的先后顺序编排好。

这一特性带来最直接的应用是缓存淘汰。LinkedHashMap 支持按访问顺序维护链表的模式，只要构造时传入 accessOrder=true。每次 get 操作会把被访问的节点移到链表尾部，那么链表头部自然就是“最久未被访问”的节点。基于这个机制，覆盖 removeEldestEntry 方法，就能实现一个经典 LRU 缓存：

class LruCache<K, V> extends LinkedHashMap<K, V> { private final int maxSize; public LruCache(int maxSize, int initialCapacity) { super(initialCapacity, 0.75f, true); this.maxSize = maxSize; } @Override protected boolean removeEldestEntry(Map.Entry<K, V> eldest) { return size() > maxSize; } }

这段代码的关键点有两个：构造时第三个参数传 true，开启访问顺序模式；重写 removeEldestEntry，当 size 超过上限时允许淘汰最老节点。就这么简单，一个 LRU 缓存就完成了。

不过要提醒一点：把 accessOrder 开成 true 之后，所有 get 操作都会触发链表节点移动。如果缓存命中率极高，这部分移动操作会有可观的开销。另外，如果你遍历这个 LinkedHashMap 的 keySet 时同时进行 get 操作，会抛出 ConcurrentModificationException，因为遍历过程中节点的移动会改变 modCount。我之前在缓存模块里踩过这个坑，后面在实践部分会详细说。

3.2 TreeMap：让键自己报告顺序

TreeMap 基于红黑树实现，核心思想是：每个键插入时都根据比较器决定自己的位置。因此遍历 TreeMap 时输出的是按键排序的结果，而不是插入顺序。

红黑树是一种自平衡二叉搜索树，任何节点的左右子树高度差不会超过两倍，从而保证插入、查找、删除都能稳定在 O(log n)。它的平衡维护代价体现在插入和删除时需要做旋转和重新着色操作，这部分比哈希表要重。这就意味着：如果只是需要偶尔排序一次，不如用 HashMap 存完再排序；如果数据本身就要求持续以有序方式维护，或者高频执行范围查询，那么 TreeMap 的气质才匹配。

TreeMap 一个非常好用的能力是范围查询：subMap(fromKey, toKey)、headMap(toKey)、tailMap(fromKey)。这类操作在业务报表、排行榜、区间统计等场景非常顺手。比如按时间戳存储事件，然后取最近 10 分钟范围内的事件，用 TreeMap 会优雅很多：

TreeMap<Long, Event> eventMap = new TreeMap<>(); // ... 填充数据 NavigableMap<Long, Event> recent = eventMap.tailMap(System.currentTimeMillis() - 10 * 60 * 1000L);

这类“按时间范围切片”的操作如果是用 HashMap，你得先导出一份 key 列表，做排序，再做过滤，最后再逐个 get。TreeMap 一个方法就能完成，而且返回的还是一个视图，对视图遍历的成本很低。

3.3 自定义顺序的边界：Comparable 与 Comparator

想要使用 TreeMap，键必须可比。Java 提供了两种方式：让键类实现 Comparable 接口，或者给 TreeMap 传入一个 Comparator。大多数业务键可以从自然顺序直接获得支持，比如 String 的字典序、Integer 的数值序；但遇到自建对象，就必须自己定义比较规则。

这里有一个非常经典的坑：比较器的返回值不满足一致性。TreeMap 依赖比较器做元素去重，如果 compare 返回 0，就视为同一个键。所以如果你写了一个 Comparator 只比较了主属性，而没有处理主属性相同但其他属性不同的情况，那么这些不同实体会被 TreeMap 认为是同一个 key。数据丢失时排查往往要花很长时间。最简单的解决办法：比较器里先比主属性，主属性相同再比一个或多个能够唯一区分对象的字段，宁可多写几行比较逻辑，也不要让相等判定和业务含义不一致。

Java 8 之后可以用 Comparator.comparing 这类链式写法，让比较器代码清爽很多：

Comparator<Person> comp = Comparator.comparing(Person::getDept) .thenComparing(Person::getId);

这个写法可读性强，也能天然处理部分字段为空的问题。不过前提是你知道自己对象的取值边界，如果比较字段可能为 null，还是要显式用 Comparator.nullsFirst 或 nullsLast 做包装，否则 NPE 一样会出现。

4. 给特定场景准备的 Map 实现，用对了是利器

HashMap、LinkedHashMap、TreeMap 是日常最常用的三个 Map 实现。但 Java 标准库里还有几个专业选手：WeakHashMap、IdentityHashMap、EnumMap。它们不像前面的实现那样通用，但用对场合会非常舒服，用错场合则会让你头皮发麻。

4.1 WeakHashMap：键只听弱引用的话

WeakHashMap 与 HashMap 的唯一区别在于，它的 key 使用弱引用而不是强引用。当某个 key 对象不再被外部强引用时，垃圾回收器下一次回收时就会把这个 key 从 WeakHashMap 中移除，对应的 value 也会顺带被清理。

这个特性让 WeakHashMap 非常适合做内存敏感场景的缓存。你希望缓存的数据在内存充足时留在里面，内存紧张时可以被 GC 回收，而不是阻碍回收导致内存泄漏。典型应用是一些以类对象为 key 的辅助数据存储，不少框架在实现类元数据缓存时就用了这个思路。

但陷阱也非常隐蔽。如果你的 value 内部又持有对应 key 的强引用，那么 key 被回收后，value 却还反向引用着 key，导致 key 无法释放，整个回收机制形同虚设。这种“值持有键引用”的反模式在弱引用容器中特别容易造成内存泄漏。解决办法是让 value 不要强引用 key，或者在 key 不再需要时主动清掉 value。另外注意，WeakHashMap 不是线程安全容器，不要在并发环境下裸用。

4.2 IdentityHashMap：判断的是“是不是同一个东西”

IdentityHashMap 的特殊之处在于键比较方式：使用引用同一性（==）而不是对象相等性（equals）。也就是说，就算两个对象内容完全一样，只要它们是两个不同的实例，IdentityHashMap 就认为它们是两个不同的键。

什么时候需要这种语义？典型场景是序列化、反序列化、代理、对象图遍历相关的处理，你需要维护的是对象身份到元数据的关系，而不是业务等价到元数据的关系。例如一个深度遍历框架为了避免重复处理同一个对象，用 IdentityHashMap 记录“这个实例我处理过没有”，此时两个内容相同的对象是否重复，取决于它们是不是同一个实例，而不是内容是否相等。

坑点是很多人不太适应这种语义。如果你往 IdentityHashMap 里放两个内容相同的 String 对象，会发现它们占了两个 entry。这不是 bug，是语义如此，使用之前一定要先确认自己的判断依据到底是 equals 还是 ==。

4.3 EnumMap：跟枚举键天生一对

当 Map 键类型是枚举时，EnumMap 是效率碾压级的选择。它内部用数组存储，数组下标直接用枚举的 ordinal 值，put 和 get 都直接落到数组下标操作，几乎没有哈希计算成本，也不需要桶结构。用 EnumMap 替代 HashMap，在数据量很大时性能差异明显，而且遍历顺序默认就是枚举的声明顺序，天然可控。

实际开发中，状态机、类型分发路由、配置按类型归档等场景都适合 EnumMap。比如一个订单处理系统，按订单状态映射到不同处理器：

EnumMap<OrderStatus, OrderHandler> handlerMap = new EnumMap<>(OrderStatus.class); handlerMap.put(OrderStatus.CREATED, createdHandler); handlerMap.put(OrderStatus.PAID, paidHandler); // ...

用起来很顺手。如果想要求所有枚举值都必须有处理器，EnumMap 还能配合 EnumSet 做缺失检测，实现“每个状态必须有处理器”的检查，比用 HashMap 后自己写一套判断逻辑要简洁得多。

5. 并发场景下的 Map 选择，别把所有问题都扔给互斥锁

很多人提到并发 Map，条件反射就是“用 ConcurrentHashMap”。这没错，但我希望先解释清楚为什么它是默认答案，以及什么情况下它也不是最优解。

5.1 同步包装类的局限

Hashtable 是 Java 早期就存在的同步 Map 实现，它通过在方法上加 synchronized 保证线程安全。它的并发能力很差：同一时间只有一个线程能执行 put、get 等操作，其他线程全部阻塞等待。所谓线程安全，代价是串行化的吞吐，在多核高并发场景里基本属于被淘汰的用法。

Collections.synchronizedMap(new HashMap<>()) 是 Hashtable 思路的变体：它包装一个 HashMap，把所有方法入口同样加上 synchronized。比起裸用 HashMap 要安全，但在吞吐上没有本质改进，甚至因为外层包装而多一些方法调用开销。

这两种方案的共同缺点是整表锁，锁的粒度是整个容器。并发读多写少时，全局互斥会造成不必要的竞争，读操作明明互不影响，却也要排队拿锁。

5.2 ConcurrentHashMap 为什么能扛住

ConcurrentHashMap 的并发设计走的是另一条路线：桶级并发。Java 8 以后，它放弃了 Java 7 的 Segment 分段锁设计，改为 CAS 加 synchronized 锁定单个桶节点。put 操作时先通过 CAS 确保桶位置能正确初始化，真正需要写某个桶时也只需要锁住那一条链表或红黑树的头节点，不同桶之间可以并行写入，读操作则基本无锁，靠 volatile 保证可见性。

但 ConcurrentHashMap 有一个需要特别注意的问题：单独的 get 和 put 是线程安全的，复合操作却不一定。拿这段代码为例：

if (!cache.containsKey(key)) { cache.put(key, load(key)); }

这段代码在 ConcurrentHashMap 下并不是原子操作，两个线程可能都发现 key 不存在，然后各自 load 并 put，后写入的覆盖了先写的。正确写法是用它提供的原子方法：

cache.computeIfAbsent(key, k -> load(k));

computeIfAbsent 在 key 不存在时才执行加载函数，并且整个过程原子完成。这个区别很细微但非常致命，尤其在缓存预热、防击穿的场景里。类似的还有 merge、computeIfPresent，能用这些原子方法表达的逻辑，就不要自己写“先查后写”的两段式。

还有一个细节：ConcurrentHashMap 不允许 null key 和 null value。这与 HashMap 正好相反。原因在于并发场景下，null 值可能被用来表示“没有这个键”，而这种模糊语义在多线程环境里会引起误判。如果你确实需要 null 值，要么换容器，要么用 Optional 包装，总之别勉强硬塞。

5.3 并发读极高而写入很低的场景

如果并发场景里读操作占绝对主导、写操作极少，而且 Map 在初始化后基本不再变化，那么与其用 ConcurrentHashMap 的同步开销保护读安全，不如考虑不可变 Map。Java 9 的 Map.of 或者 Guava 的 ImmutableMap 都提供了不可变映射，天然线程安全，读操作没有任何锁竞争。配合 volatile 或原子引用做整体替换，往往能得到更干净的工程结构。

不过这种优化属于“最后一公里”级别的调优。除非你确实通过压测定位到并发瓶颈，否则不要为了微小的差异引入额外复杂度。常规业务里，ConcurrentHashMap 已经能覆盖绝大多数并发 Map 需求。

6. 从接口到实现：方法论与避坑实录

把上面几节讲的实现类串起来，你会发现所谓“选择”其实有一条比较清晰的决策路径。先讲我常用的三步选型思路，再分享我在实际项目里踩过的坑，最后给出一张速查表。

6.1 三步选型的经验流程

第一步，确认你要的到底是不是 Map。如果只是从一批对象里按某个属性快速找到一个元素，HashMap 足够；如果有“哪个键出现了几次”的统计需求，HashMap 配合 merge 也足够。不要一遇到键值对就往 Map 上靠，有时数组加线性扫描反而更简单。

第二步，确认顺序需求。无顺序要求直接 HashMap；有“插入序等于使用序”的要求就用 LinkedHashMap；有“按键排序”的输出需求再考虑 TreeMap；如果需求是“按枚举声明顺序”，直接 EnumMap 最省事。

第三步，检查并发环境。容器是否会被多个线程共享？是，再考虑 ConcurrentHashMap；否，就继续用普通实现。这里有个常见的误判：方法内部创建的局部 map，每次调用都是新对象，根本不参与共享，不需要并发处理。只有静态成员、实例成员、外部传入的容器等真正共享的引用才需要考虑并发问题。

这套方法虽然简单，但在项目里能规避至少八成的“瞎选 Map 实现”问题。

6.2 我在真实项目中踩过的三个典型坑

第一个坑是关于初始容量的误用。某次做数据聚合，预计有 20000 条记录，我直接写了 new HashMap<>(20000)，想着“设了容量就不会扩容了”。结果因为负载因子 0.75 的存在，实际装到 15000 条左右就触发了扩容，20000 条数据在插入过程中白白多了一次全量 rehash。单次 rehash 十几毫秒，平时无感，但在一个循环执行上千次的批处理里，累积起来就是几十秒的浪费。后来我统一改成了 new HashMap<>(expectedSize * 4 / 3 + 1)，这类问题基本上消失了。

第二个坑是 TreeMap 的比较器不一致导致的数据覆盖。之前做报表合并，用“日期加部门”作为 key，当时偷懒只比较日期，结果同一天两个部门的记录被当成同一个 key，后一条覆盖了前一条，报表数据少了一行，排查了很久才想到比较器的问题。从那以后，凡是为 TreeMap 写 Comparator，我都会刻意让比较规则在逻辑上能唯一定位到一条记录，必要的时候把主键字段也加进去。

第三个坑是 LinkedHashMap 的 accessOrder 模式在遍历时被误触。我实现过一次缓存模块，缓存对象用了 LRU 模式。某次排查线上日志时发现，每次遍历 keySet 都会触发大批量节点移动，而遍历只是为了打印缓存摘要，根本不需要访问顺序。后来给遍历逻辑加了一个标记位：只有真正命中缓存时才更新访问顺序，打印摘要走内部快照，不去访问原容器。这一类问题在 LRU 容器上特别容易发生，提醒各位留意。

6.3 最终速查表

这张表不是标准答案，覆盖的是日常 90% 的选型场景。真正项目的决策最终还是回到需求本身的语义诉求，也就是“哪个实现最能自然表达你的业务意图”。

最后再分享一点个人体会：Java 容器这块的技术含量，不在于背下每个实现的细节，而在于遇到具体问题时，能快速判断出“当前场景的约束是什么，哪一类数据结构最匹配”。Map 只是容器家族的一部分，上篇讲过 List 和 Set，这篇补完了 Map，但队列、堆、双端队列这些容器同样有类似的选择逻辑。后续再写文章的时候，我会把并发队列和阻塞队列的选型也整理出来——那是另一个同样值得深入研究的主题。