StringTokenizer并非内存更优方案：它无对象复用、不支持limit控制、无法流式消费，且JDK 7u6后每个nextToken()均创建新String；split()经JVM优化更高效，推荐用splitAsStream或手写indexOf循环。
Java 中 StringTokenizer 并不具有内存优势，在处理超长文本切分时，它既不比 split() 更省内存，也不更高效——相反，它在现代 JVM 和实际工程中已被明确淘汰。
StringTokenizer 没有真实内存优势的原因
-
无对象复用机制：每次创建
StringTokenizer都会新建实例，内部维护String引用、位置索引和分隔符数组，但不缓存中间结果，也不复用状态。而split()返回的字符串数组虽是新分配的，但现代 JVM 对短生命周期小数组做了大量优化（如栈上分配、逃逸分析）。 -
无法跳过字段或流式消费：
StringTokenizer必须逐个调用nextToken()，但所有 token 本质仍是原字符串的子串（JDK 7u6 之后已取消substring的底层数组共享，每个nextToken()都触发new String(value, offset, count)），内存开销并不低。 -
不支持 limit 控制输出规模：
split(regex, limit)可以限制最多生成limit个结果，提前终止匹配，这对超长文本（如日志行含数千字段）能显著减少内存占用；StringTokenizer没有类似能力，必须遍历全部 token 才知道总数。
真正影响内存的关键点
-
split("")或split(".")等误用正则，会因引擎回溯产生临时状态对象，导致堆内存激增——但这属于用法错误，不是split本身缺陷。 -
StringTokenizer对连续分隔符（如"a,,b"）直接跳过空字段，看似“省了”，实则是语义丢失：你本想保留结构信息，它却静默丢弃，后续逻辑可能因字段错位崩溃，反而引发更大内存/调试成本。 - 超长文本切分的合理内存策略是流式处理，例如：
-
Pattern.compile(delimiter).splitAsStream(text)（Java 8+）——返回Stream<String>，按需生成，不全量加载； - 自定义
Reader+ 边读边分词（如解析 GB 级 CSV）； - 使用
CharBuffer配合手动扫描，避免创建中间字符串。
-
如果你真在超长文本场景卡内存，该怎么做？
- ✅ 优先用
Pattern.compile(delimiter).splitAsStream(text)，配合forEach或limit(n)； - ✅ 对固定单字符分隔符（如逗号），且确定无转义需求，可手写基于
indexOf的轻量循环，复用StringBuilder； - ✅ 避免
StringTokenizer：它不支持 Unicode 补充字符（如 emoji）、无法处理\u0000、不能指定忽略空白、也不能跳过前导/尾随分隔符； - ❌ 不要为了“看起来轻量”而选
StringTokenizer——它的“轻”是假象，源码里仍有new StringTokenizer()、new String()、hasMoreTokens()的字段访问开销，且 JDK 从未对其做 JIT 内联优化。
StringTokenizer 是 Java 1.0 的产物，它的存在只为兼容 20 年前的代码。今天任何新项目里为“内存”或“性能”选择它，都是对问题本质的误判。
