Java 重寫方法與初始化的隱患

Shawon發表於2015-10-29
Java

雖然文章標題是Java, 但幾乎所有物件導向設計的語言都遵守這個初始化流程, 感謝廖祜秋liaohuqiu_秋百萬指出, 之前忘記提這個了.

前言

drakeet寫了個和RecyclerView相關的GenerousRecyclerView, 原文提到了寫這個的目的. 因為需要知道ViewGroup的clipToPadding屬性, 所以呼叫了ViewGroup.getClipToPadding, 但這個方法是API level 21引入的. 我看了一下程式碼, ViewGroup是通過呼叫setClipToPadding完成相關內容初始化的, setClipToPadding在API level 1就有了, 也就是說我們只要監視setClipToPadding的呼叫, 就能知道ViewGroup的clipToPadding狀態. 如此巧妙, 如果我告訴drakeet, 說不定就能引起他的注意, 出任CEO, 走上人生巔峰.

Java重寫方法與初始化的隱患

如果你已經知道我要說什麼了, 可以鄙視我.

問題

簡單還原一下問題, 我們有一個類SuperClass

public class SuperClass {

    private int mSuperX;

    public SuperClass() {
        setX(99);
    }

    public void setX(int x) {
        mSuperX = x;
    }
}

現在我們想隨時知道mSuperX是什麼值, 不用反射, 因為父類從不直接修改mSuperX的值, 總是通過setX來改, 那麼最簡單的方法就是繼承SuperClass, 重寫setX方法, 監聽它的改變就好.下面是我們的子類SubClass:

public class SubClass extends SuperClass {

    private int mSubX = 1;

    public SubClass() {}

    @Override
    public void setX(int x) {
        super.setX(x);
        mSubX = x;
        System.out.println("SubX is assigned " + x);
    }

    public void printX() {
        System.out.println("SubX = " + mSubX);
    }
}

我使用mSubX來跟蹤mSuperX

因為在ViewGroup中, clipToPadding預設值是true(為了簡化問題, 把它當成boolean, 實際並不是), 而ViewGroup初始化有可能不呼叫setClipToPadding, 此時是預設值, 為了模擬這種情況, 將mSubX初始化為1.

最後在main裡呼叫:

public class Main {
    public static void main(String[] args) {
        SubClass sc = new SubClass();
        sc.printX();
    }
}

很多人, 包括我, 認為終端輸出的結果應該是:

SubX is assigned 99
SubX = 99

然而真正執行後輸出的是:

SubX is assigned 99
SubX = 1
Java重寫方法與初始化的隱患

實際分析

要想知道發生了什麼, 最簡單的方法就是看看到底程式到底是怎麼執行的, 比如單步除錯, 或者直接一點, 看看Java位元組碼.

下面是Main的位元組碼

Compiled from "Main.java"
public class bugme.Main {
  ......
  public static void main(java.lang.String[]);
    Code:
       0: new           #2                  // class bugme/SubClass
       3: dup           
       4: invokespecial #3                  // Method bugme/SubClass."<init>":()V
       ......  
}

這是直接用javap反編譯.class檔案得到的. 雖說同樣是Java寫的, 用apktool反編譯APK檔案(其中的dex檔案)得到的smali程式碼和Java Bytecode明顯長得不一樣.

位元組碼乍一看怪怪的, 只要知道它隱含了一個棧和區域性變數表就好懂了.

這段程式碼首先new一個SubClass例項, 把引用入棧, dup是把棧頂複製一份入棧, invokespecial #3將棧頂元素出棧並呼叫它的某個方法, 這個方法具體是什麼要看常量池裡第3個條目是什麼, 但是javap生成的位元組碼直接給我們寫在旁邊了, 即SubClass.<init>.

接下來看SubClass.<init>,

public class bugme.SubClass extends bugme.SuperClass {
  public bugme.SubClass();
    Code:
       0: aload_0       
       1: invokespecial #1                  // Method bugme/SuperClass."<init>":()V
       ......

這裡面並沒有方法叫<init>, 是因為javap為了方便我們閱讀, 直接把它改成類名bugme.SubClass, 順便一提, bugme是包名. <init>方法並非通常意義上的構造方法, 這是Java幫我們合成的一個方法, 裡面的指令會幫我們按順序進行普通成員變數初始化, 也包括初始化塊裡的程式碼, 注意是按順序執行, 這些都執行完了之後才輪到構造方法裡程式碼生成的指令執行. 這裡aload_0將區域性變數表中下標為0的元素入棧, 其實就是Java中的this, 結合invokespecial #1, 是在呼叫父類的建構函式, 也就是我們常見的super().

所以我們再看SuperClass.<init>

public class bugme.SuperClass {
  public bugme.SuperClass();
    Code:
       0: aload_0       
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: aload_0       
       5: bipush        99
       7: invokevirtual #2                  // Method setX:(I)V
      10: return  

