linkedhashset内存开销主要来自每个节点多出的before/after两个引用字段，64位jvm指针压缩下共+8字节，叠加对齐填充总计约+16字节/元素，形成环状强引用链影响gc，属空间换顺序的明确设计取舍。
LinkedHashSet 的内存开销主要来自双向链表的额外引用，不是“多存了一份数据”，而是每个元素节点多存了两个指针。
每个元素多占 16 字节（典型情况）
在主流 JVM（如 HotSpot）上，一个对象头 + 对象字段会带来固定开销。LinkedHashSet 中每个元素实际封装为 LinkedHashMap.Entry 类型节点，相比 HashSet 的 HashMap.Node，多了两个引用字段：before 和 after。
- 在 64 位 JVM 启用指针压缩（默认开启）时，每个引用占 4 字节 → 共 +8 字节
- 加上对齐填充（JVM 对象内存按 8 字节对齐），通常总增加量为 16 字节/元素
- 例如：存 10 万个字符串，仅链表指针就多占约 1.6 MB（100000 × 16）
链表结构本身不复制元素，但延长了对象生命周期
双向链表只是把已存在的哈希表节点串起来，不会重复存储 key 或 value。但它让所有节点相互持有强引用：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 头节点 → 第二个节点 → … → 尾节点 → header 哑节点（循环链表）
- 这种环状结构使整个链表成为一个不可分割的引用链，影响 GC 时机
- 即使某个元素从哈希桶中被移除（如发生 rehash 或删除），只要它还在链表中，就不会被回收
和 HashSet 对比：空间换顺序
HashSet 只需维护哈希桶数组 + 单向冲突链表（或红黑树），结构更轻量；LinkedHashSet 在此基础上叠加一套独立的双向链表：
- 哈希表负责 O(1) 查找 —— 和 HashSet 完全一致
- 双向链表只负责迭代顺序 —— 不参与查找，纯属“顺序索引”
- 没有“顺序索引”的代价，就没有插入顺序保证；这是明确的设计取舍
实际项目中怎么评估是否值得
是否接受这部分开销，取决于场景对“顺序”的刚性需求：
- 日志去重后要按访问时间展示？→ 值得，顺序是业务要求
- 临时中间集合、仅用于判重？→ 用 HashSet 更省，顺序无关紧要
- 元素本身很大（如大 byte[] 或嵌套对象）？→ 链表开销占比小，可忽略
- 元素极小且数量极大（如百万级 Integer）？→ 链表开销占比显著，建议压测对比
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
