Java 重寫方法與初始化的隱患
雖然文章標題是Java, 但幾乎所有面向?qū)ο笤O計的語言都遵守這個初始化流程, 感謝廖祜秋liaohuqiu_秋百萬指出, 之前忘記提這個了.
前言
drakeet寫了個和RecyclerView相關的GenerousRecyclerView, 原文提到了寫這個的目的. 因為需要知道ViewGroup的clipToPadding屬性, 所以調(diào)用了ViewGroup.getClipToPadding, 但這個方法是API level 21引入的. 我看了一下代碼, ViewGroup是通過調(diào)用setClipToPadding完成相關內(nèi)容初始化的, setClipToPadding在API level 1就有了, 也就是說我們只要監(jiān)視setClipToPadding的調(diào)用, 就能知道ViewGroup的clipToPadding狀態(tài). 如此巧妙, 如果我告訴drakeet, 說不定就能引起他的注意, 出任CEO, 走上人生***.
如果你已經(jīng)知道我要說什么了, 可以鄙視我.
問題
簡單還原一下問題, 我們有一個類SuperClass
- public class SuperClass {
- private int mSuperX;
- public SuperClass() {
- setX(99);
- }
- public void setX(int x) {
- mSuperX = x;
- }
- }
現(xiàn)在我們想隨時知道mSuperX是什么值, 不用反射, 因為父類從不直接修改mSuperX的值, 總是通過setX來改, 那么最簡單的方法就是繼承SuperClass, 重寫setX方法, 監(jiān)聽它的改變就好.下面是我們的子類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初始化有可能不調(diào)用setClipToPadding, 此時是默認值, 為了模擬這種情況, 將mSubX初始化為1.
***在main里調(diào)用:
- 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
實際分析
要想知道發(fā)生了什么, 最簡單的方法就是看看到底程序到底是怎么執(zhí)行的, 比如單步調(diào)試, 或者直接一點, 看看Java字節(jié)碼.
下面是Main的字節(jié)碼
- 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明顯長得不一樣.
字節(jié)碼乍一看怪怪的, 只要知道它隱含了一個棧和局部變量表就好懂了.
這段代碼首先new一個SubClass實例, 把引用入棧, dup是把棧頂復制一份入棧, invokespecial #3將棧頂元素出棧并調(diào)用它的某個方法, 這個方法具體是什么要看常量池里第3個條目是什么, 但是javap生成的字節(jié)碼直接給我們寫在旁邊了, 即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幫我們合成的一個方法, 里面的指令會幫我們按順序進行普通成員變量初始化, 也包括初始化塊里的代碼, 注意是按順序執(zhí)行, 這些都執(zhí)行完了之后才輪到構造方法里代碼生成的指令執(zhí)行. 這里aload_0將局部變量表中下標為0的元素入棧, 其實就是Java中的this, 結合invokespecial #1, 是在調(diào)用父類的構造函數(shù), 也就是我們常見的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
- ......
- }
同樣是先調(diào)了父類Object的構造方法, 然后再將this, 99入棧, invokevirtual #2旁邊注釋了是調(diào)用setX, 參數(shù)分別是this和99也就是this.setX(99), 然而這個方法被重寫了, 調(diào)用的是子類的方法, 所以我們再看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, 第二個是括號里的參數(shù), 也就是99, invokespecial #3調(diào)用的是父類的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入棧, 再把參數(shù)入棧, 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 // 即將執(zhí)行這句
- 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處開始繼續(xù)分析, 5,6,7將參數(shù)的值賦給mSubX, 此時mSubX是99了, 下面那一堆則是在執(zhí)行System.out.println("SubX is assigned " + x);并返回, 還可以看到Java自動幫我們使用StringBuilder優(yōu)化字符串拼接, 就不分析了.
說了這么多, 我們的代碼才剛把下面箭頭指著的這句執(zhí)行完:
- 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已經(jīng)是99了, 再執(zhí)行下面的4,5,6, 這一部分是SubClass的初始化, 代碼將把1賦給mSubX, 99被1覆蓋了.
方法返回后, 相當于我們執(zhí)行完了箭頭指的這一句代碼:
- public class Main {
- public static void main(String[] args) {
- ->SubClass sc = new SubClass();
- sc.printX();
- }
- }
接下來執(zhí)行的代碼將打印mSubX的值, 自然就是1了.
以前就聽說過JVM是基于棧的, Dalvik是基于寄存器的, 現(xiàn)在看了Java字節(jié)碼, 回想一下smali, 自然就能明白. 我在Android無需權限顯示懸浮窗, 兼談逆向分析app中有分析smali代碼, smali里面經(jīng)?？吹筋愃苬0, v1這類東西, 是在操作寄存器, 而剛才分析的bytecode, 指令常常伴隨著入棧出棧.
理論解釋
我們都知道Java是面向?qū)ο蟮恼Z言, 面向?qū)ο笕筇匦灾欢鄳B(tài)性. 假如父類構造方法中調(diào)用了某個方法, 這個方法恰好被子類重寫了, 會發(fā)生什么?
根據(jù)多態(tài)性, 實際被調(diào)用的是子類的方法, 這個沒錯. 再考慮有繼承時, 初始化的順序. 如果是new一個子類, 那么初始化順序是:
父類static成員 -> 子類static成員 -> 父類普通成員初始化和初始化塊 -> 父類構造方法 -> 子類普通成員初始化和初始化塊 -> 子類構造方法
父類構造方法中調(diào)用了一次setX, 此時mSubX中已經(jīng)是我們要跟蹤的值, 但之后子類普通成員初始化將mSubX又初始化了一遍, 覆蓋了前面我們跟蹤的值, 自然得到的值就是錯的.
Java中, 在構造方法中唯一能安全調(diào)用的是基類中的final方法, 自己的final方法(自己的private方法自動final), 如果類本身是final的, 自然就能安全調(diào)用自己所有的方法.
完全遵守這個準則, 可以保證不會出這個bug. 實際上我們常常不能遵守, 所以要時刻小心這個問題.
這個東西在Java編程思想(第四版) (機械工業(yè)出版社 2012年11月第1版) 的8.3.3小節(jié)有寫過, 但是這種東西除非自己遇到bug了, 基本看過不會有印象.
這篇文章所有的知識點基本都是很基礎的, 我自己也都記得, 但當這些知識合在一起的時候, 他們之間產(chǎn)生的反應卻是我沒有注意過的. 這也是我寫這篇文章的原因.
如果以后有人面試拿這個問題考你, 你可能是遇上drakeet了.
題外話
關于默認初始化, 比如這樣寫:
- public class SubClass extends SuperClass {
- private int mSubX;
- public SubClass() {}
- ......
- }
如果父類保證一定會在初始化時調(diào)用setX, 程序是不會出現(xiàn)上面說的bug的, 因為默認初始化并不是靠生成下面這樣的代碼默認初始化.
4: aload_0
5: iconst_1
6: putfield #2 // Field mSubX:I
所謂的默認初始化, 其實是我們要實例化一個對象之前, 需要一塊內(nèi)存放我們的數(shù)據(jù), 這塊內(nèi)存被全部置為0, 這就是默認初始化了.
下面這兩句話, 雖然效果一樣, 但實際是有區(qū)別的.
private int mSubX;
private int mSubX = 0;
一般情況下, 這兩句代碼對程序沒有任何影響(除非你遇到這個bug), 上面一句和下面一句的區(qū)別在于, 下面一句會導致<init>方法里面生成3條指令, 分別是aload_0, iconst_0, putfield #**, 而上面一句則不會.
所以如果你的成員變量使用默認值初始化, 就沒必要自己賦那個默認值, 而且還能省3條指令.
