LinkedHashMap与LinkedHashSet有序性原理及实战解析

做后端接口开发的朋友，应该都碰过这种场景：业务上要求“按我 put 进去的顺序遍历输出”，结果用 HashMap 一跑，顺序全乱了；有人直接告诉你“用 LinkedHashMap 就行”，但换完之后心里其实没底——为什么它就记得住顺序？LinkedHashSet 又是怎么回事？我几年前在做支付网关时，就因为报文排序列用错了集合，导致联调阶段验签一直失败，排查了一下午才发现是 HashMap 的遍历顺序不固定，对方服务按约定字段拼串，我这边却按另一套顺序拼，两边自然对不上。自那之后，我对“需要按插入顺序遍历”这件事特别敏感，这几种集合的差异也变成了我代码评审时重点关注的点。

这篇就把 LinkedHashSet 和 LinkedHashMap 讲透：不光是 API 怎么用，还包括它们底层为什么能做到有序、什么情况下顺序会失效、和 TreeMap 的排序到底有什么区别、实际项目中怎么选型。不管你是刚学 Java 的初学者，还是写过几年业务代码想补底层细节的开发者，都能从这里拿到可以直接落地的经验。

1. 为什么 HashMap/HashSet 的遍历顺序会“乱”

1.1 HashMap 不是按你 put 的顺序存数据

很多人的直觉是：Map 就是把键值对存起来，遍历时应该按添加顺序返回。但 HashMap 从来没承诺过这一点，它的存储结构决定了遍历顺序天然不可预测。

HashMap 内部是一个“数组 + 链表/红黑树”的结构。put 一个键值对时，先算 key 的 hashCode，再通过 (n - 1) & hash 定位到数组下标，这个下标是哈希值换算出来的，和 put 的先后没有关系。数据落到数组的哪个桶里，取决于 key 的哈希结果。遍历的时候，HashMap 会从数组下标 0 开始，一路扫到最后一个桶，在桶里再沿着链表往下走。也就是说，你看到的顺序本质上是“哈希桶的位置顺序”，而不是插入顺序。

打个比方，HashMap 就像一栋有很多房间的酒店，前台按名字的笔画数安排房间，客人入住时并不按到达顺序排号。你要找客人时按房间号巡楼，走出来的人自然不是“先到先出”。

java复制Map<String, String> orderDetail = new HashMap<>();
orderDetail.put("orderNo", "A20250201");
orderDetail.put("merchantId", "1000001");
orderDetail.put("amount", "98.50");
orderDetail.put("notifyUrl", "https://example.com/callback");

for (String key : orderDetail.keySet()) {
    System.out.println(key + " -> " + orderDetail.get(key));
}

这段代码最终打印的顺序完全不保证是 orderNo、merchantId、amount、notifyUrl。你能看到的只是“当前这批 key 的哈希分布落在桶上的结果”。数据一旦增多、扩容发生，顺序还可能再次变化。

1.2 HashSet 同样无序，因为它底层就是 HashMap

HashSet 看起来是个只存元素的集合，但它内部并不是自己维护一个数组，而是包了一个 HashMap。当我们 add(e) 时，底层执行的是 map.put(e, PRESENT)，这里的 PRESENT 是一个固定的占位对象。

既然 HashSet 的存储落到了 HashMap 上，那么迭代 HashSet 时，实际上是在迭代 HashMap 的 keySet，顺序自然也是由哈希桶决定的。你在一个 HashSet 里依次放入“苹果”“香蕉”“橙子”，遍历结果不一定是这个顺序。

很多初学者会把 HashSet 当成“没有顺序的 List”，这种理解不完整。准确说：HashSet 是一个基于 HashMap 的、元素不重复且顺序不可预期的集合。它只能保证“去重”，不能保证“按添加顺序去重”，也不能保证“按某个规则排序”。

1.3 哪些业务场景真的对顺序敏感

既然 HashMap/HashSet 无序，那“按插入顺序遍历”的需求到底从哪来？我归纳一下实际项目里最典型的几类：

第一类是报文拼接和签名验签。业务方约定参数按某个顺序拼成字符串，再接上密钥做摘要。拼串时如果用的是 HashMap，每次启动程序后同一个 key 集合大概率落在相同的桶里，顺序看似稳定，但一旦代码改动、数据量变化或 JVM 升级导致 hash 分布变化，顺序就可能变，签名也就对不上了。

