电商购物车系统：利用 LinkedHashMap 实现变量商品的有序展示与过期处理

在电商场景里，购物车这个模块看似简单，其实藏着不少技术细节。尤其是当用户把商品加进去之后，期望看到的是按加入顺序排列，同时系统还得有能力把那些放了很久没动静的商品自动清掉。这两个需求，LinkedHashMap确实能搞定，问题在于——怎么用对。

先抛个结论：LinkedHashMap 不是“不能用”，而是默认不帮你做过期淘汰，并且扩容时的重哈希操作也可能带来一些预期之外的干扰。下面具体拆开来说。

保持插入顺序：关键在于 accessOrder = false

LinkedHashMap 内部维护着一个双向链表，默认按照插入顺序来排列元素。这一点大家都清楚。但有个前提：构造时必须明确指定 accessOrder = false（虽然这是默认值，但显式写出来更稳妥）。一旦你手滑设成了 true，它就变成了“每次访问就把节点挪到尾部”——简直是要了购物车的命。比如用户刚加了一个新商品，结果却被顶到了最下面，体验非常反直觉。

推荐的写法就是老老实实明确参数：

Map cartItems = new LinkedHashMap<>(16, 0.75f, false);

这里 false 就是显式声明“按插入顺序”，相当于给系统上了一道保险。

手动实现过期逻辑：LinkedHashMap 本身不带 TTL

这一点往往容易被忽略——LinkedHashMap 本身没有过期机制。想要实现“超时自动清理”，只能自己动手。

实践中比较常见的做法是：在每次读或者写操作的时候，顺手检查一下头节点（也就是最早插入的那个）是否已经超时，如果超时就移除；同时，把当前操作的那个项移到链表尾部，让活跃的商品尽量靠后，避免被误伤。

具体实现上，可以这样设计：

• 每个 CartItem 内部记录一个 lastModifiedTime（毫秒时间戳）；
• 封装一个 get(String key) 方法：先调用 super.get(key)，再更新该 item 的时间戳，并执行 moveToLast(key)；
• 封装一个 cleanExpired(long expireMillis)：反复从链表头部开始遍历，直到遇到第一个未过期的项为止，中间的过期项全部 remove() 掉。

说白了，过期清理是一个需要自己主动去触发的动作，不能指望框架帮你做。

避免扩容打乱顺序：预估容量 + 禁止 rehash 干扰

LinkedHashMap 扩容时，内部链表确实会重建，理论上顺序不会丢。但问题在于：扩容带来的性能开销是实打实的，而且可能让一些“刚加入就过期”的边缘 case 更难控制。

更稳妥的做法是提前算清楚：

• 根据业务场景预估单个用户购物车里最多放多少商品（比如 20），那么初始容量可以设为 20 / 0.75 ≈ 27，然后向上取到 32；
• 不要在遍历 cart 的同时修改它（比如边迭代边 remove 过期项），正确做法是用 Iterator.remove()，或者先收集要删除的 key，再统一删；
• 尽量避免依赖 entrySet().iterator() 的“排序稳定性”，更建议以 keySet() 遍历为主——后者与内部链表的顺序严格一致，逻辑更清晰。

轻量级替代思路：LinkedList + HashMap 组合

如果觉得 LinkedHashMap 的封闭设计让你觉得不够灵活（比如想按最后修改时间排序、或者支持多维度淘汰策略），那完全可以换一种思路——把职责拆开。

具体来说：

• 用 LinkedList 来维护商品 ID 的插入顺序；
• 用 HashMap 来做 O(1) 的查找；
• 过期清理时，从链表头部开始扫描，查询 HashMap 中对应的 item 是否过期，过期则同步删除链表和 Map 中的记录。

这种方式逻辑更透明，调试起来也方便。特别适合中等规模的购物车场景（比如 ≤ 100 个商品），并且对 GC 压力比较敏感的时候，这种组合比 LinkedHashMap 更容易控制内存行为。

说到底，技术选型没有银弹，关键还是看业务场景和团队对维护成本的接受度。你选哪个？