ArrayList尾插均摊O(1)，LinkedList头/尾插严格O(1)但内存开销大、缓存不友好；随机访问ArrayList为O(1)，LinkedList为O(n)；实际性能受JVM优化、GC及CPU缓存影响显著。
ArrayList 和 LinkedList 插入性能差异在哪
在尾部插入元素时，ArrayList 通常比 LinkedList 快；但在中间或头部频繁插入，LinkedList 的常数时间优势才可能体现——前提是没触发 ArrayList 的扩容，且你真的在用 Iterator.add() 或 ListIterator 做随机位置插入。
常见错误是以为“链表插入快”就无脑选 LinkedList，结果发现 list.add(0, item) 在 ArrayList 上是 O(n)，在 LinkedList 上也是 O(n)（因为要先遍历到索引 0？不，那是 get(0)；但 add(0, ...) 确实是 O(1)，因为头插直接改头指针）。可实际中，JVM 对 ArrayList 的连续内存访问高度优化，而 LinkedList 每次 new Node() 带 GC 压力，对象引用跳转还破坏 CPU 缓存局部性。
-
ArrayList尾插：均摊 O(1)，扩容时触发数组复制（O(n)），但扩容策略是 1.5 倍增长，摊还代价可控 -
LinkedList头插/尾插：严格 O(1)，但每个元素多两个引用字段（8~16 字节），内存占用翻倍以上 - 用
list.get(i)随机访问：前者 O(1)，后者 O(n)，哪怕 i=0 —— 因为LinkedList.get()内部仍要从头或尾开始遍历
HashMap 初始化容量与负载因子怎么设才不浪费
默认构造 new HashMap() 会用初始容量 16、负载因子 0.75，意味着第 13 个键值对插入时触发扩容。如果预估要存 1000 个元素，直接写 new HashMap(1024) 或 new HashMap(1280)（向上取最近的 2 的幂 × 1.25）更省事；硬算的话，用 (int) Math.ceil(expectedSize / 0.75) 再 round up 到 2 的幂。
负载因子不是越小越好：设成 0.5 能减少哈希冲突，但空间利用率腰斩，且扩容更频繁；设成 0.9 容易导致链表过长（Java 8+ 在桶中节点数 ≥ 8 且 table.length ≥ 64 才树化），反而增加查找开销。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 若 key 是字符串且长度短、取值范围小（如状态码 "OK", "ERR"），哈希分布可能极不均匀，优先考虑重写
hashCode()或换IdentityHashMap - 并发场景别用
HashMap加 synchronized 块，ConcurrentHashMap的分段锁（Java 7）或 CAS + synchronized 桶（Java 8+）更可靠 - Java 8 中，单个桶内链表转红黑树的阈值是 8，但前提是 table.length ≥ 64；否则先扩容，避免过早树化带来的额外内存和维护成本
HashSet、TreeSet、LinkedHashSet 各自不可替代的场景
HashSet 底层是 HashMap，插入/查找平均 O(1)，但不保证顺序；TreeSet 用红黑树，自动排序，操作 O(log n)，适合需要范围查询（如 subSet(from, to)）或天然有序输出的场景；LinkedHashSet 是带插入顺序的 HashSet，迭代性能接近 HashSet，但内存多一个双向链表指针，适合需去重+保序（如解析 CSV 表头、缓存最近请求 URL）。
容易踩的坑：把 TreeSet 当普通集合用，却忘了它的 add() 是 O(log n) 而非 O(1)，在高频写入场景下吞吐骤降；或者误以为 LinkedHashSet 迭代是“按访问顺序”，其实它是插入顺序，LRU 需要用 LinkedHashMap 并重写 removeEldestEntry()。
-
TreeSet要求元素实现Comparable或传入Comparator，null 元素在自然排序下会抛NullPointerException -
LinkedHashSet的迭代顺序稳定，但序列化后反序列化仍保持该顺序——这点比靠ArrayList+ 手动去重更可靠 - 如果只是临时去重再转回 list，用
new ArrayList(new LinkedHashSet(list))比流式list.stream().distinct().collect(...)更快，后者在小数据量下有明显函数式开销
Stream.collect(Collectors.toMap()) 的并发陷阱
用 Collectors.toMap() 转换 List 到 Map 时，若原始数据含重复 key，默认抛 IllegalStateException；加 merge 函数可解决，但并发流（.parallelStream()）下，merge 行为不可预测——多个线程可能同时尝试合并同一 key，导致结果取决于竞态时序。
真正安全的并发 map 构建方式是：先用 parallelStream().collect(Collectors.groupingByConcurrent()) 得到 ConcurrentMap，再按需转换；或者干脆用 ConcurrentHashMap + computeIfAbsent() 手动构建。
-
toMap()的 value mapper 函数若抛异常，整个 collect 会中断，不会部分成功 - key 冲突时传的
(v1, v2) -> v1看似简单，但在 parallelStream 中无法保证“先出现的胜出”，因为分段处理后合并阶段才 resolve 冲突 - 如果 value 是复杂对象且需深拷贝，别在 value mapper 里做 clone，应在收集后统一处理；否则并行流中重复 clone 浪费 CPU
集合性能优化的复杂点不在公式计算，而在理解 JVM 内存布局、CPU 缓存行为和具体 JDK 版本的实现细节——比如 Java 21 的 SequenceCollection 预览特性，或不同 GC 算法下对象分配速度对 LinkedList 节点创建的影响。这些没法靠背 API 解决。
