Kotlin类属性初始化异常 加无用副作用才正常 是定义行为还是Bug

核心结论 #

该现象是Kotlin编译器*跨方法死存储消除（Dead Store Elimination）*优化的实现漏判，不属于语言规范定义的预期正常行为，不存在代码层面的书写错误。

基础执行链路 #

Kotlin类的实例属性初始化语句、init代码块，会严格按照类内书写的先后顺序，逐次插入主构造函数的执行流程。以无额外修改的原始代码为例，未做任何优化时的理想执行步骤为：

1. 为A类实例分配堆内存，所有int类型实例字段自动初始化为JVM默认零值：a=0、b=0
2. 执行val p = load()的赋值逻辑：调用实例方法load()
   • 方法内修改a = 1、b = 3
   • 执行println("init: $a $b")：控制台输出属于不可消除的可观测副作用，会被完整保留
3. 执行var a = 0的赋值：将a从load()写入的1改回0
4. 执行var b = 2的赋值：将b从load()写入的3改回2
5. 构造函数返回实例，main方法读取a、b值，输出main: 0 2

两种代码版本的行为差异根源 #

未添加.also{}时的优化漏判 #

编译器开启静态跨方法分析时，会同时追踪字段的所有写入路径、可观测边界：

• 它识别到var a = 0的赋值目标值，和堆内存分配时的默认零值完全相等
• 它判定这个赋值动作发生在load()调用之后，而load()内部对a的读取、修改，已经在控制台打印的可观测点被完整捕获
  基于上述判断，编译器错误地把“将a从1改回0”的操作判定为没有任何观测点的死存储，直接将对应的PUTFIELD A.a : ICONST_0字节码指令从构造函数中删除。
  这就导致构造函数执行到末尾时，a的值停留在load()方法写入的1，没有被改回初始的0；而b的初始化值2和默认零值不同，编译器不敢随意删除对应的赋值指令，因此最终b的值为2，正好对应你看到的第一个输出结果：main: 1 2。

加上空.also{}后的优化边界变化 #

当你在a的初始化表达式后追加空的.also{}时，优化逻辑会发生明显变化：

• .also{}是Kotlin标准库的高阶函数，编译器的保守优化规则默认这类带lambda参数的函数调用存在潜在可观测副作用，无法随意调整、删除夹在函数调用前后的字段写入指令
• 原本被判定为死存储的a = 0赋值逻辑因此被完整保留，构造函数执行完成后，a的值会被从1改回0，正好对应你看到的第二个输出结果：main: 0 2

规范符合性说明 #

Kotlin语言规范本身允许编译器在不破坏可观测副作用的前提下，自由删除、重排初始化流程中的冗余指令，这类优化从规则层面是合法的。但该场景下的优化结果，明显改变了外部代码可以读取到的对象状态——也就是把原本应该是0的a值，变成了1，属于编译器跨方法分析时忽略“构造函数返回后外部代码读取”这个可观测点的实现Bug，并非规范定义的预期行为，这类问题已经在后续的Kotlin编译器版本中被修复。

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