第二类是接口返回固定结构的 JSON。有些老系统的前端或对接方对字段顺序有强依赖，或者你们内部调试时希望 JSON 的 key 顺序和代码赋值顺序一致，方便肉眼排查。很多 JSON 库在解析 Object 时也会依赖 LinkedHashMap 来保留原始字段顺序。

第三类是“去重且保持首次出现顺序”。比如一份权限 ID 列表，接口传入时可能有重复，需要去掉重复但保留业务配置时的先后关系；再比如批量导入时，按 Excel 行号去重并保留原顺序。HashSet 做不到，ArrayList 配合 contains 又是 O(n²)，性能容易出问题。LinkedHashSet 就是为这个场景设计的。

第四类是最近访问/最近使用的淘汰场景，也就是 LRU 缓存。LinkedHashMap 的 accessOrder 模式天生适合做这件事。

这些场景有一个共同点：顺序不是靠某个比较器排出来的，而是“按元素进入集合的先后”来确定的。普通的 HashMap/HashSet 管不了这个，需要用带“链式记忆”的集合。

2. LinkedHashMap 有序背后的设计秘密

2.1 一张哈希表加一条双向链表

LinkedHashMap 类名里的 Linked，指的不是链表散列中的“拉链”，而是另一条独立的双向链表。它的核心设计是：在保留 HashMap 原有“数组 + 链表 + 红黑树”结构的基础上，给每个节点额外增加 before 和 after 两个指针，把所有节点串成一条“按插入顺序排列”的双向链表。

可以这样理解：HashMap 是一堆散落在各个桶里的节点，彼此之间没有“谁先来”的关系；LinkedHashMap 则在桶结构之外，另起了一条队列，每个新节点插入时，除了放进对应桶，还会被接到这条队列的尾部。遍历时直接从队列头 head 开始，沿着 after 指针一个一个走，走完就是插入顺序。

因为多维护了这条双链表，LinkedHashMap 每个 Entry 比 HashMap 的 Node 多了两个引用。如果存了几千万条数据，内存增量是肉眼可见的，这点我后面会展开讲。但带来的好处是巨大的：遍历顺序稳定，而且与哈希桶的分布完全解耦。

java复制Map<String, String> linkedMap = new LinkedHashMap<>();
linkedMap.put("orderNo", "A20250201");
linkedMap.put("merchantId", "1000001");
linkedMap.put("amount", "98.50");
linkedMap.put("notifyUrl", "https://example.com/callback");

for (String key : linkedMap.keySet()) {
    System.out.println(key);
}

这段代码无论跑多少次，只要没有删除后重新 put，输出结果一定是 put 的顺序。正因为这一点，LinkedHashMap 非常适合上面说的报文拼接、固定列表输出等场景。

2.2 扩容、删除和哈希冲突不会破坏顺序吗？

如果你了解 HashMap 扩容，可能会有疑问：扩容时所有节点重新哈希，数组下标全变了，LinkedHashMap 是怎么保证顺序不变的？

这里面有个容易被忽视的重点：扩容改变的是“节点落在哪个桶”，并不会改变“节点在双链表中的前后位置”。LinkedHashMap 节点同时存在于两个结构中：桶数组负责快速查找，双链表负责记录顺序。扩容时，节点会被拆到新桶数组，但每个节点上的 before 和 after 指针从头到尾没有被改过，双链表还是原来那条双链表，遍历顺序自然不变。

删除元素时情况类似。LinkedHashMap 重写了 afterNodeRemoval 回调，在 HashMap 删除节点后，同步把它从双链表中摘掉。链表的前后节点重新对接，剩下的节点顺序依旧连续。

哈希冲突也不会影响双链表顺序。同一个桶里即使有多个节点形成链表，它们在双链表中的相对位置仍由插入先后决定，而不是由桶内链表顺序决定。这也是 LinkedHashMap 和普通 HashMap 的一个本质差别：HashMap 桶内链表的顺序只是碰撞结果的体现，LinkedHashMap 的双链表顺序才是遍历时真正使用的顺序。

2.3 三个回调方法：LinkedHashMap 如何“寄生”在 HashMap 上

