strictfp不提升数学精度，而是确保float和double运算在所有平台结果完全一致；它强制每步按IEEE-754的32/64位精度立即舍入，解决跨平台可重现性问题，而非精度问题。

strictfp 不提升数学精度，而是锁定计算路径，让 float 和 double 运算在所有平台（x86、ARM、不同 JVM 实现）上产出完全一致的结果。

它解决的是“可重现性”，不是“更准”

现代 CPU（如 Intel x87）曾用 80 位寄存器暂存中间结果，导致 a * b + c 在不同机器上因截断时机不同而微异。strictfp 强制每一步都按 IEEE-754 规定的 32 位或 64 位精度立即舍入，不借力硬件扩展精度。这意味着：

• 0.1f + 0.2f 在任何平台都得到相同的二进制表示（比如 0.30000001192092896），而不是有时略大、有时略小
• 金融对账、多人联机游戏物理同步、离线哈希链等场景，不再因平台差异出现“本该一致却漂移”的问题
• 它不修复 0.1 + 0.2 != 0.3 的固有误差，只是确保这个误差在所有目标环境里一模一样

它只约束哪些运算？边界很明确

strictfp 仅作用于源码中直接写的 float/double 算术表达式（+、-、*、/、%、类型转换），其余一律不管：

• 不碰 Math 类方法：Math.sin、Math.pow 等由 JVM 自行实现，strictfp 无效
• 不碰 BigDecimal：它走十进制路径，与 IEEE-754 无关
• 不碰 JNI 或硬件指令直译：这些绕过 Java 字节码规范
• 不干预编译期常量折叠：static final double X = 0.1 + 0.2; 的值由 javac 决定，运行时 strictfp 不起作用

怎么加才真正生效？位置决定范围

strictfp 是语法级标记，不穿透调用栈，只约束被修饰结构的直接上下文：

• 修饰类：strictfp class Calculator { ... } → 类内所有方法体、静态块、字段初始化表达式中的浮点运算均受控
• 修饰方法：strictfp double compute(double a, double b) { return a * b + 0.1; } → 仅该方法体内表达式生效；若它调用父类非 strictfp 方法，父类里的浮点运算不受影响
• 修饰接口：strictfp interface MathOps { default double avg(float x, float y) { return (x + y) / 2f; } } → 接口默认/静态方法受约束，但实现类重写时需自行加 strictfp
• 禁止写法：不能修饰变量、构造器、局部变量、lambda 表达式或代码块

现在还用得着吗？看你的运行环境

在绝大多数现代场景中，strictfp 已无实际效果，但仍有少数情况必须保留：

• 目标平台含旧 ARM 设备、Android 4.4 以前 Dalvik、或某些嵌入式 JVM：它们对 strictfp 有真实响应
• 服务端（x64 OpenJDK 11+）与边缘设备（ARM32 或定制 JVM）协同计算：必须统一中间结果
• 单元测试断言浮点输出，且 CI 流水线跑在混合架构机器上（如 x86 开发机 + ARM 测试节点）
• 对接遗留 C 协议，其参考实现严格按 IEEE-754 步骤计算，Java 端必须逐位对齐
• 不要为“听起来更精确”而全局启用——它无法替代 BigDecimal 做金额运算，也掩盖不了建模缺陷