strictfp在现代jvm（如openjdk 11+ x64、android 5.0+）中基本无效，因jvm默认禁用x87扩展精度；它仅在旧dalvik（android 4.4及更早）、java me cdc、跨架构离线校验或jni浮点对齐等特定场景生效。
strictfp 在现代 JVM 上基本没用，除非你真在跑旧平台
结论很直接：strictfp 对 OpenJDK 11+ x64、HotSpot ART（Android 5.0+）、主流服务器环境几乎零影响——JVM 默认已禁用 x87 扩展精度寄存器，行为和加了 strictfp 一致。
它只在这些场景还“活着”：
- Android 4.4 及更早的 Dalvik 虚拟机
- 某些嵌入式 JVM（如 Java ME CDC）
- 跨 x86_32（IA32）与 ARM32 的离线计算校验（比如游戏存档哈希链）
- JNI 中调用了依赖中间精度的 C 数学库，且 Java 层需对齐其浮点行为
如果你的 build.gradle 里写着 sourceCompatibility = 17，又只部署在 Kubernetes 上的 x64 Pod 里，那加 strictfp 就是纯字节码噪音，JIT 编译器甚至可能优化掉它的语义标记。
strictfp 只管 float/double 表达式，不管 Math、BigDecimal 和常量
很多人加了 strictfp 还发现结果不一致，是因为误以为它能“统一所有浮点行为”。其实它只约束极窄的一类操作：
-
a + b * c：中间乘积必须截断为float或double精度，不能暂存在 80 位寄存器 -
(float) d、(double) f这类强制类型转换 -
%模运算（仅限浮点）
但它完全不管：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
Math.sin(x)、Math.pow(a, b)：这些是本地方法，实现由 JVM 自行决定 -
BigDecimal：压根不走 IEEE 754 浮点路径 -
0.1f + 0.2f这种字面量表达式：编译期由javac计算并折叠，和运行时strictfp无关
示例：
public strictfp class Calc {
static final double BAD = 0.1 + 0.2; // 编译期算好，值固定为 0.30000000000000004
static double good(double a, double b) { return a + b; } // 运行时才算，受 strictfp 约束
}
加在哪才真正生效？别被继承/调用链绕晕
strictfp 不会穿透调用栈。它只作用于被修饰的**直接语法上下文**：
- 修饰类 → 类内所有方法体中的
float/double表达式生效（含静态初始化块、匿名内部类） - 修饰方法 → 仅该方法体内表达式生效；若它调用了非
strictfp父类方法，父类里的浮点运算不受控 - 修饰接口 → 接口默认方法（
default）受约束，但实现类重写后需自行加strictfp
常见翻车现场：
- 父类是
strictfp，子类重写了关键计算方法却没加strictfp→ 失效 - 用
javac -target 1.2编译，但运行在 JDK 21 上 → 字节码有标志，JVM 忽略 - Gradle 配置
targetCompatibility = 11但sourceCompatibility = 8→strictfp标志可能被 javac 吞掉
真要跨平台一致？先换思路，再考虑 strictfp
与其花时间调试 strictfp 是否生效，不如问自己：这个“一致”到底是不是必须靠浮点实现？
- 金融计算 → 直接用
long（单位“分”）或BigDecimal，别碰double - 物理模拟 → 若需确定性，优先固定 timestep + 整数缩放（如
int pos = (int)(x * 1000)），比依赖strictfp更可靠 - 协议校验（如 TLS 握手中的浮点 nonce）→ 查 RFC，多数已弃用浮点，改用整数编码
strictfp 解决不了 0.1 + 0.2 != 0.3，它只保证这个“错误”在 x86、ARM、RISC-V 上一模一样。而现实中，出问题的往往不是精度差异，是有人忘了它根本不管 Math.sqrt 或 JNI 回调。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
