概述
在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了而已。
网友评论