Java 面试：Java 25 的 Flexible Constructor Bodies 改变了什么？
题干与适用场景
Java 25 将 Flexible Constructor Bodies（JEP 513）定稿。面试官要求你说明构造器在显式 super(...) 或 this(...) 前可以做什么、为什么不能读取正在构造的实例，以及这对继承和参数预处理有什么影响。
面试官考察点
- 是否理解构造器调用链和“实例尚未初始化”的安全约束。
- 是否能区分允许的静态逻辑、局部变量和对
this的非法访问。 - 是否能识别预览版本、最终版本和编译目标的迁移风险。
回答前需要澄清的问题
先确认目标是 JDK 25 的最终特性还是较早的 JEP 447/482/492 预览，以及项目的 source、target 和运行时版本。还要确认问题关注语法、JVM 验证，还是将旧的静态参数转换方法直接内联到构造器。
30 秒回答框架
传统 Java 要求构造器第一条语句是 super(...) 或 this(...)。Flexible Constructor Bodies 允许在显式构造器调用前执行一段受限的 prologue，例如计算局部变量或初始化当前类尚未初始化的字段；但不能读取或调用正在构造的实例，也不能把未初始化的 this 传给任意代码。这样可以直接预处理参数，同时保持父类构造先于可观察实例状态的安全规则。
分步骤深入解答
- 把构造器分成 prologue、显式构造器调用和剩余 body；调用
this(...)时仍沿着同一类的构造链，调用super(...)时进入父类。 - prologue 可声明局部变量、执行不依赖实例状态的表达式，并初始化当前类的未初始化字段；这些值可用于构造器参数。
- 禁止读取实例字段、调用实例方法、使用
this作为参数或让任意可观察代码接触半初始化对象。 - JVM 与编译器必须追踪哪些字段仍未初始化，确保父类构造器看不到违反初始化顺序的状态；静态方法和常量可在规则允许时使用。
- 迁移时删除仅为准备
super(...)参数而存在的静态 helper，但保留有副作用、可复用或需要独立测试的逻辑边界。 - 用 JDK 25 编译器和目标运行时验证；若项目仍以旧 source/target 编译，新的语法不能直接提交。
class Child extends Parent {
private final String normalized;
Child(String raw) {
var value = raw.trim(); // prologue: local computation
super(value); // explicit constructor invocation
this.normalized = value;
}
}高质量示范回答
JEP 513 允许构造器在 super(...) 或 this(...) 前有受限的 prologue。它适合做不依赖实例状态的参数预处理和当前类字段初始化，但仍禁止读取实例字段、调用实例方法或把半初始化的 this 传出去。编译器和 JVM 需要保证父类构造器只看到合法的初始化状态。回答时我会区分 JEP 447/482/492 预览与 JDK 25 定稿，并检查 source、target、运行时版本。它减少了为一小段参数转换而创建静态 helper 的需要，却没有取消构造器顺序和继承安全约束。
常见错误
- 说成“任何语句都能放在
super()前”。 - 忽略
this尚未完成初始化，允许调用实例方法或读取字段。 - 把预览版 JEP 编号当成 JDK 25 的最终编号。
- 只改源码，不检查编译目标和部署运行时。
- 为了示例方便在 prologue 引入外部可观察副作用。
追问及应对
为什么允许局部计算却禁止读取 this？
局部计算不会观察半初始化对象；读取字段或调用方法可能触发动态分派、泄露不完整状态或让父类逻辑看到错误不变量。
this(...) 和 super(...) 前的规则一样吗？
两者都受早期构造上下文约束；this(...) 会继续当前类的构造链，super(...) 会进入父类，因此都不能让实例状态在合法初始化前被观察。
什么时候不该内联原来的 helper？
如果 helper 有多个调用点、复杂副作用、独立测试价值或清晰的模块边界，保留 helper 更易维护；该特性只是语法能力，不是重构要求。
如何兼容旧 JDK？
保持旧 source/target 时不能使用新语法；可暂时保留原有参数准备方式，待编译器、运行时和发布矩阵都升级后再迁移。