如果你读过 JDK 源码，会发现 LinkedHashMap 本身几乎没有重写 put、remove 这些核心方法，它靠的是 HashMap 预留的三个钩子方法：

• afterNodeAccess(Node<K,V> e)：在某个节点被访问后调用。
• afterNodeInsertion(boolean evict)：在插入新节点后调用。
• afterNodeRemoval(Node<K,V> e)：在移除节点后调用。

HashMap 在增删改查的关键路径上会调用这些方法，默认实现都是空的。LinkedHashMap 通过重写它们来维护自己的双链表结构。这是一种挺优雅的模板方法模式：父类定义了主流程，子类只关心自己的“附加逻辑”。

这里也提醒大家，如果之后基于 LinkedHashMap 做二次开发，不要破坏这些回调对链表的操作。比如重写 removeEldestEntry 实现 LRU 时，是在 afterNodeInsertion 里被触发的，如果自己又去手动修改链内节点顺序，很容易踩坑。

2.4 accessOrder 参数：从“插入顺序”切到“访问顺序”

LinkedHashMap 有一个特殊构造方法，传入第三个布尔参数 accessOrder。默认是 false，表示按插入顺序遍历；如果传 true，则表示按访问顺序遍历，也就是每次 get 或 put 已有 key 时，都会把该节点移动到双链表尾部。

为什么会有这个设计？因为只要把遍历顺序定义为“最近最少使用在前、最近使用在后”，再配合自动淘汰最老元素，就能实现一个 LRU 缓存。Java 官方在集合框架里埋了这个语义，就是等你在实际场景里去用。

需要注意的是，accessOrder 模式下，单纯的 containsValue 不会改变顺序，但 get、put 已存在的 key 都会触发节点移动。你写代码前一定要想清楚，这个“访问”到底指哪些操作，否则容易得到意料之外的结果。

3. LinkedHashSet 与 LinkedHashMap 的选型和构造细节

3.1 LinkedHashSet 底层其实是 LinkedHashMap

LinkedHashSet 的类继承结构看起来很简单，它直接继承 HashSet。大多数人不知道的是，HashSet 有一个包级私有的构造方法，允许指定底层 map 的类型：

java复制HashSet(int initialCapacity, float loadFactor, boolean dummy) {
    map = new LinkedHashMap<>(initialCapacity, loadFactor);
}

LinkedHashSet 调用这个构造器时，传 true 过去，底层 map 就变成了 LinkedHashMap。元素的增删查实际走的是 LinkedHashMap 的方法，但对外暴露的是 Set 语义。

因此，LinkedHashSet 的迭代顺序和 LinkedHashMap 的 keySet 迭代顺序完全一致，都是插入顺序。它适合做“去重并保持首次加入顺序”的事情。举个例子，一个 List 中有重复 ID，想按第一次出现顺序去重：

java复制List<Long> rawIds = Arrays.asList(1001L, 1002L, 1001L, 1003L, 1002L);
List<Long> uniqueIds = new ArrayList<>(new LinkedHashSet<>(rawIds));

这段代码特别常用，比手动循环判断 contains 要简洁，复杂度也从 O(n²) 降到了 O(n)。你不需要关心 LinkedHashSet 内部的 LinkedHashMap 细节，只要记住一个结论：它是“能记顺序的 HashSet”。

3.2 构造参数怎么定？容量和负载因子别乱调

LinkedHashMap 的构造器和 HashMap 基本一致，常见有下面几种：

我看到不少人在创建集合时随手写 new LinkedHashMap<>(10000)，以为这样能装 1 万条数据不扩容，其实是不对的。initialCapacity 只是哈希表数组的初始长度，不是阈值。当元素数量超过 capacity * loadFactor 时，HashMap 会触发扩容，重新分配数组并 rehash。

如果你明确知道会放大约 500 条数据，又不想中途扩容，建议把初始容量设为 500 / 0.75 ≈ 667，再结合 HashMap 会向上取整到 2 的幂，实际容量可能会变成 1024。过于纠结精确容量没有意义，预留 30% 的空间就够了，因为扩容机制本身可以自动兜底。

