一個面試問題暴露的認(rèn)知盲區(qū)類與對象到底差在哪前陣子面試一位自稱Java基礎(chǔ)扎實的候選人我問他說說類與對象的本質(zhì)區(qū)別是什么。他張口就來——類是模板對象是實例。我又追問了一句那你覺得類本身在內(nèi)存里有沒有位置如果沒有那Person.class這個文件加載到哪里去了他愣住了支支吾吾半天說不清楚。這一幕其實很典型。很多寫了兩三年 Java 的人能背出模板與實例這個定義但一旦被問到類加載靜態(tài)成員的存儲位置new 到底做了什么這些底層問題時就露餡了。說到底類與對象這四個字不是背一個定義就能過關(guān)的它是整個 Java 面向?qū)ο篌w系的地基。地基松了后面學(xué)多線程、學(xué) JVM、學(xué)框架源碼都會飄。這篇文章我不會只給你一個定義。我會從設(shè)計層面、內(nèi)存層面、運行層面這三個角度把類與對象這件事徹底拆開。順便把那些網(wǎng)上高頻搜但是沒人講透的邊角問題——表達(dá)式必須包含類類型、Optional 對象操作、對象為空判斷、動態(tài)代理里的類與對象——也一起揉進(jìn)來說清楚。不管你是準(zhǔn)備面試、剛?cè)腴T、還是寫了幾年代碼想補基礎(chǔ)這篇都值得看完。1. 類的本質(zhì)編譯期的類型藍(lán)圖與運行期的 Class 對象1.1 類是類型系統(tǒng)的骨架不是一句模板就能概括的說類是一張設(shè)計圖紙這個類比沒有錯但它只描述了類和對象關(guān)系的一個側(cè)面。如果你想把本質(zhì)兩個字講透首先要意識到類是 Java 類型系統(tǒng)的載體它承擔(dān)了三種完全不同的角色。第一種角色類是對現(xiàn)實世界概念的建模。比如定義了Person類本質(zhì)上是在說所有具有姓名、年齡這些屬性能吃飯、能走路這類行為的個體都屬于 Person 這個概念。這是從需求分析角度的理解。第二種角色類是編譯器進(jìn)行類型檢查的依據(jù)。你在代碼里寫Person p new Student();編譯器靠什么判斷這行能不能過靠的就是Person和Student這兩個類在繼承體系中的位置。沒有類編譯器看到的只是一堆無差別的字節(jié)類型安全無從談起。這也是為什么 Java 是強類型語言因為一切類型約束都落地在類這個結(jié)構(gòu)上。第三種角色類本身也是一個對象——準(zhǔn)確地說每個類在 JVM 里都會對應(yīng)一個java.lang.Class類型的實例。這部分很少有人提但它是理解反射、動態(tài)代理、Spring 容器這些高級玩意的關(guān)鍵錨點。后文我會專門展開。1.2 類加載機制你的 .class 文件是怎么從磁盤變成 JVM 里的 Class 對象的回到開頭那個面試問題類在內(nèi)存里到底有沒有位置答案是有但它不是以你寫的那個人類的形式存在的而是以一種叫做Class 對象的特殊對象存在的。過程是這樣的你寫了一個Person.javajavac把它編譯成Person.class字節(jié)碼文件。當(dāng)程序第一次使用Person類時JVM 的類加載器ClassLoader會把這個字節(jié)碼文件讀進(jìn)來經(jīng)過加載、驗證、準(zhǔn)備、解析、初始化這五個階段最終在 JVM 的堆內(nèi)存或者更準(zhǔn)確地說是方法區(qū)/元空間不同 JDK 版本存放位置有差異中生成一個java.lang.Class對象這個對象就代表了Person類本身。這里有幾個關(guān)鍵點值得嚼一嚼類不是從一開始就存在于內(nèi)存里的它是懶加載的。只有當(dāng)你new Person()、訪問Person的靜態(tài)成員、或者用反射Class.forName(Person)時JVM 才會去加載它。同一個類在同一個類加載器下只會被加載一次也就是說 JVM 里只有一個代表Person的 Class 對象。無論你 new 多少個 Person 實例它們指向的是同一個 Class 對象。正因為類本身也是對象所以你可以拿到它、操作它——這就是反射的根基。Person.class這個語法拿到的不就是那個 Class 對象嗎理解了這一層再看類是模板這句話就知道它說的太淺了。模板只是類在設(shè)計階段的樣子。到了運行期類以 Class 對象的形式真實存在于內(nèi)存中擁有自己的屬性、方法描述信息還能被讀取和修改。1.3 靜態(tài)成員屬于類實例成員屬于對象這句話的底層含義Java 基礎(chǔ)里有一個高頻考點靜態(tài)變量static 修飾的成員屬于類實例變量屬于對象。很多教程只是讓你記住這個結(jié)論但結(jié)合上面的內(nèi)容這句話就有了實際意義。static修飾的成員在類加載的準(zhǔn)備階段就會被分配到內(nèi)存中它依附的對象是那個 Class 對象——也就是說只要類被加載了靜態(tài)成員就存在不需要 new 任何一個實例就能訪問。你可以用Person.count直接訪問靜態(tài)變量正是因為count是掛在 Class 對象上的。而實例變量就不同了。每個new Person()出來的對象都有自己獨立的一份實例變量內(nèi)存空間。p1.name和p2.name是兩塊完全不同的內(nèi)存互不影響。我見過不少人因為沒想明白這一點寫出很詭異的代碼。比如在靜態(tài)方法里直接訪問實例變量編譯直接報錯或者用對象.靜態(tài)變量這種寫法——Java 雖然允許但 IDEA 會給你標(biāo)黃警告因為它容易讓人誤以為這個變量屬于對象。實際運行的時候JVM 看的根本不是你用哪個對象來訪問的它看的是變量的聲明類型——這就叫靜態(tài)成員與對象無關(guān)。2. 對象的本質(zhì)new 關(guān)鍵字背后的內(nèi)存分配與生命周期2.1 new 不是魔法它干了幾件具體的事很多人把new Person()當(dāng)成一個造東西的咒語念出來就有對象了。實際上new這個關(guān)鍵字背后JVM 至少做了四件事第一步檢查類是否已經(jīng)被加載。如果Person的 Class 對象還不存在先觸發(fā)類加載流程。這就是為什么第一次 new 一個類的時候程序會卡那么一下。第二步在堆內(nèi)存中為對象分配一塊連續(xù)的內(nèi)存空間。分配完之后這塊內(nèi)存的所有位都被置為零——也就是說對象的實例變量會先有一個零值數(shù)字是 0boolean 是 false引用是 null。注意這時候?qū)ο筮€是一個零狀態(tài)的空殼子。第三步為對象頭設(shè)置必要信息。每個對象在內(nèi)存里不只有實例變量還有一段隱藏的對象頭Object Header里面記錄了這個對象屬于哪個類通過指向 Class 對象的引用、對象的哈希碼、GC 分代年齡、鎖狀態(tài)標(biāo)志等。這就是為什么同一個類 new 出來的對象能調(diào)用到自己的類方法——因為每個對象都持有一個指向自己 Class 對象的引用。第四步調(diào)用構(gòu)造方法init執(zhí)行你在構(gòu)造函數(shù)里寫的初始化邏輯。這一步做完對象才真正變成你期望的樣子——name 被賦上張三age 變成 18。所以你看new的本質(zhì)不是憑空創(chuàng)造而是按著 Class 對象里的元數(shù)據(jù)信息在內(nèi)存里復(fù)制出一份數(shù)據(jù)的載體。2.2 棧上的引用與堆上的對象一對糾纏不清的孿生兄弟新手最容易混亂的點在于Person p new Person();這行代碼里p到底是什么p不是對象本身它是一個引用Reference是一個存放在棧內(nèi)存里的變量它的值是一個指向堆內(nèi)存中那個 Person 對象的地址。你可以把p理解成遙控器堆里的對象才是電視機。你拿著遙控器按按鈕——也就是用p.name、p.eat()這種語法——實際上是通過遙控器的信號去操作電視機。這個區(qū)分極其重要因為它能解釋很多詭異現(xiàn)象為什么p1 p2;之后改動p1.namep2.name也變了因為p1和p2這兩個遙控器指向的是同一臺電視機。很多對象賦值頁面不變、集合里存的都是同一個對象這類 bug追溯到底都是這種引用傳遞造成的。為什么方法參數(shù)傳對象方法內(nèi)部改了屬性外面的對象也變了因為傳進(jìn)去的不是對象的副本而是引用——你復(fù)制了一個遙控器但遙控器控制的還是原來那臺電視機。為什么判斷兩個對象相等不能用因為比較的是兩個遙控器的編號引用地址而不是電視機本身的內(nèi)容。對象為空這個判斷也一樣。if (p null)檢查的其實是這個遙控器有沒有綁定任何電視機。一個新建的對象永遠(yuǎn)不為 null因為 new 成功就一定在堆里有位置而如果一個引用變量沒有被賦值或者被賦了 null檢查就通過了。2.3 對象的生命周期從可達(dá)到不可達(dá)再到被 GC 回收對象什么時候被銷毀很多剛學(xué) Java 的人以為出了作用域就被銷毀。準(zhǔn)確地說對象本身沒有作用域概念作用域是引用變量的概念。真正決定對象生死的是——它是否還被可達(dá)。什么是可達(dá)就是從 GC Roots垃圾回收根節(jié)點出發(fā)沿著引用鏈能夠遍歷到的對象就是活著的。GC Roots 包括棧里的局部變量引用、靜態(tài)變量引用、JNI 引用等。當(dāng)一個對象不再被任何 GC Roots 引用時它就變成了垃圾等待 GC 回收。舉個具體例子public void test() { Person p new Person(); // 棧上 p 引用堆中對象 p null; // p 不再指向那個對象 // 此時堆里的 Person 對象沒有被任何引用指著了成為可回收對象 }注意把p置為 null 只是切斷了這條引用鏈對象并不會立刻被回收。GC 的具體回收時機取決于 JVM 的垃圾回收策略可能是下一次 Minor GC也可能更晚。這也是個面試愛問的點。這個可達(dá)性分析的機制恰恰是理解類與對象關(guān)系的延伸——對象是活躍的、有生命周期的而類只要被加載一次就會一直待在元空間里直到 JVM 退出。一個可能被回收一個幾乎永生這就是本質(zhì)區(qū)別的一部分。3. 類與對象的核心差異從定義、內(nèi)存到數(shù)量的多維對照3.1 五個維度拆開對比為了讓你看得更清晰我把類與對象的差異整理成一張多維對照表對比維度類Class對象Object性質(zhì)抽象的概念、模板、數(shù)據(jù)類型具體的實體、實例、數(shù)據(jù)載體存在位置編譯期是 .class 文件運行期是元空間的 Class 對象運行期對象實例存在于堆內(nèi)存創(chuàng)建方式通過編寫代碼定義由 JVM 類加載器裝載通過 new、反射、反序列化等創(chuàng)建數(shù)量關(guān)系一個類在內(nèi)存中只有一個對應(yīng)的 Class 對象一個類可以創(chuàng)建無數(shù)個對象實例是否有狀態(tài)類的描述信息幾乎不變靜態(tài)成員可變更但依附類對象每個對象都有獨立的實例變量狀態(tài)生命周期從類加載到 JVM 退出全局唯一、幾乎長生從創(chuàng)建到不再被引用可能隨時被 GC能否直接操作可以通過反射操作 Class 對象可以通過引用直接調(diào)用方法、訪問屬性這張表背下來容易但你要能對著每一行講出背后為什么才算真懂。拿數(shù)量關(guān)系這一行舉例。為什么一個類只有一個 Class 對象因為類加載器的緩存機制——每次加載類之前都會先去查緩存緩存里有了就返回同一個。這保證了Person.class Class.forName(Person)這種比較在同一個類加載器環(huán)境下永遠(yuǎn)為 true。而對象就不一樣了new Person()每次都會在堆里劃一片新內(nèi)存所以new Person() new Person()永遠(yuǎn)是 false除非 Person 重寫了 hashCode 和 equals但那是另一個話題。再拿是否有狀態(tài)這一行舉例。類的靜態(tài)變量確實可以變但記住它是全局唯一的一份所有對象共享。而對象的實例變量是每個對象各一份。這直接決定了靜態(tài)成員適合放什么——全局配置、常量、工具方法但絕對不適合放和某個具體對象綁定的數(shù)據(jù)。3.2 類型Type與實例Instance的關(guān)系在生活中并不難找如果想找一個生活化的類比我自己的體會是類是一枚印章對象是蓋出來的一個個印痕。印章本身刻著認(rèn)證通過四個字這是它的類定義——規(guī)定了印出來的效果是什么樣。但你拿這枚印章在十份文件上蓋了十個印每一個印痕都獨立存在于一張紙上有自己的位置內(nèi)存地址、有自己的紙張生命周期可回收。你蓋壞了其中一張紙上的印其他紙上的印不受影響——這就對應(yīng)了每個對象實例變量獨立。而印章本身不會因為蓋了十次就消失它還好好躺在那里——這就對應(yīng)了 Class 對象一直存在。還有一個類比也常用類就像菜譜對象就像按菜譜炒出來的每一盤菜。菜譜是文字是抽象的概念它可以被十萬家餐館參考但每一盤菜端上桌都是獨立的一盤色香味各自有差異吃完了GC 回收菜譜還在。這類比的妙處在于它天然解釋了為什么類是抽象、對象是具體——抽象意味著不占用實際的桌面空間具體意味著真實存在于某個位置。理解了這兩個詞的本質(zhì)比記住定義有用得多。3.3 表達(dá)式必須包含類類型一個經(jīng)典的報錯背后就是類型混淆搜熱詞的時候看到不少人查表達(dá)式必須包含類類型這個報錯這個問題非常典型它正是類與對象混淆的直接體現(xiàn)。這個報錯通常出現(xiàn)在你寫xxx.class這種語法時xxx不是一個類而是一個對象。比如Person p new Person(); String className p.class.getName(); // 編譯報錯表達(dá)式必須包含類類型正確寫法應(yīng)該是String className Person.class.getName(); // 或者 String className p.getClass().getName();為什么p.class不行因為.class這個語法是一個字面量只在類名上有效用于獲取這個類的 Class 對象。而對象的類型信息要通過getClass()這個實例方法來拿由 Object 類繼承而來。一個是編譯期就確定的類字面量一個是運行期動態(tài)返回的運行時類型兩者雖然最終都指向同一個 Class 對象但使用語法完全不同。很多報這個錯的開發(fā)者實際上就是沒搞清楚類名和對象引用在語法層面的分工。類名是類型的靜態(tài)入口對象引用是實例的動態(tài)入口二者不能混用。把這個錯誤弄懂了你對類與對象的邊界感會提升一大截。4. 實戰(zhàn)中那些和類與對象糾纏最深的坑4.1 判斷對象為空的幾種方式以及 Optional 的正確打開方式判斷對象為空這個需求幾乎是天天寫。最樸素的方式是if (obj ! null)新手都會。但后端開發(fā)里真正普遍的場景是你從一個接口拿到一個對象這個對象可能不為 null但它內(nèi)部的某個關(guān)聯(lián)字段可能是 null或者你調(diào)用的方法返回的可能是一個 Optional。這里有個值得展開的細(xì)節(jié)Optional本身就是一個容器對象你用Optional.of(obj)來包裝時如果 obj 是 null會直接拋NullPointerException只有用Optional.ofNullable(obj)才是安全的。很多新手在這里栽跟頭本質(zhì)上是沒理解 Optional 是一個對象它內(nèi)部持有的引用可以為 null 這層關(guān)系。再舉一個真實業(yè)務(wù)場景。假設(shè)你有一個Order對象需要判斷它的getAddress()是否為空并且不為空時取出城市名。初級寫法是這樣if (order ! null) { Address addr order.getAddress(); if (addr ! null) { String city addr.getCity(); // ... } }這種層層判空的代碼用 Optional 改造后會清爽很多但也隱藏著對對象模型的理解要求Optional.ofNullable(order) .map(Order::getAddress) .map(Address::getCity) .ifPresent(city - { /* ... */ });注意map的每一步輸入是一個對象輸出是另一個對象或者 null這個鏈?zhǔn)秸{(diào)用能成立的前提是每個方法調(diào)用都發(fā)生在對象層面而 Optional 就是一個包裝對象的對象。如果你不清楚對象之間的關(guān)系會非常容易寫出鏈到一半 NPE的代碼。4.2 對象賦值頁面不變引用共享與不可變對象的糾纏看熱詞里有vue對象賦值頁面不變雖然這是個前端問題但它的根子和 Java 的對象賦值如出一轍。前端是這樣你給一個 Vue 響應(yīng)式對象新增屬性頁面不刷新因為新增的屬性沒走 Vue 的響應(yīng)式劫持。后端的對應(yīng)場景是你修改了對象但緩存、日志、下游系統(tǒng)統(tǒng)統(tǒng)感知不到變化。在 Java 里這類問題的核心往往在于——你賦值的時候是把引用賦過去了還是把內(nèi)容復(fù)制過去了。看這個經(jīng)典誤區(qū)ListString list1 new ArrayList(); list1.add(A); ListString list2 list1; // 這不是復(fù)制是讓 list2 指向同一個對象 list2.add(B); System.out.println(list1.size()); // 輸出 2很多人下意識以為list2 list1是把 list1 的數(shù)據(jù)拷了一份給 list2。不是。list2 和 list1 是兩個引用變量但綁定的是同一個 ArrayList 對象。你要真的復(fù)制內(nèi)容得new ArrayList(list1)或者調(diào)用clone()。這段邏輯放到類與對象的語境下就是那句老話的復(fù)現(xiàn)對象是堆上的獨立實體引用是棧上的遙控器。你在業(yè)務(wù)代碼里做的賦值絕大多數(shù)情況下只是復(fù)制了遙控器并沒有復(fù)制電視機。還有一個相關(guān)的坑是 String 的不可變性。String 對象一旦創(chuàng)建內(nèi)容不可變所有看似修改字符串的操作比如replace、concat實際都是生成新的 String 對象。這也是對象生命周期特性的體現(xiàn)——有些對象設(shè)計成不可變就是為了安全地在多處引用共享中傳遞不擔(dān)心被意外改動。4.3 動態(tài)代理類、Class 對象、代理對象三者如何協(xié)作動態(tài)代理是 Java 面試八股文里的高頻考點也是理解類與對象關(guān)系的一個極佳實戰(zhàn)切入點。Java 動態(tài)代理的核心類是java.lang.reflect.Proxy。當(dāng)你調(diào)用Proxy.newProxyInstance(ClassLoader, interfaces, InvocationHandler)時JVM 會在運行期動態(tài)生成一個代理類一個全新的 Class 對象然后用這個新的類創(chuàng)建出代理對象。這個過程里類和對象的關(guān)系被體現(xiàn)得淋漓盡致Proxy.newProxyInstance的第一個參數(shù) ClassLoader決定了新的代理類由哪個類加載器來加載第二個參數(shù) interfaces是代理類要實現(xiàn)的接口列表——代理類是根據(jù)這些接口的元數(shù)據(jù)現(xiàn)場生成的。生成代理類的時候JVM 實際上是動態(tài)構(gòu)造了一套字節(jié)碼然后把這個字節(jié)碼加載成 Class 對象。這個 Class 對象和你手寫的那些類沒有什么本質(zhì)區(qū)別同樣可以 new 出多個代理對象實例。當(dāng)你調(diào)用代理對象的方法時方法調(diào)用不會執(zhí)行代理類自身寫好的邏輯而是被轉(zhuǎn)發(fā)到 InvocationHandler 的invoke方法。為什么能做到這一點因為代理類在生成時每個方法的實現(xiàn)體里都寫了一段調(diào)用 handler.invoke(this, method, args)的字節(jié)碼。從類與對象的視角看動態(tài)代理的本質(zhì)就是在運行期動態(tài)創(chuàng)建一個新類再基于這個類創(chuàng)建對象并讓所有方法調(diào)用都走統(tǒng)一的攔截器。如果你只懂類是模板、對象是實例這個層面你是無法理解動態(tài)代理的——因為你意識不到類這個東西在運行期是可以被動態(tài)創(chuàng)造出來的。4.4 抽象類和普通類的區(qū)別對類本身的進(jìn)一步細(xì)分熱詞里還有抽象類和普通類的區(qū)別這也是個老生常談但常問常新的點。從類與對象的本質(zhì)區(qū)別延伸下去你會發(fā)現(xiàn)類本身也不是鐵板一塊。抽象類和普通類最大的區(qū)別在于能否被實例化——抽象類不能 new普通類可以。但這句話背后隱藏的問題是為什么 abstract 修飾的類就不能 new根本原因是抽象類里可能含有抽象方法這些方法只有聲明沒有實現(xiàn)體。如果一個抽象類可以被 new那么 new 出來的對象調(diào)用一個沒有實現(xiàn)體方法的時候JVM 根本不知道該執(zhí)行什么字節(jié)碼。所以 Java 語法層面直接禁止了抽象類的實例化——不是沒必要而是邏輯上不允許。但注意抽象類不能 new不代表它沒有構(gòu)造方法。抽象類可以有構(gòu)造方法而且它的構(gòu)造方法是給子類用的——子類實例化的過程中會通過super()隱式調(diào)用父類的構(gòu)造方法。這是繼承體系下對象創(chuàng)建鏈的體現(xiàn)一個子類對象的完整創(chuàng)建過程會從最頂層的父類一路初始化下來。這種機制也解釋了為什么抽象類參與繼承體系這件事比能否實例化更值得關(guān)注。在實際業(yè)務(wù)中抽象類最常見的用法是模板方法模式——父類定義好流程骨架普通方法把某些具體步驟留給子類去實現(xiàn)抽象方法。這時候類不僅僅是對象的模板它還是家族祖輩的規(guī)矩制定者。這個層級遞進(jìn)也是普通類和抽象類在面向?qū)ο笤O(shè)計里的不同站位。4.5 類加載與類初始化什么時候類會被激活熱詞里有類加載這是我前文提過但沒有完全展開的部分。它和類與對象的關(guān)系在于你常聽到的靜態(tài)代碼塊哪個先執(zhí)行子類和父類靜態(tài)塊順序這類問題考察的就是類加載時機的理解。類加載時機我記得很清楚下面這幾個場景會觸發(fā)類的初始化new 一個類的實例對象訪問或者賦值類的靜態(tài)變量注意用 final 修飾的編譯期常量除外調(diào)用類的靜態(tài)方法使用反射比如Class.forName(Person)初始化一個類時如果它的父類還沒初始化會先觸發(fā)父類初始化這個順序是面試官最喜歡的連環(huán)問。比如問有一個父類 A 和一個子類 B它們都有靜態(tài)代碼塊和構(gòu)造代碼塊第一次new B()的時候執(zhí)行的順序是什么答案應(yīng)該是A 的靜態(tài)代碼塊 - B 的靜態(tài)代碼塊 - A 的構(gòu)造代碼塊 - A 的構(gòu)造方法 - B 的構(gòu)造代碼塊 - B 的構(gòu)造方法。這個順序背后的邏輯是先類加載靜態(tài)成員屬于類后對象創(chuàng)建實例變量屬于對象。類只有一份所以靜態(tài)塊只執(zhí)行一次對象每次 new 都會經(jīng)歷構(gòu)造流程。把類和對象是兩套生命周期這條主線理清了這類順序題就變得非常樸素。5. 面試場上怎么把這個問題答出層次感5.1 從背定義到講原理一個遞進(jìn)式的回答思路如果你去面試被問到類與對象的區(qū)別我建議你按照下面的層次遞進(jìn)回答而不是只甩一句類是模板對象是實例。第一層先說定義類是對一組具有相同屬性和行為的對象的抽象描述是數(shù)據(jù)類型對象是類的一個具體實例是真實存在于內(nèi)存中的數(shù)據(jù)載體。第二層說創(chuàng)建方式類是寫代碼定義的由編譯器編譯成 .class 文件再由類加載器加載進(jìn) JVM在元空間生成對應(yīng)的 Class 對象對象通過 new 關(guān)鍵字在堆內(nèi)存中分配空間并初始化返回給調(diào)用者的是一個引用。第三層說內(nèi)存與生命周期類的 Class 對象全局唯一生命周期伴隨 JVM 運行對象可以創(chuàng)建多個生命周期受可達(dá)性分析控制不再被引用后會被 GC 回收。第四層說使用方式靜態(tài)成員直接依附于類通過類名即可訪問實例成員必須通過對象引用來訪問。如果你能一口氣說到第三層面試官基本能確認(rèn)你不是背題的。如果還能順手舉一個動態(tài)代理或者反射的例子說明類在運行期也能被動態(tài)生成那這道題的回答質(zhì)量會相當(dāng)高。因為這些例子證明了你不只是懂類與對象的靜態(tài)區(qū)別而是理解它們在 JVM 運行時的真實協(xié)作關(guān)系。這類經(jīng)驗我建議在面試前自己口頭多練幾遍。很多人心里明白但一緊張就漏到第二層就斷了。按照這個遞進(jìn)結(jié)構(gòu)背熟答題的時候會穩(wěn)得多。5.2 高頻追問清單面試官挖坑的四個方向面試官問完類與對象的區(qū)別之后通常還有一系列追問。我把常見的追問方向列一下每一個都指向一個具體的知識盲區(qū)追問一一個類可以有幾個對象多個對象之間共享哪些數(shù)據(jù)獨立哪些數(shù)據(jù)這個問題的本質(zhì)是考察靜態(tài)成員與實例成員的存儲位置差異以及對象之間數(shù)據(jù)隔離的理解。追問二對象相等和引用相等的區(qū)別這里要用到和equals的對比。引用相等比較的是棧上的地址值對象相等比較的是堆上對象的內(nèi)容默認(rèn)的 equals 等價于重寫之后才能比較內(nèi)容。這背后恰恰是引用與對象分離這個模型在起作用。追問三構(gòu)造方法能不能被繼承很多人會脫口而出能。準(zhǔn)確說是構(gòu)造方法不會被子類繼承但子類構(gòu)造方法會隱式調(diào)用父類無參構(gòu)造方法super()如果父類只有有參構(gòu)造子類構(gòu)造方法必須顯式調(diào)用。這個追問的考點是對象創(chuàng)建鏈的完整性。追問四靜態(tài)方法能不能被重寫答案是不能。如果子類定義了一個和父類靜態(tài)方法簽名完全相同的方法那是隱藏而不是重寫調(diào)用哪個取決于引用變量的編譯期類型而不是運行期類型。這個考點實際上還是在區(qū)分屬于類和屬于對象這兩種綁定機制。每個追問你都可以把話題繞回到類與對象的關(guān)系上因為這些問題本來就是對這一核心關(guān)系的多角度考察。5.3 從八股文到實戰(zhàn)回答這類問題時的一個額外加分項面試?yán)锕獍阎R點講對只能算及格想拿高分最好結(jié)合業(yè)務(wù)場景。比如你可以這樣說我之前做權(quán)限系統(tǒng)的時候用策略模式定義了一個抽象類AbstractAuthStrategy里面用模板方法定義了校驗流程具體的 token 解析邏輯交給不同子類去實現(xiàn)。這里抽象類是骨架、子類對象是具體策略。后來需要對某些接口做動態(tài)權(quán)限增強又用 JDK 動態(tài)代理生成了代理對象在 invoke 里統(tǒng)一做了日志記錄和異常兜底。這個過程中我明顯感覺到類描述規(guī)則、對象承載狀態(tài)、代理類動態(tài)生成這三種角色在運行時各司其職。這段話的本質(zhì)是把類與對象的知識點平移到真實工程里展示你對它的理解不只是停留在語法層面。面試官聽到這種回答會認(rèn)為你是真正用面向?qū)ο笏枷朐趯懘a的。別小看這個加分項在八股文滿天飛的年代能把基礎(chǔ)概念講出工程味道的人太少了。6. 結(jié)尾一個小技巧與你最后分享一個我自己的體會。教初學(xué)者理解類與對象最有效的類比不是圖紙與房子而是印章與印痕。圖紙和房子的關(guān)系容易讓人誤以為類需要被照搬一次才變成對象但準(zhǔn)確地說對象是每一次使用類時產(chǎn)生的獨立實體。印章蓋下的每一個印痕都是獨立的印章本身永遠(yuǎn)是那個印章印痕卻各有歸屬、早晚會模糊消散。這個類比把類唯一、對象多態(tài)、對象有生命周期三個特性一把全說清楚了。還有一個小技巧如果你正在學(xué)或者正在復(fù)習(xí) Java 基礎(chǔ)我建議你養(yǎng)成一個習(xí)慣在 IDEA 里用斷點調(diào)試去觀察對象。new 一個對象之后展開調(diào)試面板里的對象引用你能看到對象頭和實例變量的值用上 JOLJava Object Layout插件還能直接打印出一個對象在內(nèi)存里占了多少字節(jié)對象頭里有什么。這種親眼所見帶來的理解比看十篇博客都深刻。類與對象這個話題乍一看是最簡單的基礎(chǔ)題細(xì)究下去卻連接著類加載、內(nèi)存模型、反射、代理、GC 這一整棵 Java 知識樹。把這道地基打牢了后面每一層樓都蓋得安心。