Java字符串统计核心是根据目标选数据结构和处理策略：需用codePoints()处理Unicode（含emoji），正则匹配而非split分词，注意大小写/全半角转换规则，性能优化可选fastutil或数组，关键先明确统计单位。
Java 中实现字符串统计程序，核心不是“写个循环遍历”，而是根据统计目标选择合适的数据结构和边界处理策略。用错容器或忽略 Unicode、空格、大小写等细节，结果会明显偏差。
统计每个字符出现次数（含中文、emoji）
不能直接用 char 数组遍历，因为 Java 的 char 是 UTF-16 单元，无法正确表示增补字符（如大部分 emoji 和部分汉字）。必须用 String.codePoints() 或 String.codePointCount() 处理。
- 推荐用
Map<integer integer></integer>存储 Unicode 码点 → 出现次数，避免Character自动拆分代理对 - 调用
str.codePoints().forEach(...)比手动for (int i = 0; i 更安全 - 若只需 ASCII 字符统计，可用
char[]+int[128]数组，性能更高但不通用
String s = "hello世界?";
Map<Integer, Integer> freq = new HashMap<>();
s.codePoints().forEach(cp -> freq.merge(cp, 1, Integer::sum));
// 结果：{104=1, 101=1, 108=2, 111=1, 19990=1, 30028=1, 128640=1}
统计单词频次（按空格/标点切分）
用 String.split() 直接按空格切分不可靠：连续空格、首尾空格、制表符、换行符、中英文标点都会导致错误分词。应优先用正则匹配单词，而非切割。
- 正则建议用
"\b\w+\b"（支持下划线），或更严格的"[a-zA-Zu4e00-u9fa5]+(?![-'])"（中英文单词，排除连字符孤立情况） - 注意
split(" ")不等于split("\s+")；后者才真正处理所有空白符 - 统一转小写再统计，否则
"Hello"和"HELLO"被算作不同单词
String text = "Hello world! 你好 world...";
Pattern wordPattern = Pattern.compile("[a-zA-Z\u4e00-\u9fa5]+");
Matcher m = wordPattern.matcher(text.toLowerCase());
Map<String, Integer> wordFreq = new HashMap<>();
while (m.find()) {
String word = m.group();
wordFreq.merge(word, 1, Integer::sum);
}
区分大小写、忽略大小写、全角半角的处理影响
统计结果是否符合业务预期，往往取决于这三项开关的组合。它们不是可选优化，而是定义问题本身的关键参数。
立即学习“Java免费学习笔记（深入）”；
-
String.toLowerCase()对部分语言（如土耳其语）有 locale 敏感行为，如需国际化，应显式传Locale.ENGLISH - 全角 ASCII 字符（如全角 A：
'Ａ'，U+FF21）与半角'A'（U+0041）是不同码点，toLowerCase()不会互相转换 - 若需统一全半角，需自定义映射表或使用
Normalizer.normalize(str, Form.NFKC)（注意 NFKC 可能改变语义，慎用于用户输入）
性能敏感场景下的替代方案
当字符串超长（>1MB）或高频调用（如日志实时分析），HashMap 和正则引擎会成为瓶颈。此时应考虑：
- 用
Int2IntOpenHashMap（来自 fastutil 库）替代HashMap<integer integer></integer>，减少装箱开销 - 避免每次调用都编译正则：将
Pattern.compile(...)提取为static final字段 - 纯 ASCII 字符串统计，用
int[256]数组代替 Map，索引即(int) ch，速度提升 3–5 倍 - 流式处理大文本时，不要一次性
readAllBytes()，改用BufferedReader+ 行缓冲 + 状态机分词
真正难的不是“怎么数”，而是明确“要数什么”——是字节、Unicode 码点、Grapheme Cluster（用户感知的字符）、还是逻辑单词？没想清这点，代码越“健壮”越容易偏离需求。
