strictfp仅强制float/double算术运算遵循IEEE 754精度规则，不影响Math类、BigDecimal、JNI等；现代HotSpot x64下基本无作用，仅旧平台或跨架构确定性计算（如游戏物理、金融校验）需谨慎使用。
strictfp 不是浮点计算的“开关”，它只是让 JVM 在字节码层面强制使用 IEEE 754 单/双精度规则，不启用扩展精度寄存器（比如 x87 的 80 位临时寄存器）。它对现代 HotSpot（x64）几乎没影响，但在某些旧平台或特定 JNI 场景下才可能暴露差异。
strictfp 修饰类或方法时，实际约束的是哪些运算
它只作用于 float 和 double 的算术运算（+、-、*、/、%）以及 cast，不约束 Math 类方法（如 Math.sin）、BigDecimal、JNI 调用或硬件指令直译。JVM 实现可自由选择是否在内部用更高精度中间结果——strictfp 唯一禁止的是把这种自由用在 float/double 表达式求值中。
- 被修饰的方法里，
a + b * c的中间乘积必须截断为double精度，不能暂存在 80 位寄存器再参与加法 - 未修饰的方法，HotSpot x64 默认已禁用 x87，所以行为和 strictfp 一致；但 IA32 或某些嵌入式 JVM 可能不同
-
strictfp不改变Double.doubleToLongBits()结果，也不修复舍入误差本身
什么时候真需要 strictfp：跨平台一致性的真实场景
典型情况是：你正在写一个需要在 Android（Dalvik/ART）、旧版 Java ME、或不同 CPU 架构（x86 vs ARM）上跑出**完全相同中间结果**的确定性算法，比如游戏物理模拟、金融协议校验、或离线加密哈希链计算。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- Android 4.4 以前的 Dalvik 对
strictfp有实际响应；ART 后期版本基本忽略，但保留语法兼容 - 如果代码只跑在现代 OpenJDK（11+）x64 服务器上，加
strictfp几乎不会改变任何行为 - 它无法解决
0.1 + 0.2 != 0.3这类固有浮点问题，只是确保这个“错误”在所有目标平台上一模一样
常见误用和编译期陷阱
很多人以为加了 strictfp 就能“精确计算”，结果发现输出还是不一致——往往是因为漏掉了关键环节。
立即学习“Java免费学习笔记（深入）”；
- 只给类加
strictfp，但关键计算逻辑在非 strictfp 的父类方法里调用，无效 - 用
javac -target 1.2编译时，strictfp会被写入字节码；但用-target 1.8+且运行在新 JVM 上，JIT 可能优化掉其效果（尤其当它判断无影响时） -
strictfp不影响常量折叠：编译期算好的0.1f + 0.2f值由 javac 决定，和运行时 strictfp 无关 - Gradle/Maven 中若配置了
sourceCompatibility = 1.8但targetCompatibility = 11，字节码里 strictfp 标志可能被忽略
真正要跨平台一致，得先确认你的目标平台是否真的对 strictfp 敏感；否则花时间加修饰符，不如直接切到 BigDecimal 或整数运算。最麻烦的不是 strictfp 本身，而是你以为它起作用了，其实 JIT 或底层库早绕过去了。
