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