常量折叠是java编译器在编译期将final基本类型或string字面量组成的表达式直接计算并替换为结果字面量，.class文件中无原始运算痕迹。
什么是常量折叠：编译器在干啥
Java 编译器（javac）对 final 基本类型或字符串字面量组成的表达式，在编译期直接计算结果，并用字面量替换原表达式——这叫常量折叠。它不是运行时行为，不依赖 JVM 优化，而是 .class 文件里就没了原始运算痕迹。
比如：final int a = 2; final int b = 3; int c = a + b; 编译后，c 的赋值实际变成 int c = 5;，连加法指令都消失了。
常见错误现象：
• 你改了 public static final int VERSION = 1; 的值，但依赖它的其他模块没重编译，依然用旧值 → 因为值已被内联进调用方的字节码里
• 用反射读取该字段，得到的是编译期快照值，而非当前类加载时的值（这点常被误认为“反射失效”）
哪些情况会触发常量折叠
必须同时满足三个条件，缺一不可：
-
final修饰（类字段或局部变量均可，但局部变量无法跨方法共享） - 类型是基本类型（
int、boolean、char等）或String - 初始化表达式本身是编译期常量（即只含字面量、已折叠的
final变量、简单运算符如+、&、?:等）
反例不会折叠：
• final String s = System.getProperty("os.name");（运行时才确定）
• final int x = new Random().nextInt();（含对象创建）
• final long t = System.currentTimeMillis();（非编译期可求值）
为什么 final String 拼接也常被折叠
Java 对字符串有额外规则：只要参与拼接的全是编译期常量（包括 final String），整个表达式就算常量表达式。
示例：final String a = "hello"; final String b = "world"; String s = a + " " + b;
→ 编译后等价于 String s = "hello world";
但注意：
• final String a = "hello"; String b = "world"; String s = a + b; 不会折叠（b 不是 final）
• final String a = getConst();（哪怕 getConst() 总返回 "x"）也不会，因为方法调用无法在编译期求值
性能影响很实在：避免了运行时创建 StringBuilder 和多次 append，尤其在循环外的静态初始化中能省掉对象分配。
怎么验证是否发生了常量折叠
最可靠方式是看字节码：
• 用 javap -c YourClass 查看目标方法的指令
• 如果原表达式消失，直接出现 iconst_5 或 ldc "xxx"，说明已折叠
容易踩的坑：
• 用 IDE 的“Find Usages”查 final 字段，可能漏掉已被内联的调用点（它们不再引用该字段）
• 在模块化项目（JPMS）中，如果常量定义在 requires static 的模块里，而调用方未声明该依赖，编译会失败——不是折叠问题，是可见性问题
• final 字段若被标记为 public 且用于 API 版本号等场景，修改值后必须强制所有下游重编译，否则行为不一致
这件事的复杂点不在理解机制，而在协作边界：一旦你把一个 public static final 值暴露出去，它就不再是“变量”，而是“契约”。改它，等于改 ABI。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
