Java 重寫方法與初始化的隱患
雖然文章標題是Java, 但幾乎所有面向對象設計的語言都遵守這個初始化流程, 感謝廖祜秋liaohuqiu_秋百萬指出, 之前忘記提這個了.
前言
drakeet寫了個和RecyclerView相關的GenerousRecyclerView, 原文提到了寫這個的目的. 因為需要知道ViewGroup的clipToPadding屬性, 所以調用了ViewGroup.getClipToPadding, 但這個方法是API level 21引入的. 我看了一下代碼, ViewGroup是通過調用setClipToPadding完成相關內容初始化的, setClipToPadding在API level 1就有了, 也就是說我們只要監視setClipToPadding的調用, 就能知道ViewGroup的clipToPadding狀態. 如此巧妙, 如果我告訴drakeet, 說不定就能引起他的注意, 出任CEO, 走上人生***.
如果你已經知道我要說什么了, 可以鄙視我.
問題
簡單還原一下問題, 我們有一個類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字節碼.
下面是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條指令.
