strictfp 是确保浮点运算跨平台结果一致的关键机制，它强制使用 ieee-754 标准精度（32/64 位），禁用硬件扩展精度，解决可重现性而非精度问题。
strictfp 是干啥的？不是“更准”，而是“更一致”
strictfp 不是让浮点数算得更精确，而是让 float 和 double 运算在所有平台（x86、ARM、不同 JVM 实现）上给出**完全相同的结果**。它禁用硬件可能提供的扩展中间精度（比如 x87 FPU 的 80 位寄存器），强制全程只用 IEEE-754 规定的 32 位或 64 位精度做每一步计算。
常见错误现象：
— 同一段金融计算代码，在开发机（Intel CPU）和生产服务器（ARM64）上跑出微小差异，导致对账不平；
— 多人联机游戏里，客户端和服务端因浮点结果不一致，出现位置漂移或判定分歧。
- 它解决的是「可重现性」问题，不是「数学精度」问题
- 没加
strictfp时，JVM 可能借力 CPU 的高精度寄存器加速，但牺牲了确定性 - 加了之后，所有中间结果都截断/舍入到标准格式，结果可跨平台复现
什么时候必须用 strictfp？别乱加
绝大多数业务代码根本不需要 strictfp。它只在「结果一致性比性能更重要」的场景下才有意义。
- 分布式协同计算：比如服务端 + 多个边缘设备共同参与物理模拟，要求每一步浮点结果完全一致
- 金融风控规则引擎：某些基于浮点阈值的实时拦截逻辑，不能因平台差异漏判或误判
- 遗留系统对接：老协议规定了某段 C 代码的 IEEE-754 计算路径，Java 端必须严格对齐
- 测试断言：单元测试里用
assertEquals(expected, actual)断言浮点结果，又想在 CI 的不同机器上稳定通过
别因为“听说它更精确”就给整个类加 strictfp——这是典型误用。现代 JVM（如 HotSpot 17+）在多数场景下默认行为已足够收敛，盲目启用反而可能掩盖真实的数据建模问题。
立即学习“Java免费学习笔记（深入）”；
怎么写？语法限制很具体
strictfp 只能修饰类、接口、方法，不能修饰变量、构造器、局部变量或 lambda 表达式。
- 修饰类：
strictfp class Calculator { ... }→ 类内所有方法、静态块、字段初始化表达式都受约束 - 修饰方法：
strictfp double compute(double a, double b) { return a * b + 0.1; }→ 仅该方法体内的浮点表达式生效 - 接口也可以：
strictfp interface MathOps { double sqrt(double x); }→ 接口内所有默认/静态方法的浮点运算受约束 - 禁止写法：
public strictfp Calculator() { ... }（构造器不行）、strictfp double x = 1.0;（变量声明不行）
性能和兼容性影响：小但真实存在
启用 strictfp 后，JVM 无法利用 CPU 的扩展精度寄存器优化，部分密集浮点运算（如向量计算、图形渲染）可能慢 5%–15%，尤其在旧版 x86 JVM 上更明显。
- HotSpot 从 JDK 9 起对
strictfp做了较多优化，ARM64 平台影响几乎可忽略 - Android ART 运行时默认不支持
strictfp（会静默忽略），所以 Android 项目慎用 - 如果方法里混用
Math.sin()等本地方法，它们本身不受strictfp约束——这些调用仍由底层 libc 或数学库实现，结果未必严格 IEEE-754
真正容易被忽略的一点：strictfp 不影响常量折叠。像 double x = 0.1 + 0.2; 这种编译期就能算的表达式，无论有没有 strictfp，结果都是 0.30000000000000004 —— 因为它是编译器按 IEEE-754 算的，跟运行时无关。
