1. 问题现象：当数字遇上StreamTokenizer
第一次遇到StreamTokenizer的精度丢失问题时，我正在处理一个包含经纬度坐标的文本文件。当读取"121.492336"这个经度值时，程序输出的结果却变成了"121.4923"，最后两位小数莫名其妙消失了。这种精度丢失在金融计算、科学实验等场景简直是灾难——想象一下导航系统因为经度精度丢失而偏移几百米，或者证券交易系统因金额截断产生巨额亏损。
StreamTokenizer作为Java标准库中的元老级工具（自JDK1.0就存在），其设计初衷是解析编程语言源代码。它通过nextToken()方法返回的nval字段（double类型）来存储数字值，这就埋下了精度丢失的隐患。以下是典型的问题代码片段：
java复制StreamTokenizer tokenizer = new StreamTokenizer(new StringReader("121.492336"));
tokenizer.nextToken();
System.out.println(tokenizer.nval); // 输出：121.4923
2. 精度丢失的根源解剖
2.1 二进制浮点数的先天缺陷
Java的double类型采用IEEE 754标准的64位浮点数表示，这种设计本质上就会导致精度问题。例如十进制的0.1在二进制中是无限循环小数（0.0001100110011...），存储时必须截断。StreamTokenizer内部使用Double.parseDouble()进行字符串转换，这个过程会引入第一次精度损失。
更隐蔽的是StreamTokenizer自己的实现问题。查看OpenJDK源码会发现，它在处理数字时使用了以下逻辑：
java复制// 简化后的JDK源码逻辑
if (isDecimal) {
nval = Double.parseDouble(sb.toString());
} else {
nval = Integer.parseInt(sb.toString(), 10);
}
2.2 默认配置的陷阱
StreamTokenizer有三个关键参数会加剧精度问题：
ordinaryChar(int ch)：将字符标记为"普通字符"，导致该字符不会参与数字解析wordChars(int low, int hi)：设置字符范围作为单词组成部分parseNumbers()：启用数字解析（默认开启）
特别是当输入文本中包含科学计数法（如1.23E-4）时，如果错误配置了'E'或'e'的字符类型，会导致整个数字解析失败。
3. 解决方案：四步根治精度丢失
3.1 方案一：绕过nval直接获取原始字符串
java复制// 自定义解析逻辑
StringBuilder numBuilder = new StringBuilder();
while (Character.isDigit((char)tokenizer.ttype) ||
(char)tokenizer.ttype == '.' ||
(char)tokenizer.ttype == '-') {
numBuilder.append((char)tokenizer.ttype);
tokenizer.nextToken();
}
BigDecimal preciseValue = new BigDecimal(numBuilder.toString());
关键技巧：通过ttype字段逐字符读取数字部分，再用BigDecimal精确处理。实测处理"123456789.987654321"时可保持完整精度。
3.2 方案二：修改词法分析器配置
java复制// 保护科学计数法中的'e'字符
tokenizer.wordChars('e', 'e');
tokenizer.wordChars('E', 'E');
// 确保小数点不被当作普通字符
tokenizer.ordinaryChar('.');
tokenizer.parseNumbers();
3.3 方案三：换用更现代的解析工具
对于新项目，建议使用这些替代方案：
| 工具 | 精度处理 | 适用场景 | 性能对比 |
|---|---|---|---|
| Scanner | 依赖nextBigDecimal() | 简单文本 | 较慢 |
| DecimalFormat | 可配置舍入模式 | 格式化文本 | 中等 |
| Jackson | 支持任意精度 | JSON处理 | 快 |
| ANTLR | 完全可控 | 复杂语法 | 慢 |
3.4 方案四：预处理输入文本
在文本输入流和StreamTokenizer之间插入过滤器：
java复制public class PrecisionFilter extends FilterReader {
@Override
public int read(char[] cbuf, int off, int len) {
// 实现数字部分的特殊处理
}
}
4. 实战中的深度避坑指南
4.1 边界条件测试清单
必须测试这些特殊场景：
- 超长小数（如圆周率后20位）
- 科学计数法（1.23E+10）
- 正负零（+0 vs -0）
- 边界值（Double.MAX_VALUE）
- 非标准格式（如",123.45"）
4.2 性能与精度的平衡
在需要处理海量数据的场景，可以实施分级策略：
- 先用StreamTokenizer快速扫描定位数字位置
- 对关键数值（如金额、坐标）启用精确模式
- 对非关键数值（如序号）使用默认解析
4.3 日志监控建议
在关键业务系统中添加精度监控：
java复制if (originalValue.scale() > preciseValue.scale()) {
LOG.warn("Precision loss detected: {} -> {}",
originalValue, preciseValue);
}
5. 从原理到实践：精度问题的本质
精度问题本质上是文本解析领域的三重挑战：
- 字符集问题：数字在不同语言环境下的表示差异（如1,234.56 vs 1.234,56）
- 类型转换问题：字符串→中间表示→目标类型的转换损耗
- 业务语义问题：同一数字在不同业务场景的精度要求不同
在金融领域，我见过最极端的案例是利率计算需要保留18位小数。这时必须放弃StreamTokenizer，改用自定义的确定性解析算法。一个经验法则是：当精度要求超过double的15-17位有效数字时，任何基于浮点数的方案都是不可靠的。