从一次实际经历说说Java类初始化顺序中容易忽略的点 1. 说说坑? 2. 聊聊Kotlin?

  我们从第一天学习Java开始,就对Java的类初始化顺序牢记于心。但是在实际开发过程中,似乎很难能接触这一部分的应用。在这之前,我也认为它只是面试中八股文而已,直到最近踩了一个坑,这才发现它是多么的重要。

1. 说说坑?

  地球人都知道,在Java世界中,类初始化顺序是:父类的静态成员变量或者静态代码块-> 子类的静态成员变量或者静态-> 父类成员变量或者普通代码块 ->父类的构造方法-> 子类成员变量或者普通代码块 -> 子类的构造方法
  我们在理解上都没有问题,但是使用上很容易忽略这个顺序。我举一个例子:假设有两个类,分别是AnimalDog类,其中Dog继承于Animal(是不是感觉回到了学习Java的第一天?)。它们的代码如下:

public class Animal {
    public Animal() {
        eat();
    }

    protected void eat() {
    }
}

// ----------------------------
public class Dog extends Animal {

    private String foodName = "肉";

    public Dog() {
    }

    @Override
    protected void eat() {
        System.out.println("我吃" + foodName);
    }
}

  代码实现很简单,总的来说就是:父类有一个非final的方法在其构造方法里面回调,子类重写了这个方法,同时在这方法里面访问了一个自己的一个成员变量。
  那么这里会什么问题呢?大家可以运行一下上面的代码,发现输出的结果是:我吃null,也就是说foodName还没有初始化。在这里,很容易理解为什么foodName没有初始化,因为在类初始化顺序中,子类的成员变量在父类的构造方法之后才初始化。这个Demo足够的简单,所以大家觉得没有问题,在正式的开发环境中,情况一般都是非常复杂的,代码成千上万,我们在一个方法里面访问本类的成员变量,一般不会关心这个方法是什么时候回调的,从而导致在开发过程中遇到不可预知的结果。
  不过幸运的是,这种问题是必现的,一般在开发中就能遇到并且解决,并不会带到线上去,但是我还是想说:父类的构造方法(代码块)里面不要调用可以被子类重写的方法
  除此以外,这种调用方式还会遇到一个隐式的问题:

public class Dog extends Animal {
    
    private String foodName1;
    private String foodName2 = null;

    public Dog() {
    }

    @Override
    protected void eat() {
        foodName1 = "肉";
        foodName2 = "骨头";
    }

    public void print() {
        System.out.println("foodName1 = " + foodName1 + " foodName2 = " + foodName2);
    }
}

  我改写了Dog类的代码,在其内部定义了两个成员变量,分别是:foodName1foodName2,它们都在eat方法里面赋值,需要注意的是,foodName2在定义设置默认值为null,而foodName1没有设置默认值。那么我们创建Dog的对象,然后调用它的print方法,结果如何呢?结果是:foodName1 = 肉 foodName2 = null。也就是说,设置默认值的成员变量即使在方法里面重新赋值,在真正使用的时候却还是默认值。这是为啥呢?其实要想真正了解其内部原理,就要扒Dog类的字节码了,但是我懒得扒,猜测其原因是:如果在定义成员变量没有设置默认值时,当其初始化时发现已经被初始化,就不再进行初始化。换言之,如果设置了默认值,即使之前已经被赋值,也会被默认值覆盖。
  相比于第一个坑,第二个坑显得更加隐式和不容易理解。总之还是那么一句话:父类的构造方法(代码块)里面不要调用可以被子类重写的方法。最重要的是,在这个过程中,编译器并没有做出任何提示,这也是这类问题容易出现的原因之一吧。

2. 聊聊Kotlin?

  也许大家在Java中习惯了上面的使用方式,同时编译器也没有报错,说明官方也默认这种操作(我乱说的)。但是,我们以相同的方式应用在Kotlin中,编译器报了一个警告:

open class Test {
    private val string = getString()

    protected open fun getString(): String {
        return ""
    }
}

  总体上来说,比Java友好的多,至少有了一个警告提示。
  从这里,我们可以得出来两个结论:

  1. 不要随意忽略编译器给出的警告。
  2. 快去使用Kotlin吧!!!
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章