嵌套赋值与普通赋值是否有差异？final变量编译表现不同的原因

核心原因是Java编译器对「编译时常量表达式」的判定规则不同：虽然两段代码里的变量都是final修饰的不可变变量，但只有满足特定条件的final变量才会被视为编译时常量，进而触发编译期的代码可达性检查。

编译时常量的判定标准 #

Java编译器会把满足以下全部条件的final变量认定为编译时常量：

• 变量类型为基本数据类型或String
• 变量在声明时直接初始化
• 初始化的值是编译期可直接计算的常量表达式（比如字面量、其他编译时常量的算术运算等）

第二段代码的编译报错原因 #

第二段代码中，a和b在声明时直接用字面量10完成初始化：

final int a=10;
final int b = 10;

完全符合编译时常量的判定标准，编译器在编译阶段就能确定a <= b是永远为true的常量条件。因此编译器会判定while循环是无限循环，循环后的System.out.println语句永远无法执行，属于不可达代码，直接抛出编译错误。

第一段代码无限循环的原因 #

第一段代码采用先声明、后通过嵌套赋值初始化的方式：

final int a, b;
a = b = 10;

这种操作属于运行时赋值语句，而非声明阶段的直接初始化。尽管a和b被final修饰后无法再修改，但编译器不会将其认定为编译时常量——编译器不会对运行时赋值的变量做值的推导，只会将其视为普通的不可变变量。

因此，编译器无法在编译期确定a <= b的结果是永久为true，不会触发不可达代码检查，程序运行后会进入无限循环。

总结 #

• 声明时直接用常量表达式初始化的final变量，会被视为编译时常量，参与编译期的代码可达性分析
• 先声明后赋值（包括嵌套赋值）的final变量，只是运行时不可修改的变量，不属于编译时常量，编译器不会对其做编译期的常量推导

内容的提问来源于stack exchange，提问作者bharath Reddy