负载因子不建议随便调大。调大到 1.0 虽然能减少扩容，但哈希冲突会明显增加，get/put 的平均耗时可能反而升高。为了省一点扩容代价去牺牲查询性能，在小数据量下不划算，在数据量极大时又可能引发严重的哈希退化。

3.3 Stream 收集时如何保持插入顺序

实际开发中，很多人把数据从 List 转成 Map 时，会用 Collectors.toMap，但这个方法默认返回 HashMap，顺序不可控。如果后续需要按原集合顺序遍历，要在 toMap 的第四个参数里指定 LinkedHashMap 作为 mapFactory：

java复制List<OrderItem> items = getOrderItems();
Map<String, OrderItem> itemMap = items.stream()
        .collect(Collectors.toMap(
                OrderItem::getItemNo,
                Function.identity(),
                (oldValue, newValue) -> newValue,
                LinkedHashMap::new
        ));

这样生成的 Map 在遍历时，就会按照 items 集合的元素顺序出现。这是一个很容易被忽略的细节，也是我在 Code Review 时经常会指出的问题：很多人刚学过 LinkedHashMap，知道要用它，结果在 Stream 里一转，又变回了无序的 HashMap。

3.4 选型建议：Set 还是 Map，还是 List

面对“按插入顺序”这个需求，到底用哪个类，我提供一个简单的判断思路：

如果只是判断元素是否存在并去重，不关心 value，用 LinkedHashSet。比如接口幂等时记录一批已经处理过的订单号，去重后还要按处理顺序输出日志，选它就很顺手。

如果需要根据 key 拿 value，又要按照写入顺序输出，用 LinkedHashMap。比如配置中心下发的一组动态参数，既要从里面按 key 取值，又要保证修改后能按顺序展示。

如果元素本身会有重复，且你更关心下标和重复项，或者可能要频繁随机访问某个位置的元素，那 List 更合适。不要因为 LinkedHashMap 有序就强行用它替代 List，毕竟它还是一个 Map，定位靠 key，不靠下标。

不要和 TreeMap/TreeSet 混在一起。TreeMap 的顺序是按 key 的自然顺序或你传入的 Comparator 决定的，属于“排序”而不是“插入顺序”。如果你的需求是按键排序，再去用 TreeMap；如果只是来一个记一个、按来的时候遍历，那用 LinkedHashMap。

4. 实战：按插入顺序遍历的业务场景与完整代码

4.1 场景一：报文签名拼接，字段顺序必须稳定

我前面提到支付网关验签失败，其实就是这类问题。对接方要求参与签名的字段按固定顺序拼接，用于验签的代码自然也得按同一个顺序拼。这里直接给出一段可用的示例：

java复制Map<String, String> signParams = new LinkedHashMap<>();
signParams.put("merchantId", "1000001");
signParams.put("orderNo", "A20250201");
signParams.put("amount", "98.50");
signParams.put("currency", "CNY");
signParams.put("notifyUrl", "https://example.com/callback");
signParams.put("signType", "HMAC-SHA256");

StringBuilder raw = new StringBuilder();
for (Map.Entry<String, String> entry : signParams.entrySet()) {
    if (raw.length() > 0) {
        raw.append('&');
    }
    raw.append(entry.getKey()).append('=').append(entry.getValue());
}
raw.append("&key=yourSecretKey");

String sign = DigestUtils.sha256Hex(raw.toString());

这段代码能不能验签通过，前提之一就是 signParams 的遍历顺序必须和对方约定一致。换成 HashMap 后，每次遍历顺序由哈希桶决定，肉眼看起来可能连续几次都一样，但一旦 map 扩容、key 增多或者代码放到不同 JVM 版本上跑，意外就来了。

这里我再补充一个实际经验：对象转字符串时，如果依赖反射遍历字段来做签名或转义，一定要先看字段排序规则。像 Hutool 的 MapUtil.sort 或者 JSON 库的序列化顺序，都不一定等于你的“约定顺序”。最稳妥的做法就是显式用一个 LinkedHashMap 把字段顺序写死，可读性最好，也最不容易被工具库版本差异影响。

4.2 场景二：去重并保留首次出现顺序

接口层接收一批标签 ID 时，用户可能重复提交。业务上只保留第一次出现的 id，同时还要按用户勾选的原始顺序返回。这个需求如果写双重 for 循环，代码难看且效率低；用 LinkedHashSet 一行就解决。

