Java 17及JEP 306发布后，Math与StrictMath仍存在差异吗？

1. java.lang.Math与StrictMath的方法是否完全一致？ #

JEP 306确实将Java浮点运算默认改为严格遵循IEEE 754语义，并废弃了strictfp关键字，但这不代表JVM不能用固有方法替换Math的方法——只是这些固有方法必须保证运算结果和StrictMath的对应方法完全一致。

简单来说：Math的方法现在的语义和StrictMath完全对齐，JVM可以用优化的固有实现，但必须严格复现StrictMath的结果，不能再像以前那样允许平台相关的近似值。

2. 跨架构浮点运算结果是否绝对无差异？ #

理论上，严格遵循IEEE 754规范的浮点运算跨平台结果应该完全一致，但实际中仍可能出现差异，常见原因包括：

• NaN的位模式差异：IEEE 754允许NaN有不同的位表示（只要符号位和指数位符合NaN规则），如果代码直接比较浮点值的二进制位（而非用Double.isNaN()这类逻辑判断），会看到不同平台的NaN存在位差异，但逻辑上它们都是NaN。
• JVM实现兼容性问题：部分早期Java 17版本的JVM可能在某些平台上未完全适配JEP 306要求，导致固有方法的实现未严格对齐StrictMath的结果。
• 第三方库或JNI调用：如果代码使用了第三方库，或通过JNI调用了平台原生浮点函数，这些代码可能绕过Java的严格浮点语义，引发跨平台差异。
• 边缘场景的运算偏差：极少数极端数值场景下，部分CPU的IEEE 754严格模式实现可能存在细微偏差（属于硬件或JVM实现的bug）。

针对Apple Silicon与Intel平台差异的排查建议 #

• 先定位差异出现的场景：是Math/StrictMath的方法，还是自定义浮点运算？如果是前者，建议升级到最新Java 17版本，或确认JVM实现是否完全支持JEP 306。
• 检查代码是否直接比较浮点值的二进制位，而非使用逻辑判断（比如用Double.compare()代替直接==，用Double.isNaN()判断NaN）。
• 排查是否有第三方库或JNI调用引入了平台相关的浮点逻辑。

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