17370845950

HashMap统计词频最直接，但需规范字符串：清洗标点、转小写、跳过空串，用merge方法计数；排序用TreeMap，保序用LinkedHashMap；中文须分词，大文本需预设容量和流式处理。

用 HashMap 统计词频是最直接的方案，但要注意键的类型和字符串规范化

Java 中统计文本中单词出现次数，HashMap 是最常用且够用的选择。关键不是“能不能用”，而是“怎么用才不出错”。常见坑是直接对原始单词调用 split(" ") 后就塞进 map，结果大小写、标点、空格不一致导致重复计数。比如 "Hello" 和 "hello," 会被当成两个词。

实操建议：

• 先用正则 replaceAll("[^a-zA-Z0-9\\s]", " ") 清洗标点，再 trim().split("\\s+") 拆分（避免多个空格产生空字符串）
• 统一转小写：word.toLowerCase()，否则 "The" 和 "the" 算两个键
• 跳过空字符串和纯空白：if (word.isEmpty()) continue;
• 计数逻辑推荐用 map.merge(word, 1, Integer::sum)，比手动 get + put 更简洁且线程安全（单线程下也更少出错）

TreeMap 和 LinkedHashMap 什么情况下该换？

默认用 HashMap 没问题，但输出需要排序或按输入顺序时就得换。注意：这不是性能优化，而是语义需求。

选型依据：

• 要按字母序输出词频？用 TreeMap，它天然按键排序，但插入慢一点（O(log n)），且不保留原始出现顺序
• 要按单词首次出现顺序排列？用 LinkedHashMap，它保持插入序，遍历时顺序可预测；但需自己控制插入逻辑（比如首次遇到才 put）
• 如果只是最终排序一次再打印，别提前换 TreeMap —— 先用 HashMap 统计完，再转 List> + Collections.sort() 更灵活

中文文本统计不能直接套英文逻辑

中文没有空格分词，split(" ") 会整个字符串当一个词。必须引入分词环节，否则统计毫无意义。

轻量级方案（适合简单场景）：

• 用开源库如 hanlp 或 ik-analyzer，例如：

  Segment segment = HanLP.newSegment().enableNameRecognize(true);  
  List termList = segment.seg(text);  
  for (Term term : termList) {  
      String word = term.word.trim();  
      if (!word.isEmpty()) map.merge(word, 1, Integer::sum);  
  }

• 不用第三方？至少做基础切分：按字符统计（text.chars().mapToObj(c -> String.valueOf((char)c))），适用于字频分析，但无法识别“人工智能”这种词
• 注意编码：确保读取文件时指定 StandardCharsets.UTF_8，否则中文变乱码，HashMap 里存的全是错误键

大文本下 HashMap 的内存和性能临界点在哪？

几 MB 的文本没问题，但百 MB 以上或词表超 50 万项时，HashMap 默认初始容量（16）和负载因子（0.75）会导致频繁扩容，GC 压力明显。

可提前干预：

• 预估词数：若知道文本约有 10 万个不同词，初始化时写 new HashMap(131072)（2 的幂，略大于 10w / 0.75）
• 避免装箱开销：高频场景考虑用 IntObjectHashMap（来自 fastutil 库），key 还是 String，但 value 用原生 int，省去 Integer 对象创建
• 流式处理：不要一次性 readAllBytes 加载全文，改用 BufferedReader.readLine() 分行处理，边读边统计，内存可控

真正卡住的往往不是 Map 本身，而是没意识到中文分词或文件编码这些前置环节已经让统计结果失真了。