正则split与循环法统计单词数的性能差异及底层原因解析

两种写法虽然大O时间复杂度同为O(n)，但实际运行的常数项开销差距可达几十上百倍，性能差异完全由底层实现逻辑决定，核心原因有三个：

• 正则引擎的固有启动成本
  你调用的split("\\s")触发不了Java中split方法的单字符快速分割优化——只有传入的分割参数是长度为1的普通字符、不属于正则特殊符号时，split才会跳过正则引擎直接执行简单逐字符匹配。\\s是正则中用于匹配空白的元字符，每次调用都要先走完正则表达式编译、匹配状态机构建的全套流程，仅这部分固定开销就高于遍历计数全流程的成本。
  就算进入正式匹配阶段，正则匹配是基于状态机跳转实现的，每匹配一个字符需要经过的判断分支远多于直接写ch == ' '的相等比较，单步操作的开销本身就高一大截。
• split方法自带的额外内存分配开销
  split的设计目标是返回切分完成后的完整字符串数组，执行过程中除了查找分割点位置，还要完成分割点临时数组的动态扩容、每个切分单词的String对象创建、对应位置字符内容拷贝、最终结果数组缩容等一系列操作，会生成大量临时对象，甚至可能触发Minor GC。
  反观你写的遍历实现，全程只维护一个int类型的计数器，不需要创建任何额外对象、不需要分配数组内存，这部分开销直接降为0。
• JVM对简单遍历逻辑的深度优化
  你可能担心toCharArray()会带来额外的遍历拷贝开销，实际上这个方法是JVM内置的intrinsic优化方法，底层直接通过内存批量拷贝完成字符数组生成，并非逐字符复制，执行开销低到几乎可以忽略。而且整个遍历逻辑是顺序内存访问、判断条件极其固定，CPU分支预测成功率接近100%，执行指令和相关数据完全可以加载到L1缓存中运行，几乎没有访存延迟。

提示：你当前写的遍历计数逻辑存在漏洞，默认输入不存在首尾空格、单词之间仅间隔单个空格，如果遇到" hello world "这类带连续空格、首尾空格的输入，统计结果会出错，实际场景使用需要补充跳过连续空格、裁剪首尾空白的处理逻辑。

内容的提问来源于stack exchange，提问作者IshAsh