Kotlin中lateinit变量在字节码层面上的解释

概述

在Kotlin里面,变量可以声明为late init:

lateinit var str: String

顾名思义,这是指一个延迟初始化的变量。在kotlin里面,如果在类型声明之后没有使用符号?,则表示该变量不会为null。但是这个时候会要求我们初始化一个值。有些时候,我们在声明变量的时候,并不能初始化这个变量。比如说在使用Spring的时候,我们会声明一个变量,但是在afterProperties里面进行初始化。

但是我们又想使用kotlin非null变量带来的便利,这个时候,你需要的就是lateinit了。它告诉编译器,这个变量会被初始化,并且不会为null,但是在声明这里,我暂时还不知道什么时候会被初始化。

编译器知道你的变量没有初始化吗?

我们来考虑的第一个问题是,一个声明成lateinit的变量,如果在整个代码里面都没有进行任何的初始化,那么能否编译通过?


代码

答案是可以。所以,也就是在编译层面上,kotlin的编译器不会做这种检查。如果你将变量声明为lateinit,它就认为你肯定会初始化,至于你是怎么初始化它的,它就不管了。

如果一个变量声明为lateinit,但是没有初始化,而又被使用了的话,会抛出一个异常UninitializedPropertyAccessException。

那么问题来了,它究竟是怎么实现的呢?

lateinit变量

我们将刚才那段代码的字节码使用javap指令解析之后,看到str变量的内容是:


str字节码

在变量声明的地方,可以看到它和普通的Java里面声明的变量没太多不同,比较大的一个不同是,它被编译器添加了一个RuntimeInvisibleAnnotations。RuntimeInvisibleAnnotations表明这个注解在运行时不能被访问,这主要是指代码层面无法访问。因为这个RuntimeInvisibleAnnotations,也就是NotNull其声明是:

NotNull注解

Rentention被设定成CLASS。

每次访问都判断是否初始化?

我在第一次使用的lateinit的时候就有这个疑问。因为一个lateinit变量被初始化,却被使用了,抛出来的异常是UninitializedPropertyAccessException,这个是kotlin自定义的异常,而不是JDK的异常。这是一个很关键的地方。如果是JDK的异常,那可能是JVM自身内部检测变量是否初始化了。

但是这个异常是Kotlin的,所以必然是Kotlin自己做了手脚。而这种手脚,或者黑科技,只能是通过编译器在编译期间插入字节码指令来完成的。

我首先将怀疑的目光放到了getStr()方法上。我怀疑,Kotlin在代码每次访问str变量的时候,实际上替换成了getStr()方法,而后在getStr()里面完成这种校验,类似于

    fun getStr(): String {
        if (str == null) {
            throw UninitializedPropertyAccessException()
        }
    }

但是这有一个很大的问题,首先,lateinit的确有可能被初始化为null,即便声明为String而不是String?。那么这种改写就是一个很奇怪的东西了。因为一个没有声明为?的变量,却是null,在被使用的时候,抛出来的异常是KotlinNullPointerException.这种改写会导致语言设计层面上的不一致性。

使用反射就能做到这一点,更加猥琐的是利用本地方法调用。

另外一种考虑则是,这种方法简直太消耗性能了。每次访问一个变量,变成一个方法调用,效率至少慢一个数量级。

所以,就需要考虑JVM的机制了。我的第二个猜测是,在访问的变量的那个地方,插入字节码指令,检测是否为null。JVM规范里面定义了一个字节码指令ifnonnull,用于检测一个变量是否为null:


ifnonnull指令

在查看javap之后的结果,果然是利用了这个指令:


sayHello字节码

红色箭头指向的就是ifnonnull指令,其后跟着的13是指如果ifnonnull检测为true,那么就会执行标记为13的字节码指令,也就是astore_1。这条指令之后就是print(str)的过程。

可以看到,所谓的print()方法,也不过是一个语法糖而已,读者可以自己去看看

而如果ifnonnull检测失败,接下来就是执行蓝色箭头指向的指令,它暴露了抛出UninitializedPropertyAccessException的秘密,那就是,调用了kotlin/jvm/internal/Intrinsics.throwUninitializedPropertyAccessException:(Ljava/lang/String;)V


throwUninitializedPropertyAccessException

所以事实上到这里lateinit的秘密就已经清楚了,无非就是编译器给你插入检测为null的指令而已。那么问题还是存在的,前面我已经说过,为null并不代表没有被初始化。但是如果结合Kotlin的语法,如果一个变量的类型声明没有使用?符号,则Kotlin认为,这个变量被初始化之后必不能为null。所以用null检测来取代是否初始化检测,是符合Kotlin的设计的。

但是,基于JVM的语言都有的一个通病就是,如果你调用别的同样JVM的语言的API,那么就会破坏自身的完整性和一致性。比如我说过用反射或者本地方法调用都能把lateinit变量初始化为null,实际上,这就已经超出了kotlin的预计了,因此也就是破坏了kotlin自身的一致性。这个时候,出现语义前后不一致是很容易理解的。

如果再从JVM角度来讨论一下,那就是,JVM本身也没有提供变量是否初始化的指令。而且,JVM明确要求,在给变量分配内存的时候,内存应该被“初始化”了,也就是全部比特位都置为0(这就是各个成员变量默认值的来源)。也就是意味着,在声明lateinit变量的时候,它的引用(指针?)已经被置为null了。所以想达到真的检测变量有没有被用户主动初始化,基本上是不能依赖于JVM的机制,而只能依赖于编译器。

很可惜,我最开始就说了,编译器也放弃了检测lateinit究竟有没有被用户主动初始化。

我觉得是因为编译器不能。或者说,代价太大而限制太多。

我觉得从这里只能得出的一个结论是:如果你的代码真的显示初始化了lateinit变量,而又抛出了UninitializedPropertyAccessException异常,并不需要惊讶,只是因为你恰好将变量初始化为null了而已

你可能感兴趣的:(Kotlin中lateinit变量在字节码层面上的解释)