多线程投票场景必须用ConcurrentHashMap，因其支持原子操作如compute避免计数丢失；防重复投票宜用putIfAbsent+扁平key；导出需显式排序，不可依赖entrySet遍历顺序。
投票数据用 HashMap 还是 ConcurrentHashMap？
单线程命令行小工具用 HashMap 完全够用；但只要涉及多用户并发提交（比如 Web 接口或模拟多线程测试），必须换 ConcurrentHashMap，否则会出现计数丢失——put 和 get 非原子，两个线程同时对同一选项执行 map.put(opt, map.get(opt) + 1)，很可能只加了 1 次而不是 2 次。
实操建议：
- 初始化时直接声明为
ConcurrentHashMap，别用 HashMap 后期强转
- 避免手写
get + put 组合，改用 compute 或 merge 方法保证原子性
- 如果只是读多写少，且能接受最终一致性（如后台统计看板），
ConcurrentHashMap 的分段锁已足够，不用上 ReentrantLock
compute 方法怎么安全累加投票数？
手动 get 再 put 是并发 bug 温床。compute 把“读-改-写”封装成一个原子操作，传入 key 和一个 BiFunction 即可。
Map votes = new ConcurrentHashMap<>();
// 初始化选项
votes.put("Java", 0);
votes.put("Python", 0);
votes.put("Go", 0);
// 用户投 Java 一票
votes.compute("Java", (key, oldValue) -> oldValue == null ? 1 : oldValue + 1);
注意点：
-
oldValue 可能为 null（首次投票），必须判空，不能直接 +1
- 函数体里不要做耗时操作（如 DB 查询、HTTP 调用），会阻塞该 key 对应的 hash 段
- 如果只想在 key 存在时更新，用
computeIfPresent；如果只在不存在时插入，默认值用 computeIfAbsent
如何防止重复投票？用 Set 记录已投用户 ID
仅靠 Map 存票数无法识别刷票。需要额外结构记录“谁投过什么”，常见做法是用 ConcurrentHashMap>：外层 key 是选项名，内层 Set 存用户 ID（如学号、手机号哈希）。
但更省内存且线程安全的做法是用 Con
currentHashMap 做全局去重：userId + "_" + optionName 当 key，值固定为 Boolean.TRUE，利用 putIfAbsent 的返回值判断是否首次提交：
ConcurrentHashMap votedRecords = new ConcurrentHashMap<>();
String voteKey = "2023001_Java";
if (votedRecords.putIfAbsent(voteKey, Boolean.TRUE) == null) {
// 真正投票逻辑
votes.compute("Java", (k, v) -> v == null ? 1 : v + 1);
} else {
System.out.println("重复投票：2025001 已投过 Java");
}
关键细节：
- 拼接 key 时用下划线而非冒号或点，避免解析歧义
- 不依赖
Set 的 add 返回值做判断，因为 ConcurrentHashMap 的 putIfAbsent 更轻量、无扩容风险
- 若需查某用户所有投票记录，这种扁平 key 设计反而比嵌套
Map> 更易遍历
导出结果时为什么 entrySet() 遍历顺序不稳定？
ConcurrentHashMap 不保证遍历顺序，每次运行输出可能不同。如果要求按得票从高到低排序展示，不能依赖 map 自身顺序，必须显式排序。
正确做法是把 entrySet() 转成 List 后用 sort：
List> sorted = new ArrayList<>(votes.entrySet());
sorted.sort((e1, e2) -> e2.getValue().compareTo(e1.getValue()));
for (Map.Entry entry : sorted) {
System.out.printf("%s: %d 票%n", entry.getKey(), entry.getValue());
}
注意事项：
- 别在遍历
ConcurrentHashMap 时调用 remove 或 put，虽不抛异常，但结果不可预测
- 如果只是临时排序展示，用
Stream.sorted 更简洁，但要注意 parallelStream 在小数据集上反而慢
- 线上系统若频繁导出，建议把排序逻辑抽成方法，并加
@Override 注释说明“此排序不改变原 map 结构”
实际跑起来你会发现，最难的不是存数据，而是定义清楚“谁算合法用户”“ID 怎么生成”“网络超时后要不要回滚本地计数”——这些边界问题不会在
HashMap 文档里写，但决定系统能不能用。