  ......     
}

同樣是先調了父類Object的構造方法, 然後再將this, 99入棧, invokevirtual #2旁邊註釋了是呼叫setX, 引數分別是this和99也就是this.setX(99), 然而這個方法被重寫了, 呼叫的是子類的方法, 所以我們再看SubClass.setX:

public class bugme.SubClass extends bugme.SuperClass {
  ......
  public void setX(int);
    Code:
       0: aload_0       
       1: iload_1       
       2: invokespecial #3                  // Method bugme/SuperClass.setX:(I)V
       ......
}

這裡將區域性變數表前兩個元素都入棧, 第一個是this, 第二個是括號裡的引數, 也就是99, invokespecial #3呼叫的是父類的setX, 也就是我們程式碼中寫的super.setX(int)

SuperClass.setX就很簡單了:

public class bugme.SuperClass {
  ......     
  public void setX(int);
    Code:
       0: aload_0       
       1: iload_1       
       2: putfield      #3                  // Field mSuperX:I
       5: return        
}

這裡先把this入棧, 再把引數入棧, putfield #3使得前兩個入棧的元素全部出棧, 而成員mSuperX被賦值, 這四條指令只對應程式碼裡的一句this.mSuperX = x;

接下來控制流回到子類的setX:

public class bugme.SubClass extends bugme.SuperClass {
  ......
  public void setX(int);
    Code:
       0: aload_0       
       1: iload_1       
       2: invokespecial #3                  // Method bugme/SuperClass.setX:(I)V
     ->5: aload_0                           // 即將執行這句
       6: iload_1       
       7: putfield      #2                  // Field mSubX:I
      10: getstatic     #4                  // Field java/lang/System.out:Ljava/io/PrintStream;
      13: new           #5                  // class java/lang/StringBuilder
      16: dup           
      17: invokespecial #6                  // Method java/lang/StringBuilder."<init>":()V
      20: ldc           #7                  // String SubX is assigned 
      22: invokevirtual #8                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      25: iload_1       
      26: invokevirtual #9                  // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
      29: invokevirtual #10                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
      32: invokevirtual #11                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      35: return
}

從5處開始繼續分析, 5,6,7將引數的值賦給mSubX, 此時mSubX是99了, 下面那一堆則是在執行System.out.println("SubX is assigned " + x);並返回, 還可以看到Java自動幫我們使用StringBuilder優化字串拼接, 就不分析了.

說了這麼多, 我們的程式碼才剛把下面箭頭指著的這句執行完:

public class bugme.SubClass extends bugme.SuperClass {
  public bugme.SubClass();
    Code:
       0: aload_0       
     ->1: invokespecial #1                  // Method bugme/SuperClass."<init>":()V
       4: aload_0       
       5: iconst_1      
       6: putfield      #2                  // Field mSubX:I
       9: return        

  ......      
}

此時mSubX已經是99了, 再執行下面的4,5,6, 這一部分是SubClass的初始化, 程式碼將把1賦給mSubX, 99被1覆蓋了.

方法返回後, 相當於我們執行完了箭頭指的這一句程式碼:

public class Main {
    public static void main(String[] args) {
      ->SubClass sc = new SubClass();
        sc.printX();
    }
}

接下來執行的程式碼將列印mSubX的值, 自然就是1了.

以前就聽說過JVM是基於棧的, Dalvik是基於暫存器的, 現在看了Java位元組碼, 回想一下smali, 自然就能明白. 我在Android無需許可權顯示懸浮窗, 兼談逆向分析app中有分析smali程式碼, smali裡面經常看到類似v0, v1這類東西, 是在操作暫存器, 而剛才分析的bytecode, 指令常常伴隨著入棧出棧.

理論解釋

我們都知道Java是物件導向的語言, 物件導向三大特性之一多型性. 假如父類構造方法中呼叫了某個方法, 這個方法恰好被子類重寫了, 會發生什麼?

根據多型性, 實際被呼叫的是子類的方法, 這個沒錯. 再考慮有繼承時, 初始化的順序. 如果是new一個子類, 那麼初始化順序是:

父類static成員 -> 子類static成員 -> 父類普通成員初始化和初始化塊 -> 父類構造方法 -> 子類普通成員初始化和初始化塊 -> 子類構造方法

父類構造方法中呼叫了一次setX, 此時mSubX中已經是我們要跟蹤的值, 但之後子類普通成員初始化將mSubX又初始化了一遍, 覆蓋了前面我們跟蹤的值, 自然得到的值就是錯的.

Java中, 在構造方法中唯一能安全呼叫的是基類中的final方法, 自己的final方法(自己的private方法自動final), 如果類本身是final的, 自然就能安全呼叫自己所有的方法.

完全遵守這個準則, 可以保證不會出這個bug. 實際上我們常常不能遵守, 所以要時刻小心這個問題.

這個東西在Java程式設計思想(第四版) (機械工業出版社 2012年11月第1版) 的8.3.3小節有寫過, 但是這種東西除非自己遇到bug了, 基本看過不會有印象.

這篇文章所有的知識點基本都是很基礎的, 我自己也都記得, 但當這些知識合在一起的時候, 他們之間產生的反應卻是我沒有注意過的. 這也是我寫這篇文章的原因.

如果以後有人面試拿這個問題考你, 你可能是遇上drakeet了.

題外話

關於預設初始化, 比如這樣寫:

public class SubClass extends SuperClass {
    private int mSubX;

    public SubClass() {}
    ......
}

如果父類保證一定會在初始化時呼叫setX, 程式是不會出現上面說的bug的, 因為預設初始化並不是靠生成下面這樣的程式碼預設初始化.

       4: aload_0       
       5: iconst_1      
       6: putfield      #2                  // Field mSubX:I

所謂的預設初始化, 其實是我們要例項化一個物件之前, 需要一塊記憶體放我們的資料, 這塊記憶體被全部置為0, 這就是預設初始化了.

下面這兩句話, 雖然效果一樣, 但實際是有區別的.

private int mSubX;

private int mSubX = 0;

一般情況下, 這兩句程式碼對程式沒有任何影響(除非你遇到這個bug), 上面一句和下面一句的區別在於, 下面一句會導致<init>方法裡面生成3條指令, 分別是aload_0, iconst_0, putfield #**, 而上面一句則不會.

所以如果你的成員變數使用預設值初始化, 就沒必要自己賦那個預設值, 而且還能省3條指令.

相關文章