strictfp确保float/double在不同平台运算结果完全一致，而非提升精度；它约束算术运算、类型转换和常量表达式，适用于金融清算、科学仿真等需结果可复现的场景。
strictfp 是用来解决跨平台浮点结果不一致的
它不是让 float/double 更“精确”，而是让它们在不同 CPU（比如 Intel x87 vs ARM）和 JVM 实现上算出**完全相同的结果**。早期 JVM 允许中间计算使用 80 位扩展精度（x87 寄存器），导致同一段 1.0 / 3.0 在 Windows 和 Linux 上可能有细微差异——strictfp 就是为堵住这个口子而生的。
- 只对
float和double的算术运算、类型转换、常量表达式生效，不影响BigDecimal或整数 - 修饰类时，该类所有方法、静态初始化块、字段初始值表达式都自动受约束
- 修饰方法时，仅限该方法体内的浮点表达式；构造器、lambda、匿名类内部不继承父类的
strictfp - 接口用
strictfp修饰后，所有默认方法和静态方法也强制 FP-strict，但抽象方法声明本身不参与运算，所以不生效
哪些场景真需要 strictfp？别乱加
绝大多数业务代码根本不需要它。加了反而可能拖慢性能，还容易让人误以为“用了就更准”——其实它只是“更稳”，不是“更准”。
- 必须用：金融清算系统（多节点并行跑相同浮点逻辑）、科学仿真（结果需可复现）、游戏物理引擎（跨平台联机同步帧状态）
- 不用也行：Web 后端接口计算、Android UI 布局尺寸、日志中的耗时统计——这些对微小误差不敏感
-
替代方案更常见：钱相关的用
BigDecimal，图形渲染用float+ 约定舍入模式，比strictfp更直接可控
strictfp 性能影响小，但编译期就锁死了行为
现代 JVM（HotSpot 8u292+）对 strictfp 的优化已很成熟，实测开销通常低于 1%，但关键在于：它把浮点语义固化在 class 文件里，运行时无法绕过。
- 一旦类被标记
strictfp，哪怕你只在某个方法里做整数运算，整个类加载后所有浮点路径都会走 IEEE 754 标准舍入流程 - 某些 JIT 优化（如常量折叠、向量化）可能被禁用，尤其涉及
double连续累加时 - Android Dalvik/ART 对
strictfp支持完整，但旧版 ART（5.0 以下）曾忽略方法级strictfp，只认类级
常见误区：strictfp ≠ 防止浮点误差
很多人看到 0.1f + 0.2f != 0.3f 就想加 strictfp，这是错的——这个等式在任何平台、加不加 strictfp 都为 false，因为二进制无法精确表示十进制小数。它管的是“一致性”，不是“正确性”。
- 错误写法：
strictfp void calc() { return 0.1f + 0.2f; }→ 结果仍是0.30000001，只是所有平台都返回这个值 - 正确预期：
float a = 1e20f; float b = 1.0f; System.out.println(a + b == a);在非 strictfp 下可能返回false（x87 扩展精度保留低位），加了strictfp后所有平台都返回true - 调试技巧：用
javap -c查看字节码，含strictfp的方法会在方法属性中带AccStrict标志
严格浮点的核心价值不在“算得对”，而在“算得一样”。如果你没在多个异构硬件上部署过同一套数值逻辑，大概率还没到需要它的阶段。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
