??我們從第一天學(xué)習(xí)Java開始，就對Java的類初始化順序牢記于心。但是在實際開發(fā)過程中痒钝，似乎很難能接觸這一部分的應(yīng)用。在這之前痢毒，我也認為它只是面試中八股文而已送矩，直到最近踩了一個坑，這才發(fā)現(xiàn)它是多么的重要哪替。
1. 說說坑栋荸？
??地球人都知道，在Java世界中凭舶，類初始化順序是：父類的靜態(tài)成員變量或者靜態(tài)代碼塊-> 子類的靜態(tài)成員變量或者靜態(tài)-> 父類成員變量或者普通代碼塊 ->父類的構(gòu)造方法-> 子類成員變量或者普通代碼塊 -> 子類的構(gòu)造方法蒸其。
??我們在理解上都沒有問題，但是使用上很容易忽略這個順序库快。我舉一個例子：假設(shè)有兩個類摸袁，分別是Animal和Dog類，其中Dog繼承于Animal(是不是感覺回到了學(xué)習(xí)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);
}
}
??代碼實現(xiàn)很簡單，總的來說就是：父類有一個非final的方法在其構(gòu)造方法里面回調(diào)闽铐，子類重寫了這個方法蝶怔，同時在這方法里面訪問了一個自己的一個成員變量。
??那么這里會什么問題呢兄墅？大家可以運行一下上面的代碼踢星，發(fā)現(xiàn)輸出的結(jié)果是：我吃null，也就是說foodName還沒有初始化隙咸。在這里沐悦，很容易理解為什么foodName沒有初始化成洗，因為在類初始化順序中，子類的成員變量在父類的構(gòu)造方法之后才初始化藏否。這個Demo足夠的簡單瓶殃，所以大家覺得沒有問題，在正式的開發(fā)環(huán)境中副签，情況一般都是非常復(fù)雜的遥椿，代碼成千上萬，我們在一個方法里面訪問本類的成員變量淆储，一般不會關(guān)心這個方法是什么時候回調(diào)的冠场，從而導(dǎo)致在開發(fā)過程中遇到不可預(yù)知的結(jié)果。
??不過幸運的是本砰，這種問題是必現(xiàn)的碴裙，一般在開發(fā)中就能遇到并且解決，并不會帶到線上去灌具，但是我還是想說：父類的構(gòu)造方法(代碼塊)里面不要調(diào)用可以被子類重寫的方法。
??除此以外譬巫，這種調(diào)用方式還會遇到一個隱式的問題：
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類的代碼咖楣，在其內(nèi)部定義了兩個成員變量，分別是：foodName1和foodName2芦昔，它們都在eat方法里面賦值诱贿，需要注意的是，foodName2在定義設(shè)置默認值為null咕缎，而foodName1沒有設(shè)置默認值珠十。那么我們創(chuàng)建Dog的對象，然后調(diào)用它的print方法凭豪，結(jié)果如何呢焙蹭？結(jié)果是：foodName1 = 肉 foodName2 = null。也就是說嫂伞，設(shè)置默認值的成員變量即使在方法里面重新賦值孔厉，在真正使用的時候卻還是默認值。這是為啥呢帖努？其實要想真正了解其內(nèi)部原理撰豺，就要扒Dog類的字節(jié)碼了，但是我懶得扒拼余，猜測其原因是：如果在定義成員變量沒有設(shè)置默認值時污桦，當其初始化時發(fā)現(xiàn)已經(jīng)被初始化，就不再進行初始化匙监。換言之凡橱，如果設(shè)置了默認值小作，即使之前已經(jīng)被賦值，也會被默認值覆蓋梭纹。
??相比于第一個坑躲惰，第二個坑顯得更加隱式和不容易理解”涑椋總之還是那么一句話：父類的構(gòu)造方法(代碼塊)里面不要調(diào)用可以被子類重寫的方法础拨。最重要的是，在這個過程中绍载，編譯器并沒有做出任何提示诡宗，這也是這類問題容易出現(xiàn)的原因之一吧。
2. 聊聊Kotlin?
??也許大家在Java中習(xí)慣了上面的使用方式击儡，同時編譯器也沒有報錯塔沃，說明官方也默認這種操作(我亂說的)。但是阳谍，我們以相同的方式應(yīng)用在Kotlin中蛀柴，編譯器報了一個警告：
open class Test {
private val string = getString()
protected open fun getString(): String {
return ""
}
}
??總體上來說，比Java友好的多矫夯，至少有了一個警告提示鸽疾。
??從這里，我們可以得出來兩個結(jié)論：
- 不要隨意忽略編譯器給出的警告训貌。
- 快去使用Kotlin吧Ｖ瓢埂！递沪！