java复制List<String> tagIds = Arrays.asList("t01", "t02", "t01", "t03", "t02", "t04");
LinkedHashSet<String> orderedSet = new LinkedHashSet<>(tagIds);
List<String> distinctTagIds = new ArrayList<>(orderedSet);
System.out.println(distinctTagIds);

输出结果会稳定保持 t01、t02、t03、t04。你可能会说，用 list.stream().distinct().collect(...) 也可以，但在很多旧项目中 Stream 风格不统一，或者集合数据量很小，直接用 LinkedHashSet 反而更直观。

需要注意的是，Set 的去重依赖元素的 equals 和 hashCode。如果你存的是一个自定义对象，只希望按对象里某个字段去重，却没有重写 equals/hashCode，那么 LinkedHashSet 认为的“重复”可能和业务上的“重复”不是一回事。遇到这种需求，要么重写这两个方法，要么还是用 Map<String, T> 手动按业务主键去重，用 LinkedHashMap 保留顺序，覆盖旧值。

4.3 场景三：更新已有 key 时顺序会不会变？

这是 LinkedHashMap 使用中最容易忽略的细节，我必须单独拿出来说。默认插入顺序模式下，put 一个“已存在的 key”只会更新 value，不会把这个 key 挪到链表尾部。假设：

java复制Map<String, String> conf = new LinkedHashMap<>();
conf.put("retryCount", "3");
conf.put("timeout", "3000");
conf.put("callback", "true");

conf.put("retryCount", "5");

遍历结果仍然是 retryCount、timeout、callback，顺序不变。因为 retryCount 已经存在，LinkedHashMap 没有重新插链。

那如果你就是想把这个 key 的“插入时间”刷新到最新呢？必须先把旧 key 删掉，再重新 put：

java复制conf.remove("retryCount");
conf.put("retryCount", "5");

remove 操作会把节点从双链表中摘除，之后 put 会把它当成一个新节点接到链表尾部。这个行为在需要“调整某个 key 到最新位置”的场景中非常有用。比如一个手动维护菜单顺序的逻辑：用户想改某菜单的展示顺序到末尾，可以按新顺序 remove 再 put，而不用重建整个 Map。

4.4 场景四：用 accessOrder 实现一个最简单的 LRU 缓存

很多人面试时被问“怎么实现 LRU”，其实 LinkedHashMap 已经内置了大部分能力，只要把 accessOrder 设为 true，并重写 removeEldestEntry 方法控制容量即可。

java复制public class LRUCache<K, V> extends LinkedHashMap<K, V> {

    private final int maxEntries;

    public LRUCache(int maxEntries) {
        super(16, 0.75f, true);
        this.maxEntries = maxEntries;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > maxEntries;
    }
}

使用：

java复制LRUCache<String, String> cache = new LRUCache<>(3);
cache.put("a", "1");
cache.put("b", "2");
cache.put("c", "3");
cache.get("a"); // 访问 a，a 会被移到链表尾部
cache.put("d", "4");
System.out.println(cache.keySet());

由于链表头部永远是最久未使用的元素，当 cache 容量超过 3、再插入 d 时，removeEldestEntry 会返回 true，淘汰头部元素。最终 keySet 输出什么，取决于 get("a") 是否让 a 免于淘汰，这个逻辑留给读者自己推一遍，能推明白就说明你真的理解了访问顺序。

这个实现确实简单，但要注意它不是线程安全的。多线程环境下，要么在外部对 cache 加锁，要么使用 Collections.synchronizedMap 包一层。在高并发场景下如果要求严格精确的 LRU 语义，我个人会更倾向用 Caffeine 这类专门做缓存的库，毕竟它们处理了并发、淘汰策略、统计等一大堆细节，自己造轮子很容易在边界条件上翻车。

5. 不同遍历方式的取舍与性能实测感受

5.1 几种常见的遍历写法，顺序都一样吗？

LinkedHashMap 的四种常见遍历方式，底层最终都会走双链表，所以遍历顺序是一致的：

java复制// 方式一：entrySet
for (Map.Entry<String, String> entry : map.entrySet()) {
    System.out.println(entry.getKey() + "=" + entry.getValue());
}

