Странное котлинское нуль-безопасное поведение

Question

Если глобальное свойство определено как private var raceLoadJob: Job? = null, то Kotlin попросит вас сделать что-то подобное в вашем методе

if (raceLoadJob != null){
    if (raceLoadJob!!.isActive) return // null assertation
}

Kotlin запросит диссертацию, потому что значение raceLoadJob можно изменить.Первое, о чем я подумал, это многопоточность.

Так что вы можете изменить код на

raceLoadJob?.let {
    if (it.isActive) return
}

Но если вы декомпилируете эту часть кода, вы увидите

Job var10000 = this.raceLoadJob;
if (this.raceLoadJob != null) {
   Job var1 = var10000;
   if (var1.isActive()) {
      return;
   }
}

Вы можете видеть, что это условие this.raceLoadJob != null, но не var10000 != null.Это означает, что в теории этот код может завершиться сбоем из-за присвоения значения raceLoadJob, но var10000 равно null.

Это проблема или у меня ошибка в моих рассуждениях?

Answer 1

Ошибка в ваших рассуждениях заключается в том, что вы анализируете поведение кода Kotlin, глядя на выходные данные декомпилятора, а не на байт-код.Компилятор Kotlin генерирует шаблоны байт-кода, которые не используются javac, поэтому декомпилятор (который был разработан для декомпиляции вывода javac) может предоставить только приблизительное представление действительной логики.

Если вы посмотрите на фактический байт-код, это выглядит так:

ALOAD 0
GETFIELD raceLoadJob : LRaceLoadJob;
DUP
IFNULL L1
ASTORE 2

Это показывает, что значение, проверяемое на null, точно такое же, которое используется в последующих вычислениях.