是，满足编译期常量条件的 static final 基本类型变量会被编译器内联为字面量，参与算术运算无运行时开销；否则不优化。
final 常量参与算术运算时，编译器是否优化？
Java 中用 final 修饰的基本类型变量（如 static final double）在满足“编译期常量”条件时，会被内联为字面量。这意味着像 G = 6.67430e-11 这样的声明，只要它在声明时就用字面量初始化、类型是基本类型或 String，后续参与的算术表达式（如 G * m1 * m2 / rSq）不会引入额外运行时开销——编译后等价于直接写数字。
但注意：如果 final 变量的值来自方法调用（如 Math.PI 是 public static final double，但它不是编译期常量），则不内联；而 Math.PI 本身虽不可变，但 JVM 不将其视为编译期常量，所以不能用于 case 或注解属性中。
-
static final double G = 6.67430e-11;✅ 编译期常量，可内联 -
static final double PI = Math.PI;❌ 非编译期常量，不内联 -
final double gLocal = 9.80665;（非 static）⚠️ 仅本实例可见，不参与编译期优化
物理公式定义该用 static final 还是普通 final？
物理常量（如万有引力常数、光速、普朗克常量）属于类级别事实，所有实例共享且永不变化，必须声明为 static final。否则每次新建对象都重复存储一份，浪费内存；更严重的是，若漏写 static，会导致不同实例间无法统一数值，破坏物理意义的一致性。
常见错误是写成：final double c = 299792458; —— 这会让每个 PhysicsCalculator 实例都存一个 c，且无法被其他类直接引用（没 public 和 static）。
立即学习“Java免费学习笔记（深入）”；
- ✅ 正确姿势：
public static final double SPEED_OF_LIGHT = 299_792_458.0; - ✅ 推荐加下划线分隔：
6.67430e-11→6.67430e-11（可读性好，Java 7+ 支持） - ⚠️ 注意 double 精度：不要用
float存物理常量，float会丢失有效位（如6.67430e-11f实际存的是近似值）
如何把公式逻辑封装进方法而不破坏常量语义？
常量只负责“值不变”，公式计算应放在普通（或 static）方法里。不要试图把整个公式塞进常量声明中（比如 static final double F = G * m1 * m2 / r * r;），因为 m1、m2、r 是变量，这样写根本通不过编译。
正确做法是：用 static final 定义所有基础常量，再写一个清晰命名的方法承载计算逻辑。例如牛顿万有引力：
public static double gravitationalForce(double m1, double m2, double r) {
if (r == 0) throw new IllegalArgumentException("Distance cannot be zero");
return GRAVITATIONAL_CONSTANT * m1 * m2 / (r * r);
}- 方法参数名要明确物理含义（别用
a、b） - 做必要校验（如除零、负质量），比让调用方处理更可靠
- 避免在方法里重复定义常量（如再写一遍
6.67430e-11），否则维护时容易漏改
单位一致性必须靠人来保证，代码帮不上忙
Java 类型系统不检查单位。即使你写了 static final double PLANCK_CONSTANT = 6.62607015e-34;，它仍是纯数字。如果你传入的 mass 单位是吨而非千克，或者 distance 是公里而非米，公式结果就完全错误——而编译器和运行时都不会报错。
这是最常被忽略的点：常量定义再规范，也无法替代开发者对单位制的主动管理。
- 建议在常量注释中明确标注单位，例如：
// in m^3 kg^-1 s^-2 - 可在方法 JavaDoc 中强调输入单位，如 “@param r distance in meters”
- 考虑引入类型别名（如用
MassKg、DistanceM包装 double），但这是额外设计成本，不是语言原生支持
公式跑出 NaN 或数量级明显不对时，先盯住单位，而不是怀疑常量值或运算符优先级。