// 方式二：keySet 再 get
for (String key : map.keySet()) {
    System.out.println(key + "=" + map.get(key));
}

// 方式三：values（只能拿到 value）
for (String value : map.values()) {
    System.out.println(value);
}

// 方式四：Java 8 forEach
map.forEach((key, value) -> System.out.println(key + "=" + value));

从“顺序是否一致”角度讲，四种方式没有任何差别。但性能上有一点提醒：方式二在遍历 key 时，每次还用 key 去 map 里 get 了一次，等于额外做了一次哈希查找。数据量小的时候无所谓，但当 Map 里有几十万条数据且循环逻辑复杂时，多出来的这一次次哈希计算不可忽视。

我建议在只需要遍历键值对的场景直接使用 entrySet。如果需要删除某些元素，优先考虑迭代器：

java复制Iterator<Map.Entry<String, String>> it = map.entrySet().iterator();
while (it.hasNext()) {
    Map.Entry<String, String> entry = it.next();
    if (entry.getValue().startsWith("temp")) {
        it.remove();
    }
}

如果用 for-each 在遍历过程中直接调用 map.remove(key)，大概率会抛 ConcurrentModificationException。这个异常并不是并发环境才有的，普通单线程在迭代中修改结构也会触发，因为集合内部的 modCount 变了。

5.2 LinkedHashMap 遍历反而可能比 HashMap 更快？

第一次听到这句话，很多人会觉得奇怪：LinkedHashMap 不是多维护了一条链表吗，为什么遍历还可能更快？

HashMap 的迭代器从头到尾扫描数组，如果数组长度是 1024，实际只存了 64 个元素，遍历时要做 1024 次桶位置判断，其中大部分是空桶。LinkedHashMap 的迭代器是从双链表头出发，有多少元素就走多少次，不会去访问空桶。

所以当 HashMap 容量开得比较大、负载因子又低于默认值 0.75，或者经历过扩容后留下大量空桶时，LinkedHashMap 的遍历性能在数据量足够大时确实会更稳定。当然这个差异在你日常的几百、几千条数据里几乎感知不到，只有做大数据量遍历或批量导出时才有参考价值。

相反的代价在插入操作上。LinkedHashMap 每次 put 新节点，除了在哈希桶里插入，还要更新双链表的头尾指针，理论插入成本比 HashMap 略高。实际测试中，这个差距往往也很小，插入普通对象时可能只有几个百分点的影响。项目里如果真的有亿级数据写入和遍历需求，才需要认真做压力测试，否则没必要为了这点差异放弃有序遍历带来的便利性。

5.3 从新节点加入角度理解“顺序的额外内存成本”

我之前提到，LinkedHashMap.Entry 比 HashMap.Node 多了 before、after 两个引用。在启用指针压缩的 64 位 JVM 上，一个引用约占 4 字节，两个就是额外 8 字节；如果没压缩，可能更多。

假设你有 1000 万条 entry，额外内存可能就是 80 MB 以上，这个量级对大型服务来说不能完全忽略。如果你的场景里根本没人在意遍历顺序，那就老老实实用 HashMap，没必要为了“可能以后有用”而白白增加内存占用。如果你确实要顺序，那这 80 MB 通常是值得的，总比在业务层额外维护一个有序 key 列表又容易不同步要省心得多。

我在项目中见过一种不太推荐的玩法：为了保持顺序，用一个 HashMap 存数据，再用一个 ArrayList 单独记录 key 顺序。这种方案表面上省了 LinkedHashMap 的 before/after 指针，但实际上你得自己保证 Map 和 List 在增删时严格同步，代码里任何一处遗漏，都会导致顺序错乱，排查起来远比直接使用 LinkedHashMap 痛苦。

6. 常见问题排查：顺序不对、去重失败、并发踩坑

6.1 明明用的是 LinkedHashMap，为什么顺序还是不对

这是我在 Code Review 里遇到最多的问题。很多人确实写了 new LinkedHashMap<>()，但随后又把这个 map 传给了某个方法，方法内部将其转成了普通 HashMap，或者用 Stream 重新 collect 成了 HashMap。比如：

java复制Map<String, String> order = new LinkedHashMap<>();
order.put(...);

Map<String, String> copied = new HashMap<>(order);

