该用Set而非List当需自动去重且不关心顺序或索引；HashSet平均O(1)、LinkedHashSet保插入序、TreeSet支持排序但O(log n)，注意null限制。
什么时候该用 Set 而不是 List
当你需要自动去重、且不关心元素顺序或索引访问时，Set 是更合适的选择。比如读取一批用户 ID 并统计唯一数量，用 List 后手动去重不仅慢（O(n²)），还容易漏掉边界情况。
-
HashSet最常用：底层是哈希表，插入/查找平均O(1)，但不保证顺序 -
LinkedHashSet适合需要按插入顺序遍历的场景，比如最近访问的资源缓存 -
TreeSet用于需要自然排序或自定义排序的集合，比如排行榜分数去重后升序展示，但增删查是O(log n)
注意：Set 不能存 null（TreeSet 直接抛 NullPointerException；HashSet 允许一个 null，但要小心后续比较逻辑）
Map 的键为什么必须是不可变对象
因为 Map（尤其是 HashMap）依赖键的 hashCode() 和 equals() 定位和比较元素。如果键对象在放入后被修改，导致 hashCode() 变化，就再也找不到它了——不是丢失，是“藏起来了”。
- 常见踩坑：用可变的
StringBuilder或自定义类作键，没重写hashCode()和equals()，或重写了但字段参与计算后又被改 - 安全做法：优先用
String、Integer等不可变类型；若必须用自定义类，确保所有参与hashCode()/equals()的字段在构造后不可变
例如：
Map<String, Integer> userScore = new HashMap<>();
userScore.put("alice", 95);
// 后续用 "alice" 能稳定取到，因为 String 不可变
Set 和 Map 在实际业务中怎么配合用
很多场景下二者不是二选一，而是协同：用 Map 存主数据 + 关联关系，用 Set 做快速存在性判断或去重中间结果。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 权限校验：把用户拥有的角色 ID 存进
HashSet<String>，检查是否包含某个角色时用roles.contains("ADMIN")，比遍历List快得多 - 批量更新防重：从消息队列收到一批订单 ID，先塞进
Set<Long>去重，再查Map<Long, Order>批量加载已有订单，避免重复 DB 查询 - 配置白名单：把合法的 API 路径存在
Set<String>，拦截器里直接判断if (!allowedPaths.contains(path)) reject();
性能关键点：别为了“看起来统一”而强行把 Map<K, Boolean> 当 Set 用——语义不清，内存浪费，还可能因 null 值引发误判。
并发环境下选哪个实现
单线程用 HashSet/HashMap 没问题，但多线程写入必须换线程安全版本，否则会出错或死循环（JDK 7 的 HashMap 扩容时可能形成环形链表）。
- 简单读多写少：用
Collections.synchronizedSet()/synchronizedMap()，但锁粒度大，吞吐低 - 高并发读写：优先选
ConcurrentHashMap；它没有ConcurrentHashSet，但可用ConcurrentHashMap.newKeySet()（JDK 8+）替代 - 注意：
ConcurrentHashMap的size()不是精确值（为避免锁竞争而妥协），需精确计数建议用LongAdder单独维护
最容易被忽略的是：即使用了 ConcurrentHashMap，复合操作如“检查不存在再 put”仍需 computeIfAbsent() 或 putIfAbsent()，否则仍有竞态。
