Java集合选型需匹配访问模式：ArrayList适合随机查ID和顺序遍历，LinkedList仅适用于频繁首尾增删；HashMap查ID必须重写equals/hashCode；多线程应选ConcurrentHashMap或CopyOnWriteArrayList；避免for-each中remove及O(n)contains。
Java集合框架不是万能容器，选错类型或误用方法会导致数据不一致、性能骤降甚至并发异常——关键不在“能不能存”，而在“该用哪个存、怎么存才安全高效”。
ArrayList 还是 LinkedList？看操作模式再决定
用户数据通常按插入顺序遍历或随机查ID，ArrayList 是默认首选；只有频繁在列表头部增删（比如消息队列回滚场景），才考虑 LinkedList。
-
ArrayList的get(int index)是 O(1)，但remove(int index)平均要移动后续元素，O(n) -
LinkedList的addFirst()和removeLast()是 O(1)，但get(int index)需遍历，O(n) - 别只看“链表适合增删”的笼统说法——用户列表极少在中间插入，更常见的是批量查、单点删ID，
ArrayList实际更稳
HashMap 存用户ID→User，但别忘了重写 equals 和 hashCode
用 HashMap 按ID快速查用户没问题，但如果 User 类没重写 equals() 和 hashCode()，哪怕两个对象字段完全相同，map.get("u1001") 也可能返回 null。
- IDE 自动生成的
equals()和hashCode()要确保覆盖所有业务判等字段（如userId，而非name或email） - 若用 Lombok，确认加了
@EqualsAndHashCode(of = "userId")，而不是默认全字段参与 - 测试时故意 new 两个相同ID的
User，验证map.containsKey()和map.get()行为是否符合预期
多线程修改用户列表？别直接用 ArrayList 或 HashMap
多个线程同时调用 list.add() 或 map.put()，即使加了同步块，也掩盖不了底层非线程安全的事实——可能抛 ConcurrentModificationException，或静默丢失数据。
立即学习“Java免费学习笔记（深入）”；
- 读多写少：用
Collections.synchronizedList(new ArrayList())，但注意迭代时仍需手动同步 - 写操作频繁：改用
CopyOnWriteArrayList（适合读远多于写的用户在线状态列表） - 高并发键值存取：优先选
ConcurrentHashMap，它比synchronizedMap锁粒度细，吞吐更高 - 切忌在 for-each 循环里调用
remove()—— 无论单线程还是多线程，都该用Iterator.remove()或removeIf()
用户数据量大时，避免用 contains() 做存在性判断
对 ArrayList 调用 list.contains(user) 是 O(n) 全扫描；若只是查ID是否存在，应提前建好 HashSet 或用 HashMap 的 keySet 视图。
-
userList.stream().anyMatch(u -> u.getId().equals("u1001"))看似简洁，实则每次都是 O(n) - 正确做法：维护一个
Set，查存在性用userIdSet = userMap.keySet() userIdSet.contains("u1001")，O(1) - 如果用户数据来自数据库，且 ID 查询高频，干脆别全加载进内存——用 DAO 层按需查，比在集合里筛更可靠
集合类型选型不是凭印象，而是看访问模式；线程安全不是加个 synchronized 就完事；而“查得快”的前提，永远是结构匹配查询意图——这些细节不抠清楚，用户数据一上量，问题就藏不住了。