这行代码一写，LinkedHashMap 通过双链表记住的顺序就没了。你可以把 HashMap 想象成一个“伸手一抓就是最方便”的袋子，从 LinkedHashMap 倒进 HashMap，顺序信息自然丢失。

要保留顺序，最稳妥的原则是：从创建到使用，一整条链路上都保持 LinkedHashMap 类型，或者通过 Collections.unmodifiableMap(new LinkedHashMap<>(...)) 封装成只读视图。不要在中途用普通 HashMap 接收。如果方法的参数类型是 Map<String, String>，传进去 LinkedHashMap 实例没问题，但方法内部如果 new HashMap<>(param)，出来就乱了。

6.2 remove 后重新 put，顺序到底怎么算

这个问题我前面已经提到过，但值得放到排查清单里。插入顺序模式下，如果一个 key 已经被存在，直接 put 不会移动它的位置；只有先 remove 再 put，它才会被当作新元素放到尾部。

如果你在做一个“上移/下移/置顶”功能的列表展示，希望通过修改 Map 来改变某项顺序，就必须显式 remove。如果你发现 remove 之后再次 put，Map 里的顺序没按预想变更，那要检查 remove 用的 key 和 put 的 key 是否同一个对象，equals/hashCode 是否一致。比如 key 是自定义对象，没有正确重写 equals，remove 时找不到对应节点，自然删不掉。

6.3 LinkedHashSet 去重失效的坑

LinkedHashSet 的去重依赖每个元素的 hashCode 和 equals。业务对象如果不重写这两个方法，两个属性完全相同的对象也会被当成不同对象，去重就失效了。

解决思路有两个：一是按业务字段重写 hashCode 和 equals，让语义层面的“同一条记录”在 Java 中真的相等；二是通过 Map 手工管理：

java复制Map<String, BusinessItem> uniqueByCode = new LinkedHashMap<>();
for (BusinessItem item : incomingList) {
    uniqueByCode.putIfAbsent(item.getCode(), item);
}
List<BusinessItem> result = new ArrayList<>(uniqueByCode.values());

这样既按 code 去重，又保留了第一次出现的位置。LinkedHashSet 适用于元素自身已经正确实现相等语义的场景；如果只是临时按某个属性去重，Map 路由的方式更灵活，也更容易读明白。

6.4 多线程并发场景下的顺序和线程安全

LinkedHashMap 和 LinkedHashSet 都不是线程安全的。多个线程同时写，不止可能出现数据覆盖的问题，双链表还可能被破坏，导致遍历时出现环或丢节点，表现形式非常诡异。

如果你需要线程安全，又能接受一定顺序语义被弱化，可以用 ConcurrentHashMap，但它不保证插入顺序，所以你无法依赖它的迭代顺序。如果一定要“并发 + 按插入顺序”，可以给 LinkedHashMap 外面加锁，或者使用 Collections.synchronizedMap(new LinkedHashMap<>())。

这里有一个细节要提醒：Collections.synchronizedMap 只保证了 put、get、remove 这些单个方法内部的原子性，它并不会在你遍历时自动加锁。你用 for-each 遍历它时，仍然需要手动在外面加锁：

java复制Map<String, String> syncMap = Collections.synchronizedMap(new LinkedHashMap<>());
synchronized (syncMap) {
    for (Map.Entry<String, String> entry : syncMap.entrySet()) {
        // 安全遍历
    }
}

如果是高并发读写场景，这种全锁定方式吞吐量可能不够，我建议从架构上重新考虑：读多写少可以上读写锁，写多读少可以引入专门的并发有序结构，或者直接使用支持排序语义的缓存组件。用普通集合硬扛高并发，维护成本极高。

6.5 常见问题速查表

我自己在实际使用中还有一个习惯：凡是“顺序敏感”的集合，在变量命名或注释里都会写清楚“不要替换成 HashMap”。特别是签名拼接和报文输出这种涉及资金校验的代码，一个集合类型改动，可能带来线上事故。LinkedHashMap 和 LinkedHashSet 并不是什么复杂的高深技术，但它们解决的是“有序遍历”这个非常具体且高频的痛点。搞明白它们和 HashMap、TreeMap 的区别后，以后再遇到“需要按插入顺序遍历”的设计，心里就有底了。