1. 先給一個可復(fù)現(xiàn)的多米諾記憶游戲原型1.1 一張牌的兩個數(shù)字是所有隱藏Bug的起點多米諾記憶游戲的玩法很簡單桌面上扣著N張牌每張牌印著一組多米諾點陣左區(qū)間數(shù)字 右區(qū)間數(shù)字比如[2|3]。玩家每次翻開兩張如果兩張牌的點數(shù)組合完全一致就消除這對牌如果點數(shù)對不上就把它們翻回去。全程累計翻錯次數(shù)超過上限就判負(fù)。這個游戲用來練手Java再合適不過——有對象建模、有集合操作、有狀態(tài)機(jī)、有UI事件甚至還能捎帶講一波算法和內(nèi)存問題。多數(shù)人寫它的時候都會覺得邏輯這么簡單能出什么錯但真實項目里往往就是這種看起來人畜無害的小東西能把Java對象比較的底褲扒得干干凈凈。常見的實現(xiàn)方式是先創(chuàng)建一副牌組比如24對共48張把DominoCard對象放進(jìn)一個List然后Collections.shuffle()洗牌再按4行12列擺到面板上。每張DominoCard有l(wèi)eftValue、rightValue兩個數(shù)字字段外加faceUp和matched兩個布爾狀態(tài)。玩家點擊桌面上一張未翻開的牌時把它翻開再點另一張時拿這兩張牌做匹配判斷。命中的話兩張都變成matchedtrue一定時間后繼續(xù)沒命中的話等展示時間結(jié)束再翻回去同時失敗次數(shù)mistakeCount加1。到這里為止一切聽起來都很順暢但真正上線跑起來問題就開始冒頭了。最典型的就是兩張明明應(yīng)該配對的牌永遠(yuǎn)顯示不匹配。我就見過好幾個朋友的初版代碼卡在這里而且更迷惑的是他們核對數(shù)值時發(fā)現(xiàn)數(shù)字明明一樣為什么程序就是說不相等這就要從最基礎(chǔ)的比較邏輯開始查起。1.2 核心類結(jié)構(gòu)與匹配流程的簡化版為了把問題說清楚我先給出一個簡化但完整的核心模型。DominoCard的典型寫法長下面這樣public class DominoCard { private final int leftValue; private final int rightValue; private boolean faceUp; private boolean matched; public DominoCard(int leftValue, int rightValue) { this.leftValue leftValue; this.rightValue rightValue; } public boolean isFaceUp() { return faceUp; } public void setFaceUp(boolean faceUp) { this.faceUp faceUp; } public boolean isMatched() { return matched; } public void setMatched(boolean matched) { this.matched matched; } // getter... }游戲主控部分的核心匹配邏輯早期版本通常長這樣public boolean isMatch(DominoCard a, DominoCard b) { return a b; }這就是第一顆雷。如果a和b是兩個不同的實例哪怕它們的leftValue和rightValue完全一樣也只會返回false。你可能會說誰會這么寫——現(xiàn)實中真的有人這么寫。原因往往是最初誤以為可以比較內(nèi)容或者從某些簡易教程里抄來了這個寫法自己也沒跑過完整的成對測試。更隱蔽的情況是有些老代碼在某個階段曾經(jīng)用枚舉或池化對象管理牌面那時候可能碰巧成立后來改了數(shù)據(jù)模型比較邏輯卻沒跟著改Bug就一直潛伏著。如果這關(guān)過了緊接著的另一顆雷是字段類型。假設(shè)把leftValue和rightValue定義成了Integer很多初學(xué)者或從某些代碼規(guī)范里繼承下來的人會這樣寫然后在匹配時用a.getLeftValue() b.getLeftValue()來比較那就會觸發(fā)Integer的緩存機(jī)制-128~127范圍內(nèi)會返回true超過這個范圍就返回false。而多米諾骨牌上的點數(shù)通常剛好在1~6之間于是所有同點數(shù)的牌在下都相等看起來游戲跑得好好的。但這是一種錯覺它掩蓋了真正的對象比較問題。2. 復(fù)現(xiàn)相同牌面卻永遠(yuǎn)配對不成功的Bug2.1 真實癥狀同一對牌時好時壞先把 Bug 現(xiàn)場還原一下。一個剛寫出來的多米諾記憶游戲點擊兩張[3|4]的牌正常情況下應(yīng)該配對成功、兩張牌從桌面消失。但實際表現(xiàn)是大部分情況下點擊完直接彈回仿佛你點錯了偶爾幾次又能成功。為什么偶爾因為如果匹配代碼存在字段是Integer但值恰好落在緩存區(qū)間和字段是int但兩個對象恰好來自同一個內(nèi)部池比如某些單例工廠或常量復(fù)用兩種情況時的表現(xiàn)就會變得非常跳躍時而相等、時而不相等。我排查時最喜歡用的切入點是先把表象拆開判斷到底是數(shù)據(jù)不同還是比較方式不同。所以第一步不是去看比較代碼而是先打日志把兩張被點擊的牌的leftValue、rightValue、對象內(nèi)存地址也就是System.identityHashCode()全部打出來。日志一出來真相往往就藏不住了牌面數(shù)值一樣但兩個對象的身份哈希完全不一樣說明它們就是兩個獨立的實例。這時候再去讀比較代碼基本一眼就能鎖定。2.2 排查鏈路從行為異常到最終根因這里我把排查過程完整寫出來方便你以后遇到類似問題時照著這個思路走。第一層確認(rèn)是否真的進(jìn)入過匹配分支。有些時候卡片配對不成功不是比較邏輯的問題而是點擊事件壓根沒觸發(fā)第二次。所以先在isMatch入口打一行日志確認(rèn)兩個參數(shù)都非空、都來自被點擊的牌。這個檢查建議永遠(yuǎn)放在最前面避免在錯誤方向上浪費幾個小時。第二層用equals和分頭驗證數(shù)據(jù)。在日志里分別輸出a b、a.equals(b)、a.getLeftValue() b.getLeftValue()和兩個對象的完整字段。早期版本寫的是a b所以a.equals(b)大概率也是false——因為Object.equals默認(rèn)就是。而字段比較的結(jié)果會暴露另一個線索如果值是Integer且在-128~127區(qū)間字段用比較會返回true這就解釋了為什么偶爾成功——因為Integer緩存救了它救得了一時救不了一世。第三層排除并發(fā)或時序干擾。有些項目里點擊事件和動畫回調(diào)是異步的第一次翻開還沒完成時第二次點擊已經(jīng)進(jìn)來了導(dǎo)致比較時拿到的是同一個對象或半初始化對象。這一層要檢查faceUp標(biāo)志位是否正確設(shè)置、是否在比較前就做了狀態(tài)翻轉(zhuǎn)。我見過不止一次游戲配對失敗的根因不是比較而是因為第一張牌在翻開動畫結(jié)束前就被標(biāo)記成了已翻轉(zhuǎn)第二張牌點擊后狀態(tài)判斷直接跳過導(dǎo)致永遠(yuǎn)走不到比較分支。第四層追到根因把比較邏輯替換成基于字段或基于equals的實現(xiàn)。這層完成后Bug 表面終結(jié)。但我要提醒你替換成equals之后如果只重寫equals不重寫hashCode那只是把噩夢從匹配失敗換成了放進(jìn)集合時行為異常問題并沒有真正結(jié)束。2.3 第一輪修復(fù)改用值比較后為什么只是暫時看起來正常第一輪修復(fù)的常見做法是把a(bǔ) b改成public boolean isMatch(DominoCard a, DominoCard b) { return a.getLeftValue() b.getLeftValue() a.getRightValue() b.getRightValue(); }如果getLeftValue()返回的是int這段代碼在點數(shù)1~6的牌面上是完全行得通的。但假如leftValue是Integer這個寫法在-128~127區(qū)間內(nèi)依舊能通過而一旦游戲需求擴(kuò)展成點數(shù)范圍更廣的多米諾牌比如支持 0~9、甚至支持超過 127 的編號Integer緩存不夠用的時候同樣的代碼就會突然大面積失效。第一輪修復(fù)之所以是看起來正常是因為數(shù)據(jù)范圍恰好落進(jìn)了緩存區(qū)把問題埋得更深了。真正可靠的修復(fù)方式是為DominoCard重寫equals和hashCode然后用equals去比較。下面這篇博文的核心部分就是圍繞到底該怎么重寫才算合格展開的。3. 從一行比較代碼展開的Java對象比較體系3.1 到底在比什么引用還是內(nèi)容在Java里的語義非常明確比較兩個引用變量是否指向堆內(nèi)存中的同一個對象。它不是比較內(nèi)容而是比較地址。哪怕兩個對象的字段完全一致只要它們是通過兩次new創(chuàng)建出來的就是false。用一個生活化的類比比較的是是不是同一個人而equals比較的是是不是同一張身份證對應(yīng)的合法身份或者兩個人的姓名、出生日期等關(guān)鍵信息是否一致。記憶游戲里的兩張[3|4]牌相當(dāng)于兩個外表完全相同的人但它們是兩個獨立的個體。你用是不是同一個人來判斷它們是否配對自然永遠(yuǎn)失敗。面試?yán)镒罱?jīng)典的問法就是兩個對象內(nèi)容一樣返回false為什么 答案就在引用語義上。但面試官第二個問題通常會接上那equals有沒有可能返回true 這就需要看這個類有沒有重寫過equals方法。如果沒重寫Object.equals默認(rèn)實現(xiàn)就是結(jié)果只能是false。3.2 equals與hashCode一對必須同生共死的契約equals方法在Java對象體系中承擔(dān)的職責(zé)是定義邏輯相等。默認(rèn)情況下如果沒有重寫它的行為與完全一致。但很多業(yè)務(wù)場景需要我們自定義什么才算相等——比如兩張多米諾牌leftValue和rightValue一致就算同一張。重寫equals時必須遵循幾條硬性約定自反性x.equals(x)必須為true對稱性x.equals(y)與y.equals(x)結(jié)果一致傳遞性如果x.equals(y)且y.equals(z)那么x.equals(z)也必須為true一致性只要對象內(nèi)容不變多次調(diào)用equals結(jié)果不變非空性x.equals(null)必須為false與equals綁定的另一條鐵律是重寫equals必須重寫hashCode。原因是Java 中所有基于哈希的集合HashMap、HashSet、Hashtable都依賴先算hashCode定位桶再通過equals精確比較。如果兩個對象equals相等但hashCode不同它們在哈希表中會被分到不同的桶HashMap.get()永遠(yuǎn)找不到目標(biāo)HashSet也會出現(xiàn)內(nèi)容相同卻能重復(fù)放入的詭異現(xiàn)象。hashCode的約定是如果兩個對象按equals比較相等那么它們的hashCode必須相等如果兩個對象的hashCode相等它們不一定equals相等這是允許的哈希沖突只要對象內(nèi)容不變多次調(diào)用hashCode返回值應(yīng)一致3.3 String與Integer的緩存陷阱為什么感覺相等卻沒有真正相等Java里有兩個極其經(jīng)典的緩存機(jī)制經(jīng)常讓人在比較時栽跟頭。第一個是字符串常量池。如下代碼String s1 java; String s2 java; System.out.println(s1 s2); // true因為兩個字面量都指向常量池中的同一個對象但這并不代表String的可以安全使用。改成這樣String s3 new String(java); String s4 new String(java); System.out.println(s3 s4); // false因為創(chuàng)建了兩個不同實例如果s3.intern()之后再與s1比較結(jié)果又變成true了。可見String的結(jié)果完全取決于對象是否從常量池來很容易被誤導(dǎo)。第二個是Integer緩存。Integer默認(rèn)緩存了-128~127之間的對象所以Integer a 100; Integer b 100; System.out.println(a b); // true走緩存 Integer c 200; Integer d 200; System.out.println(c d); // false超過緩存范圍創(chuàng)建了新對象如果項目里用Integer存多米諾點數(shù)恰好點數(shù)都在1~6那么card1.getLeftValue() card2.getLeftValue()會表現(xiàn)出假的相等。這個假象一旦遇到超過127的點數(shù)就會瞬間擊穿。這類問題的通用結(jié)論是基本類型用對象類型一律用equals或Objects.equals。對于Integer、String這類值對象永遠(yuǎn)不要依賴。這是面試高頻考點也是實際項目里最容易引發(fā)線上偶發(fā)Bug的根因之一。3.4 自定義對象的equals要怎么寫才算合格結(jié)合多米諾記憶游戲的場景DominoCard的equals應(yīng)該判斷牌面點數(shù)組合是否一致。不過這里還有一個隱藏需求[1|2]和[2|1]算不算同一張牌從純邏輯上講很多游戲規(guī)則會認(rèn)為算因為牌面由兩個數(shù)字組成左右順序只是顯示布局。當(dāng)然也可以指定必須完全一致這取決于需求。但作為一個通用設(shè)計equals應(yīng)該體現(xiàn)業(yè)務(wù)語義所以我實現(xiàn)時會同時兼容左右互換Override public boolean equals(Object o) { if (this o) return true; if (o null || getClass() ! o.getClass()) return false; DominoCard that (DominoCard) o; boolean direct this.leftValue that.leftValue this.rightValue that.rightValue; boolean reversed this.leftValue that.rightValue this.rightValue that.leftValue; return direct || reversed; } Override public int hashCode() { // 組合時考慮順序無關(guān)性 int sum leftValue rightValue; int diff Math.abs(leftValue - rightValue); return Objects.hash(sum, diff); }用sum和diff的組合作為哈希值可以保證左右順序互換的牌得到相同的hashCode。這個技巧很適合用來回答如果equals里做了順序無關(guān)判斷hashCode該怎么寫這類面試題。這里有幾個細(xì)節(jié)值得展開講講。第一getClass() ! o.getClass()的寫法在處理繼承時會變得很嚴(yán)格。如果DominoCard有子類父類和子類實例永遠(yuǎn)不會相等。另一種常見寫法是用instanceofif (!(o instanceof DominoCard)) return false;instanceof允許子類與父類之間比較但對hashCode的一致性要求更高因為子類可能擴(kuò)展了新字段破壞了對稱性。在實際項目中如果實體類沒有繼承層級getClass()更安全如果有多態(tài)需求instanceof更靈活但需要保證equals仍然遵守對稱性。第二equals里不要做太多額外計算。像上面的寫法先比較字段再Objects.hash也行但直接字段比較性能更好。對記憶游戲這種高頻點擊場景字段比較足夠了。第三hashCode不要用死板的Objects.hash(leftValue, rightValue)直接懟上去因為那會讓順序無關(guān)的[1|2]和[2|1]產(chǎn)生不同哈希。雖然哈希值不同不至于讓equals失效比如放在ArrayList里就無所謂但放進(jìn)HashMap、HashSet時就會出問題所以必須嚴(yán)格保證equals 相等則 hashCode 相等。4. 修復(fù)后的完整代碼與連帶Bug清理4.1 修復(fù)后的匹配邏輯對比把equals和hashCode修好之后匹配判斷就變得極簡public boolean isMatch(DominoCard a, DominoCard b) { return a.equals(b); }與初版對比差別一目了然比較方式初版修復(fù)版比較目標(biāo)引用是否相同業(yè)務(wù)內(nèi)容是否相同同值不同實例falsetrue左右互換判定不支持支持按需求放入HashSet/HashMap可能重復(fù)正常去重隱患隱藏的Integer緩存依賴無這個表也方便你寫復(fù)盤文檔時直接引用。4.2 順藤摸瓜狀態(tài)機(jī)與步數(shù)邊界修完匹配邏輯只是第一步。很多項目里的Bug是連環(huán)的你把第一個Bug按下去第二個Bug才浮出水面。這個記憶游戲也不例外。我在實際測試中就遇到過連續(xù)快速點擊三張牌游戲狀態(tài)直接錯亂。因為翻牌匹配是一個有狀態(tài)的過程理想狀態(tài)機(jī)應(yīng)該是enum GameState { IDLE, // 等待第一張牌翻開 ONE_FLIPPED, // 已翻開第一張等待第二張 RESOLVING, // 兩張已翻開正在做匹配或動畫 }當(dāng)玩家點擊時需要根據(jù)當(dāng)前狀態(tài)決定是否允許這次點擊。初版代碼往往只判斷了牌是否已經(jīng)翻開沒判斷當(dāng)前是否在動畫處理中于是第三張牌就能在RESOLVING狀態(tài)下被翻開導(dǎo)致三張牌同時展示狀態(tài)錯亂。修復(fù)方式是在點擊入口加狀態(tài)判斷public void onCardClicked(DominoCard card) { if (gameState GameState.RESOLVING) return; // 動畫期間忽略點擊 if (card.isFaceUp() || card.isMatched()) return; // 正常處理... }另一個高頻Bug是失敗次數(shù)邊界。假設(shè)游戲規(guī)則是最多允許10次翻錯初版可能寫成if (mistakeCount 10) { gameOver(); }這會導(dǎo)致第11次失敗才觸發(fā)游戲結(jié)束而用戶已經(jīng)多玩了1次。正確寫法是if (mistakeCount 10) { gameOver(); }這類邊界問題雖然和對象比較無關(guān)但和邏輯修復(fù)的主題高度契合。排查時可統(tǒng)一使用邊界值驗證法把次數(shù)分別設(shè)為9、10、11觀察程序是否按預(yù)期在第10次結(jié)束。4.3 回歸測試清單修完所有Bug后一定要做一輪完整的回歸測試。我給自己列過一份清單每次改完都能直接復(fù)用兩張相同點數(shù)的牌能否配對成功兩張不同點數(shù)的牌是否配對失敗且計數(shù)加1[1|2]與[2|1]是否按需求視為同一對連續(xù)快速點擊三張牌狀態(tài)是否穩(wěn)定第10次失敗是否觸發(fā)游戲結(jié)束第9次失敗后游戲是否還能繼續(xù)點擊已matched的牌是否被忽略洗牌后List中是否還有重復(fù)對象引用比如同一張牌被放入了兩次使用HashSet存放已配對牌時能否正確去重這份清單不僅能用于這個游戲凡是涉及對象比較、狀態(tài)機(jī)、邊界條件的項目基本都能套用。5. 面試官視角這些坑會以什么方式考你5.1 必問的 /equals/hashCode 連環(huán)題搜索熱詞里頻繁出現(xiàn) java面試題、java基礎(chǔ)、java八股文說明這類問題確實是面試重災(zāi)區(qū)。根據(jù)我踩過的坑和面試官朋友反饋最常見的連環(huán)題是這樣的第一問和equals的區(qū)別是什么 答出比較引用equals比較內(nèi)容前提是重寫算基礎(chǔ)分。第二問不重寫equals會怎樣 這時要能答出默認(rèn)Object.equals等同于。第三問重寫equals時為什么必須重寫hashCode 這里要展開HashMap底層的先哈希后比較機(jī)制。如果你能把HashSet去重的底層流程講清楚基本就能讓面試官點頭。第四問進(jìn)階如果某個類的hashCode每次都返回同一個固定值有什么后果 答案是所有元素都會落在同一個哈希桶里導(dǎo)致查詢性能退化成鏈表順序查找嚴(yán)重時接近O(n)。這題考的是對哈希沖突的理解。第五問高頻Integer的什么時候返回true 能答出-128~127緩存區(qū)間并且指出Integer.valueOf會走緩存但new Integer不會就是滿分答案。第六問幾乎是必考題HashMap的查找流程是什么 標(biāo)準(zhǔn)回答是先計算key.hashCode()定位到具體桶若桶內(nèi)是鏈表或紅黑樹結(jié)構(gòu)再用equals逐個比較若命中則返回對應(yīng)value。如果有多個對象的hashCode相同桶內(nèi)會形成鏈表JDK 8 之后鏈表長度超過閾值會轉(zhuǎn)成紅黑樹。這個回答能把哈希、equals、性能三個點串起來。5.2 更深一層的坑String池、Integer緩存與HashMap面試中把基礎(chǔ)題答完之后能不能從基礎(chǔ)題延伸到更深一層的坑往往是區(qū)分會背八股和真懂Java的分水嶺。以String為例如果你說String重寫了equals所以可以用equals比較這當(dāng)然沒問題。但如果你能補(bǔ)充字符串常量池對字面量做了復(fù)用導(dǎo)致在某些情況下返回true但這種行為不可依賴因為new String會創(chuàng)建新對象面試官會認(rèn)為你真的踩過坑。以Integer緩存為例很多面試者知道緩存區(qū)間是-128~127但不知道的是這個上限可以通過 JVM 參數(shù)-XX:AutoBoxCacheMax調(diào)整JDK 9 之后對某些版本有效緩存機(jī)制又是通過Integer.valueOf實現(xiàn)的而new Integer(100)則完全不走緩存。如果你主動把這些細(xì)節(jié)講出來會顯得平時確實讀過源碼。還有一個經(jīng)常被忽略的點自定義對象放進(jìn)HashMap的key時如果這個對象是可變的修改字段后哈希值會改變導(dǎo)致HashMap里再也查不到原來的鍵。比如DominoCard的leftValue是可變的放進(jìn)HashMap后改了點數(shù)hashCode跟著變了但它在桶里的位置還是基于舊哈希值計算的于是get找不到。這個坑一旦踩到比和equals更隱蔽但也是面試官很愛聊的話題——用可變對象當(dāng)HashMap的 key 有什么風(fēng)險。5.3 用這個項目當(dāng)項目經(jīng)歷時怎么講出亮點如果你準(zhǔn)備把Java多米諾記憶游戲?qū)戇M(jìn)簡歷或者面試時講項目經(jīng)歷我不建議只講我做了一個游戲。更好的講法是我在開發(fā)過程中遇到一個匹配邏輯Bug表現(xiàn)是相同牌面偶爾配對失敗排查后發(fā)現(xiàn)是對象比較方式選錯并由此深入理解了Java對象比較體系順帶修復(fù)了狀態(tài)機(jī)和邊界條件問題。這種講法的好處是有具體場景、有Bug表象、有排查鏈路、有底層原理、有修復(fù)方案、有回歸驗證正好構(gòu)成一個完整的項目復(fù)盤。面試官順著往下問基本都會落在/equals/hashCode上而這片你已經(jīng)滾瓜爛熟了。如果要再往上拔高可以加一句設(shè)計層面的考慮在重寫equals時我特意考慮了多米諾牌左右點數(shù)的順序無關(guān)性并設(shè)計了對順序無關(guān)的hashCode生成策略。 這句話能體現(xiàn)你對業(yè)務(wù)語義的理解而不是機(jī)械地套模板。另外一個值得補(bǔ)充的細(xì)節(jié)是equals中不要調(diào)用可以被子類重寫的方法否則在繼承體系下可能出現(xiàn)不可預(yù)期的行為。這也是為什么很多類庫推薦用final修飾實體類或至少把equals設(shè)計成對稱的。最后說一個我自己的習(xí)慣每次寫完equals我都會配一組單元測試把null、自反、對稱、傳遞、哈希一致性全部覆蓋到。這不只是應(yīng)付面試而是這類代碼太容易被后續(xù)維護(hù)者改出問題。手動測試只能驗證當(dāng)前路徑單測才能鎖死契約。這個項目讓我最深的體會是一個看似簡單的記憶游戲只要認(rèn)真摳一次匹配邏輯就能把、equals、hashCode、HashMap、Integer緩存、狀態(tài)機(jī)、邊界條件整整一串Java基礎(chǔ)全部串起來。做項目最值錢的部分往往不是把功能跑通而是把一個Bug查到底、把一類知識點吃透。后續(xù)再做類似游戲時我建議你在寫完第一版后故意把所有equals替換成跑一遍看看日志里的表現(xiàn)再親手修回來——這個過程比看十篇八股文都管用。 Java對象比較：從多米諾記憶游戲看==與equals陷阱
1. 先給一個可復(fù)現(xiàn)的多米諾記憶游戲原型1.1 一張牌的兩個數(shù)字是所有隱藏Bug的起點多米諾記憶游戲的玩法很簡單桌面上扣著N張牌每張牌印著一組多米諾點陣左區(qū)間數(shù)字 右區(qū)間數(shù)字比如[2|3]。玩家每次翻開兩張如果兩張牌的點數(shù)組合完全一致就消除這對牌如果點數(shù)對不上就把它們翻回去。全程累計翻錯次數(shù)超過上限就判負(fù)。這個游戲用來練手Java再合適不過——有對象建模、有集合操作、有狀態(tài)機(jī)、有UI事件甚至還能捎帶講一波算法和內(nèi)存問題。多數(shù)人寫它的時候都會覺得邏輯這么簡單能出什么錯但真實項目里往往就是這種看起來人畜無害的小東西能把Java對象比較的底褲扒得干干凈凈。常見的實現(xiàn)方式是先創(chuàng)建一副牌組比如24對共48張把DominoCard對象放進(jìn)一個List然后Collections.shuffle()洗牌再按4行12列擺到面板上。每張DominoCard有l(wèi)eftValue、rightValue兩個數(shù)字字段外加faceUp和matched兩個布爾狀態(tài)。玩家點擊桌面上一張未翻開的牌時把它翻開再點另一張時拿這兩張牌做匹配判斷。命中的話兩張都變成matchedtrue一定時間后繼續(xù)沒命中的話等展示時間結(jié)束再翻回去同時失敗次數(shù)mistakeCount加1。到這里為止一切聽起來都很順暢但真正上線跑起來問題就開始冒頭了。最典型的就是兩張明明應(yīng)該配對的牌永遠(yuǎn)顯示不匹配。我就見過好幾個朋友的初版代碼卡在這里而且更迷惑的是他們核對數(shù)值時發(fā)現(xiàn)數(shù)字明明一樣為什么程序就是說不相等這就要從最基礎(chǔ)的比較邏輯開始查起。1.2 核心類結(jié)構(gòu)與匹配流程的簡化版為了把問題說清楚我先給出一個簡化但完整的核心模型。DominoCard的典型寫法長下面這樣public class DominoCard { private final int leftValue; private final int rightValue; private boolean faceUp; private boolean matched; public DominoCard(int leftValue, int rightValue) { this.leftValue leftValue; this.rightValue rightValue; } public boolean isFaceUp() { return faceUp; } public void setFaceUp(boolean faceUp) { this.faceUp faceUp; } public boolean isMatched() { return matched; } public void setMatched(boolean matched) { this.matched matched; } // getter... }游戲主控部分的核心匹配邏輯早期版本通常長這樣public boolean isMatch(DominoCard a, DominoCard b) { return a b; }這就是第一顆雷。如果a和b是兩個不同的實例哪怕它們的leftValue和rightValue完全一樣也只會返回false。你可能會說誰會這么寫——現(xiàn)實中真的有人這么寫。原因往往是最初誤以為可以比較內(nèi)容或者從某些簡易教程里抄來了這個寫法自己也沒跑過完整的成對測試。更隱蔽的情況是有些老代碼在某個階段曾經(jīng)用枚舉或池化對象管理牌面那時候可能碰巧成立后來改了數(shù)據(jù)模型比較邏輯卻沒跟著改Bug就一直潛伏著。如果這關(guān)過了緊接著的另一顆雷是字段類型。假設(shè)把leftValue和rightValue定義成了Integer很多初學(xué)者或從某些代碼規(guī)范里繼承下來的人會這樣寫然后在匹配時用a.getLeftValue() b.getLeftValue()來比較那就會觸發(fā)Integer的緩存機(jī)制-128~127范圍內(nèi)會返回true超過這個范圍就返回false。而多米諾骨牌上的點數(shù)通常剛好在1~6之間于是所有同點數(shù)的牌在下都相等看起來游戲跑得好好的。但這是一種錯覺它掩蓋了真正的對象比較問題。2. 復(fù)現(xiàn)相同牌面卻永遠(yuǎn)配對不成功的Bug2.1 真實癥狀同一對牌時好時壞先把 Bug 現(xiàn)場還原一下。一個剛寫出來的多米諾記憶游戲點擊兩張[3|4]的牌正常情況下應(yīng)該配對成功、兩張牌從桌面消失。但實際表現(xiàn)是大部分情況下點擊完直接彈回仿佛你點錯了偶爾幾次又能成功。為什么偶爾因為如果匹配代碼存在字段是Integer但值恰好落在緩存區(qū)間和字段是int但兩個對象恰好來自同一個內(nèi)部池比如某些單例工廠或常量復(fù)用兩種情況時的表現(xiàn)就會變得非常跳躍時而相等、時而不相等。我排查時最喜歡用的切入點是先把表象拆開判斷到底是數(shù)據(jù)不同還是比較方式不同。所以第一步不是去看比較代碼而是先打日志把兩張被點擊的牌的leftValue、rightValue、對象內(nèi)存地址也就是System.identityHashCode()全部打出來。日志一出來真相往往就藏不住了牌面數(shù)值一樣但兩個對象的身份哈希完全不一樣說明它們就是兩個獨立的實例。這時候再去讀比較代碼基本一眼就能鎖定。2.2 排查鏈路從行為異常到最終根因這里我把排查過程完整寫出來方便你以后遇到類似問題時照著這個思路走。第一層確認(rèn)是否真的進(jìn)入過匹配分支。有些時候卡片配對不成功不是比較邏輯的問題而是點擊事件壓根沒觸發(fā)第二次。所以先在isMatch入口打一行日志確認(rèn)兩個參數(shù)都非空、都來自被點擊的牌。這個檢查建議永遠(yuǎn)放在最前面避免在錯誤方向上浪費幾個小時。第二層用equals和分頭驗證數(shù)據(jù)。在日志里分別輸出a b、a.equals(b)、a.getLeftValue() b.getLeftValue()和兩個對象的完整字段。早期版本寫的是a b所以a.equals(b)大概率也是false——因為Object.equals默認(rèn)就是。而字段比較的結(jié)果會暴露另一個線索如果值是Integer且在-128~127區(qū)間字段用比較會返回true這就解釋了為什么偶爾成功——因為Integer緩存救了它救得了一時救不了一世。第三層排除并發(fā)或時序干擾。有些項目里點擊事件和動畫回調(diào)是異步的第一次翻開還沒完成時第二次點擊已經(jīng)進(jìn)來了導(dǎo)致比較時拿到的是同一個對象或半初始化對象。這一層要檢查faceUp標(biāo)志位是否正確設(shè)置、是否在比較前就做了狀態(tài)翻轉(zhuǎn)。我見過不止一次游戲配對失敗的根因不是比較而是因為第一張牌在翻開動畫結(jié)束前就被標(biāo)記成了已翻轉(zhuǎn)第二張牌點擊后狀態(tài)判斷直接跳過導(dǎo)致永遠(yuǎn)走不到比較分支。第四層追到根因把比較邏輯替換成基于字段或基于equals的實現(xiàn)。這層完成后Bug 表面終結(jié)。但我要提醒你替換成equals之后如果只重寫equals不重寫hashCode那只是把噩夢從匹配失敗換成了放進(jìn)集合時行為異常問題并沒有真正結(jié)束。2.3 第一輪修復(fù)改用值比較后為什么只是暫時看起來正常第一輪修復(fù)的常見做法是把a(bǔ) b改成public boolean isMatch(DominoCard a, DominoCard b) { return a.getLeftValue() b.getLeftValue() a.getRightValue() b.getRightValue(); }如果getLeftValue()返回的是int這段代碼在點數(shù)1~6的牌面上是完全行得通的。但假如leftValue是Integer這個寫法在-128~127區(qū)間內(nèi)依舊能通過而一旦游戲需求擴(kuò)展成點數(shù)范圍更廣的多米諾牌比如支持 0~9、甚至支持超過 127 的編號Integer緩存不夠用的時候同樣的代碼就會突然大面積失效。第一輪修復(fù)之所以是看起來正常是因為數(shù)據(jù)范圍恰好落進(jìn)了緩存區(qū)把問題埋得更深了。真正可靠的修復(fù)方式是為DominoCard重寫equals和hashCode然后用equals去比較。下面這篇博文的核心部分就是圍繞到底該怎么重寫才算合格展開的。3. 從一行比較代碼展開的Java對象比較體系3.1 到底在比什么引用還是內(nèi)容在Java里的語義非常明確比較兩個引用變量是否指向堆內(nèi)存中的同一個對象。它不是比較內(nèi)容而是比較地址。哪怕兩個對象的字段完全一致只要它們是通過兩次new創(chuàng)建出來的就是false。用一個生活化的類比比較的是是不是同一個人而equals比較的是是不是同一張身份證對應(yīng)的合法身份或者兩個人的姓名、出生日期等關(guān)鍵信息是否一致。記憶游戲里的兩張[3|4]牌相當(dāng)于兩個外表完全相同的人但它們是兩個獨立的個體。你用是不是同一個人來判斷它們是否配對自然永遠(yuǎn)失敗。面試?yán)镒罱?jīng)典的問法就是兩個對象內(nèi)容一樣返回false為什么 答案就在引用語義上。但面試官第二個問題通常會接上那equals有沒有可能返回true 這就需要看這個類有沒有重寫過equals方法。如果沒重寫Object.equals默認(rèn)實現(xiàn)就是結(jié)果只能是false。3.2 equals與hashCode一對必須同生共死的契約equals方法在Java對象體系中承擔(dān)的職責(zé)是定義邏輯相等。默認(rèn)情況下如果沒有重寫它的行為與完全一致。但很多業(yè)務(wù)場景需要我們自定義什么才算相等——比如兩張多米諾牌leftValue和rightValue一致就算同一張。重寫equals時必須遵循幾條硬性約定自反性x.equals(x)必須為true對稱性x.equals(y)與y.equals(x)結(jié)果一致傳遞性如果x.equals(y)且y.equals(z)那么x.equals(z)也必須為true一致性只要對象內(nèi)容不變多次調(diào)用equals結(jié)果不變非空性x.equals(null)必須為false與equals綁定的另一條鐵律是重寫equals必須重寫hashCode。原因是Java 中所有基于哈希的集合HashMap、HashSet、Hashtable都依賴先算hashCode定位桶再通過equals精確比較。如果兩個對象equals相等但hashCode不同它們在哈希表中會被分到不同的桶HashMap.get()永遠(yuǎn)找不到目標(biāo)HashSet也會出現(xiàn)內(nèi)容相同卻能重復(fù)放入的詭異現(xiàn)象。hashCode的約定是如果兩個對象按equals比較相等那么它們的hashCode必須相等如果兩個對象的hashCode相等它們不一定equals相等這是允許的哈希沖突只要對象內(nèi)容不變多次調(diào)用hashCode返回值應(yīng)一致3.3 String與Integer的緩存陷阱為什么感覺相等卻沒有真正相等Java里有兩個極其經(jīng)典的緩存機(jī)制經(jīng)常讓人在比較時栽跟頭。第一個是字符串常量池。如下代碼String s1 java; String s2 java; System.out.println(s1 s2); // true因為兩個字面量都指向常量池中的同一個對象但這并不代表String的可以安全使用。改成這樣String s3 new String(java); String s4 new String(java); System.out.println(s3 s4); // false因為創(chuàng)建了兩個不同實例如果s3.intern()之后再與s1比較結(jié)果又變成true了。可見String的結(jié)果完全取決于對象是否從常量池來很容易被誤導(dǎo)。第二個是Integer緩存。Integer默認(rèn)緩存了-128~127之間的對象所以Integer a 100; Integer b 100; System.out.println(a b); // true走緩存 Integer c 200; Integer d 200; System.out.println(c d); // false超過緩存范圍創(chuàng)建了新對象如果項目里用Integer存多米諾點數(shù)恰好點數(shù)都在1~6那么card1.getLeftValue() card2.getLeftValue()會表現(xiàn)出假的相等。這個假象一旦遇到超過127的點數(shù)就會瞬間擊穿。這類問題的通用結(jié)論是基本類型用對象類型一律用equals或Objects.equals。對于Integer、String這類值對象永遠(yuǎn)不要依賴。這是面試高頻考點也是實際項目里最容易引發(fā)線上偶發(fā)Bug的根因之一。3.4 自定義對象的equals要怎么寫才算合格結(jié)合多米諾記憶游戲的場景DominoCard的equals應(yīng)該判斷牌面點數(shù)組合是否一致。不過這里還有一個隱藏需求[1|2]和[2|1]算不算同一張牌從純邏輯上講很多游戲規(guī)則會認(rèn)為算因為牌面由兩個數(shù)字組成左右順序只是顯示布局。當(dāng)然也可以指定必須完全一致這取決于需求。但作為一個通用設(shè)計equals應(yīng)該體現(xiàn)業(yè)務(wù)語義所以我實現(xiàn)時會同時兼容左右互換Override public boolean equals(Object o) { if (this o) return true; if (o null || getClass() ! o.getClass()) return false; DominoCard that (DominoCard) o; boolean direct this.leftValue that.leftValue this.rightValue that.rightValue; boolean reversed this.leftValue that.rightValue this.rightValue that.leftValue; return direct || reversed; } Override public int hashCode() { // 組合時考慮順序無關(guān)性 int sum leftValue rightValue; int diff Math.abs(leftValue - rightValue); return Objects.hash(sum, diff); }用sum和diff的組合作為哈希值可以保證左右順序互換的牌得到相同的hashCode。這個技巧很適合用來回答如果equals里做了順序無關(guān)判斷hashCode該怎么寫這類面試題。這里有幾個細(xì)節(jié)值得展開講講。第一getClass() ! o.getClass()的寫法在處理繼承時會變得很嚴(yán)格。如果DominoCard有子類父類和子類實例永遠(yuǎn)不會相等。另一種常見寫法是用instanceofif (!(o instanceof DominoCard)) return false;instanceof允許子類與父類之間比較但對hashCode的一致性要求更高因為子類可能擴(kuò)展了新字段破壞了對稱性。在實際項目中如果實體類沒有繼承層級getClass()更安全如果有多態(tài)需求instanceof更靈活但需要保證equals仍然遵守對稱性。第二equals里不要做太多額外計算。像上面的寫法先比較字段再Objects.hash也行但直接字段比較性能更好。對記憶游戲這種高頻點擊場景字段比較足夠了。第三hashCode不要用死板的Objects.hash(leftValue, rightValue)直接懟上去因為那會讓順序無關(guān)的[1|2]和[2|1]產(chǎn)生不同哈希。雖然哈希值不同不至于讓equals失效比如放在ArrayList里就無所謂但放進(jìn)HashMap、HashSet時就會出問題所以必須嚴(yán)格保證equals 相等則 hashCode 相等。4. 修復(fù)后的完整代碼與連帶Bug清理4.1 修復(fù)后的匹配邏輯對比把equals和hashCode修好之后匹配判斷就變得極簡public boolean isMatch(DominoCard a, DominoCard b) { return a.equals(b); }與初版對比差別一目了然比較方式初版修復(fù)版比較目標(biāo)引用是否相同業(yè)務(wù)內(nèi)容是否相同同值不同實例falsetrue左右互換判定不支持支持按需求放入HashSet/HashMap可能重復(fù)正常去重隱患隱藏的Integer緩存依賴無這個表也方便你寫復(fù)盤文檔時直接引用。4.2 順藤摸瓜狀態(tài)機(jī)與步數(shù)邊界修完匹配邏輯只是第一步。很多項目里的Bug是連環(huán)的你把第一個Bug按下去第二個Bug才浮出水面。這個記憶游戲也不例外。我在實際測試中就遇到過連續(xù)快速點擊三張牌游戲狀態(tài)直接錯亂。因為翻牌匹配是一個有狀態(tài)的過程理想狀態(tài)機(jī)應(yīng)該是enum GameState { IDLE, // 等待第一張牌翻開 ONE_FLIPPED, // 已翻開第一張等待第二張 RESOLVING, // 兩張已翻開正在做匹配或動畫 }當(dāng)玩家點擊時需要根據(jù)當(dāng)前狀態(tài)決定是否允許這次點擊。初版代碼往往只判斷了牌是否已經(jīng)翻開沒判斷當(dāng)前是否在動畫處理中于是第三張牌就能在RESOLVING狀態(tài)下被翻開導(dǎo)致三張牌同時展示狀態(tài)錯亂。修復(fù)方式是在點擊入口加狀態(tài)判斷public void onCardClicked(DominoCard card) { if (gameState GameState.RESOLVING) return; // 動畫期間忽略點擊 if (card.isFaceUp() || card.isMatched()) return; // 正常處理... }另一個高頻Bug是失敗次數(shù)邊界。假設(shè)游戲規(guī)則是最多允許10次翻錯初版可能寫成if (mistakeCount 10) { gameOver(); }這會導(dǎo)致第11次失敗才觸發(fā)游戲結(jié)束而用戶已經(jīng)多玩了1次。正確寫法是if (mistakeCount 10) { gameOver(); }這類邊界問題雖然和對象比較無關(guān)但和邏輯修復(fù)的主題高度契合。排查時可統(tǒng)一使用邊界值驗證法把次數(shù)分別設(shè)為9、10、11觀察程序是否按預(yù)期在第10次結(jié)束。4.3 回歸測試清單修完所有Bug后一定要做一輪完整的回歸測試。我給自己列過一份清單每次改完都能直接復(fù)用兩張相同點數(shù)的牌能否配對成功兩張不同點數(shù)的牌是否配對失敗且計數(shù)加1[1|2]與[2|1]是否按需求視為同一對連續(xù)快速點擊三張牌狀態(tài)是否穩(wěn)定第10次失敗是否觸發(fā)游戲結(jié)束第9次失敗后游戲是否還能繼續(xù)點擊已matched的牌是否被忽略洗牌后List中是否還有重復(fù)對象引用比如同一張牌被放入了兩次使用HashSet存放已配對牌時能否正確去重這份清單不僅能用于這個游戲凡是涉及對象比較、狀態(tài)機(jī)、邊界條件的項目基本都能套用。5. 面試官視角這些坑會以什么方式考你5.1 必問的 /equals/hashCode 連環(huán)題搜索熱詞里頻繁出現(xiàn) java面試題、java基礎(chǔ)、java八股文說明這類問題確實是面試重災(zāi)區(qū)。根據(jù)我踩過的坑和面試官朋友反饋最常見的連環(huán)題是這樣的第一問和equals的區(qū)別是什么 答出比較引用equals比較內(nèi)容前提是重寫算基礎(chǔ)分。第二問不重寫equals會怎樣 這時要能答出默認(rèn)Object.equals等同于。第三問重寫equals時為什么必須重寫hashCode 這里要展開HashMap底層的先哈希后比較機(jī)制。如果你能把HashSet去重的底層流程講清楚基本就能讓面試官點頭。第四問進(jìn)階如果某個類的hashCode每次都返回同一個固定值有什么后果 答案是所有元素都會落在同一個哈希桶里導(dǎo)致查詢性能退化成鏈表順序查找嚴(yán)重時接近O(n)。這題考的是對哈希沖突的理解。第五問高頻Integer的什么時候返回true 能答出-128~127緩存區(qū)間并且指出Integer.valueOf會走緩存但new Integer不會就是滿分答案。第六問幾乎是必考題HashMap的查找流程是什么 標(biāo)準(zhǔn)回答是先計算key.hashCode()定位到具體桶若桶內(nèi)是鏈表或紅黑樹結(jié)構(gòu)再用equals逐個比較若命中則返回對應(yīng)value。如果有多個對象的hashCode相同桶內(nèi)會形成鏈表JDK 8 之后鏈表長度超過閾值會轉(zhuǎn)成紅黑樹。這個回答能把哈希、equals、性能三個點串起來。5.2 更深一層的坑String池、Integer緩存與HashMap面試中把基礎(chǔ)題答完之后能不能從基礎(chǔ)題延伸到更深一層的坑往往是區(qū)分會背八股和真懂Java的分水嶺。以String為例如果你說String重寫了equals所以可以用equals比較這當(dāng)然沒問題。但如果你能補(bǔ)充字符串常量池對字面量做了復(fù)用導(dǎo)致在某些情況下返回true但這種行為不可依賴因為new String會創(chuàng)建新對象面試官會認(rèn)為你真的踩過坑。以Integer緩存為例很多面試者知道緩存區(qū)間是-128~127但不知道的是這個上限可以通過 JVM 參數(shù)-XX:AutoBoxCacheMax調(diào)整JDK 9 之后對某些版本有效緩存機(jī)制又是通過Integer.valueOf實現(xiàn)的而new Integer(100)則完全不走緩存。如果你主動把這些細(xì)節(jié)講出來會顯得平時確實讀過源碼。還有一個經(jīng)常被忽略的點自定義對象放進(jìn)HashMap的key時如果這個對象是可變的修改字段后哈希值會改變導(dǎo)致HashMap里再也查不到原來的鍵。比如DominoCard的leftValue是可變的放進(jìn)HashMap后改了點數(shù)hashCode跟著變了但它在桶里的位置還是基于舊哈希值計算的于是get找不到。這個坑一旦踩到比和equals更隱蔽但也是面試官很愛聊的話題——用可變對象當(dāng)HashMap的 key 有什么風(fēng)險。5.3 用這個項目當(dāng)項目經(jīng)歷時怎么講出亮點如果你準(zhǔn)備把Java多米諾記憶游戲?qū)戇M(jìn)簡歷或者面試時講項目經(jīng)歷我不建議只講我做了一個游戲。更好的講法是我在開發(fā)過程中遇到一個匹配邏輯Bug表現(xiàn)是相同牌面偶爾配對失敗排查后發(fā)現(xiàn)是對象比較方式選錯并由此深入理解了Java對象比較體系順帶修復(fù)了狀態(tài)機(jī)和邊界條件問題。這種講法的好處是有具體場景、有Bug表象、有排查鏈路、有底層原理、有修復(fù)方案、有回歸驗證正好構(gòu)成一個完整的項目復(fù)盤。面試官順著往下問基本都會落在/equals/hashCode上而這片你已經(jīng)滾瓜爛熟了。如果要再往上拔高可以加一句設(shè)計層面的考慮在重寫equals時我特意考慮了多米諾牌左右點數(shù)的順序無關(guān)性并設(shè)計了對順序無關(guān)的hashCode生成策略。 這句話能體現(xiàn)你對業(yè)務(wù)語義的理解而不是機(jī)械地套模板。另外一個值得補(bǔ)充的細(xì)節(jié)是equals中不要調(diào)用可以被子類重寫的方法否則在繼承體系下可能出現(xiàn)不可預(yù)期的行為。這也是為什么很多類庫推薦用final修飾實體類或至少把equals設(shè)計成對稱的。最后說一個我自己的習(xí)慣每次寫完equals我都會配一組單元測試把null、自反、對稱、傳遞、哈希一致性全部覆蓋到。這不只是應(yīng)付面試而是這類代碼太容易被后續(xù)維護(hù)者改出問題。手動測試只能驗證當(dāng)前路徑單測才能鎖死契約。這個項目讓我最深的體會是一個看似簡單的記憶游戲只要認(rèn)真摳一次匹配邏輯就能把、equals、hashCode、HashMap、Integer緩存、狀態(tài)機(jī)、邊界條件整整一串Java基礎(chǔ)全部串起來。做項目最值錢的部分往往不是把功能跑通而是把一個Bug查到底、把一類知識點吃透。后續(xù)再做類似游戲時我建議你在寫完第一版后故意把所有equals替換成跑一遍看看日志里的表現(xiàn)再親手修回來——這個過程比看十篇八股文都管用。