很多Java開發(fā)看到“樹形結(jié)構(gòu)”四個(gè)字第一反應(yīng)就是遞歸、遍歷、Stack。菜單權(quán)限、組織架構(gòu)、商品分類、文件目錄幾乎每一個(gè)正經(jīng)的業(yè)務(wù)系統(tǒng)都逃不掉樹。但說實(shí)話能把樹寫明白的人真不多。我接手過不少老項(xiàng)目常見畫面是一個(gè)Service類里塞了十幾個(gè)if每次拿到一個(gè)節(jié)點(diǎn)都要先判斷到底是不是葉子、有沒有子節(jié)點(diǎn)然后走完全不同的分支邏輯下一個(gè)人改代碼時(shí)頭皮都發(fā)麻。組合模式Composite Pattern就是沖著這個(gè)痛點(diǎn)來的。它是一種結(jié)構(gòu)型設(shè)計(jì)模式核心就一句話讓“單個(gè)對(duì)象”和“組合對(duì)象”在使用上保持一致讓客戶端可以像處理單個(gè)對(duì)象一樣處理一棵完整的樹。這篇文章我不會(huì)只念定義會(huì)把原理掰開揉碎配合真實(shí)業(yè)務(wù)場(chǎng)景的Java實(shí)現(xiàn)把組合模式的應(yīng)用場(chǎng)景、結(jié)構(gòu)設(shè)計(jì)和落地經(jīng)驗(yàn)一次說清楚。無論你是被權(quán)限樹折磨的后臺(tái)開發(fā)還是準(zhǔn)備Java面試想答出差異化的人都值得看完。1. 組合模式到底在解決什么問題1.1 樹形結(jié)構(gòu)處理的三個(gè)典型痛點(diǎn)先說我實(shí)際見過的三個(gè)痛點(diǎn)。第一個(gè)類型分裂。比如權(quán)限樹里有“部門節(jié)點(diǎn)”和“用戶節(jié)點(diǎn)”部門節(jié)點(diǎn)能掛子部門用戶節(jié)點(diǎn)不能。代碼寫到最后到處都是if (node instanceof DeptNode)之類的判斷。新增一種節(jié)點(diǎn)所有處理邏輯都要跟著改非常痛苦。真正可怕的是這種判斷不止出現(xiàn)在Service層還可能散布在Controller、工具類、前端API組裝各處后期每加一個(gè)節(jié)點(diǎn)類型都要全局搜索一遍所有引用點(diǎn)漏一個(gè)就出線上Bug。第二個(gè)遞歸業(yè)務(wù)代碼失控。統(tǒng)計(jì)部門人數(shù)、算商品總價(jià)、渲染菜單這類需求通常就是一把梭寫遞歸。寫的時(shí)候挺爽后期需求一變遞歸方法越來越大參數(shù)越加越多基本沒法維護(hù)。我見過一個(gè)遞歸方法從最初統(tǒng)計(jì)部門人數(shù)慢慢擴(kuò)展成同時(shí)要統(tǒng)計(jì)工資、工齡、職級(jí)、編制數(shù)七個(gè)參數(shù)傳進(jìn)去內(nèi)部十幾個(gè)if測(cè)試根本沒法覆蓋全部分支。第三個(gè)客戶端調(diào)用不統(tǒng)一。有的接口返回單個(gè)對(duì)象有的返回列表有的直接把節(jié)點(diǎn)內(nèi)部字段暴露給外部導(dǎo)致調(diào)用方必須了解樹的所有內(nèi)部細(xì)節(jié)。比如菜單渲染邏輯明明調(diào)用方只需要知道“這個(gè)菜單底下有哪些菜單”卻要被迫了解菜單節(jié)點(diǎn)內(nèi)部是數(shù)組存儲(chǔ)還是列表存儲(chǔ)、子節(jié)點(diǎn)是延遲加載還是立即加載這種耦合到最后就是牽一發(fā)動(dòng)全身。這三個(gè)痛點(diǎn)的本質(zhì)其實(shí)是一個(gè)我們?nèi)鄙僖粋€(gè)統(tǒng)一的抽象把“葉子”和“容器”蒙在同一個(gè)接口后面。組合模式的價(jià)值正是在這一層。一旦抽象建立起來外部的所有邏輯都被統(tǒng)一成“對(duì)一棵樹的節(jié)點(diǎn)做操作”至于這個(gè)節(jié)點(diǎn)內(nèi)部是一整個(gè)部門還是一名單身員工根本不用關(guān)心。1.2 核心結(jié)構(gòu)Component、Leaf、Composite三個(gè)角色組合模式的結(jié)構(gòu)極其簡(jiǎn)單就三個(gè)角色。Component是抽象構(gòu)件定義了所有節(jié)點(diǎn)對(duì)外暴露的方法。它既包含業(yè)務(wù)上共同的操作比如獲取名稱、計(jì)算價(jià)格、打印信息也定義了樹結(jié)構(gòu)相關(guān)的操作比如添加子節(jié)點(diǎn)、移除子節(jié)點(diǎn)、獲取子節(jié)點(diǎn)列表。在設(shè)計(jì)Component的時(shí)候有個(gè)容易忽略的點(diǎn)它不應(yīng)該只是一個(gè)數(shù)據(jù)裝配的載體更要承載業(yè)務(wù)行為。很多人把組合模式寫成了純粹的樹狀數(shù)據(jù)結(jié)構(gòu)里里外外只有g(shù)etter和setter結(jié)果一棵樹建好了業(yè)務(wù)邏輯還是散落在各個(gè)Service里模式的核心價(jià)值就打了折扣。Leaf是葉子節(jié)點(diǎn)代表樹里沒有子分支的末端節(jié)點(diǎn)執(zhí)行真正的業(yè)務(wù)邏輯比如單個(gè)商品的定價(jià)、單個(gè)用戶的權(quán)限判斷。葉子節(jié)點(diǎn)內(nèi)部通常只有一條路自己算賬。所以它的add和remove要么不存在要么就只能拋異常。Composite是容器節(jié)點(diǎn)內(nèi)部持有一個(gè)List 負(fù)責(zé)管理子節(jié)點(diǎn)。它自己不真正干活而是遞歸地委托給子節(jié)點(diǎn)。這個(gè)“委托”是組合模式中最關(guān)鍵的機(jī)制Composite的方法實(shí)現(xiàn)里通常會(huì)遍歷children把同樣的方法調(diào)用轉(zhuǎn)發(fā)給每一個(gè)子節(jié)點(diǎn)再把結(jié)果匯總。換句大白話葉子是“實(shí)物”容器是“盒子”。盒子里可以放實(shí)物也可以再放盒子但無論盒子套幾層從外面看它們都能“打開取東西、放東西、算總價(jià)值”。這就是組合模式想表達(dá)的“部分與整體的一致關(guān)系”。1.3 透明模式和安全模式到底選哪個(gè)寫代碼時(shí)第一個(gè)分叉就是add、remove這些樹操作到底放不放到公共抽象里這一步的抉擇會(huì)影響后面所有的實(shí)現(xiàn)所以我單獨(dú)拎出來講。透明模式是放進(jìn)去。Leaf雖然用不到也必須實(shí)現(xiàn)然后拋出UnsupportedOperationException。好處是客戶端完全不用判斷類型接口高度統(tǒng)一遍歷樹的時(shí)候不管碰到什么節(jié)點(diǎn)都能統(tǒng)一調(diào)用getChildren。安全模式是只放到Composite里Component里不定義樹操作方法。Leaf天然安全調(diào)用不存在的add方法在編譯期就會(huì)報(bào)錯(cuò)但客戶端如果要給節(jié)點(diǎn)加孩子必須先instanceof判斷接口的統(tǒng)一性稍微差一點(diǎn)。我個(gè)人的建議日常業(yè)務(wù)系統(tǒng)優(yōu)先選安全模式。原因很簡(jiǎn)單透明模式的“統(tǒng)一”在Java里很容易變成隱蔽的運(yùn)行期炸彈。葉子節(jié)點(diǎn)拋異常這個(gè)設(shè)計(jì)一旦遇到?jīng)]人處理的代碼路徑問題定位成本遠(yuǎn)高于那幾次多余的instanceof判斷。而且真正使用樹的時(shí)候入口基本都是頂層容器需要“把葉子當(dāng)容器操作”的場(chǎng)景少之又少。你不需要為了一個(gè)幾乎不存在的場(chǎng)景犧牲類型安全。當(dāng)然如果團(tuán)隊(duì)成員整體對(duì)設(shè)計(jì)模式理解比較深而且遍歷代碼確實(shí)存在“不管類型統(tǒng)一操作子節(jié)點(diǎn)”的強(qiáng)需求透明模式也是一個(gè)可選的權(quán)衡。關(guān)鍵是把風(fēng)險(xiǎn)講清楚透明模式本質(zhì)上是把編譯期問題推遲到運(yùn)行期這種“延遲暴雷”的成本往往在壓測(cè)和線上故障時(shí)才顯現(xiàn)。2. 哪些場(chǎng)景才是組合模式的最佳舞臺(tái)2.1 文件系統(tǒng)與目錄結(jié)構(gòu)文件系統(tǒng)就是組合模式教科書級(jí)別的例子。一個(gè)文件夾可以包含文件也可以包含子文件夾無論文件還是文件夾都支持重命名、查大小、刪除這些操作。如果用代碼模擬可以設(shè)計(jì)一個(gè)FileNode接口FileLeaf和DirectoryComposite分別實(shí)現(xiàn)它DirectoryComposite的getSize()方法遍歷所有孩子的getSize()并累加一個(gè)System.out.println就能打印整棵目錄樹的結(jié)構(gòu)。實(shí)際項(xiàng)目中這個(gè)模型比想象中更常用。我?guī)团笥雅挪檫^一個(gè)備份同步工具的問題它要把本地某個(gè)大目錄的增量文件同步到云端目錄結(jié)構(gòu)十幾層深里面混著普通文件、隱藏文件、快捷方式、壓縮包。最開始那套代碼用ArrayList 記錄所有路徑遍歷時(shí)搞不清目錄和文件的關(guān)系同步結(jié)果經(jīng)常錯(cuò)。后來?yè)Q成組合模式建模普通文件和目錄實(shí)現(xiàn)了統(tǒng)一的FileNode同步邏輯開始變得非常清晰每個(gè)節(jié)點(diǎn)自己負(fù)責(zé)“是否需要同步”的判斷目錄再把判斷結(jié)果匯總給上層。2.2 組織架構(gòu)與部門統(tǒng)計(jì)企業(yè)OA里老總要求看全公司的部門樹計(jì)算每個(gè)部門包含所有子部門的人數(shù)、工資總額、座位數(shù)。部門下面掛員工部門下面還能掛子部門。不用組合模式你要寫兩套統(tǒng)計(jì)方法一套遍歷部門一套遍歷員工最后再組合。部門一多、層級(jí)一變這套代碼就膨脹成災(zāi)難。用了組合模式之后Employee和Department都實(shí)現(xiàn)一個(gè)統(tǒng)一的OrgNode接口整棵組織樹就變成一堆OrgNode。統(tǒng)計(jì)工資時(shí)直接對(duì)根節(jié)點(diǎn)遞歸調(diào)用getTotalSalary每個(gè)Department的getTotalSalary內(nèi)部循環(huán)children把結(jié)果累加即可。以后加一個(gè)“實(shí)習(xí)生節(jié)點(diǎn)”、“外包人員節(jié)點(diǎn)”只要實(shí)現(xiàn)OrgNode接口統(tǒng)計(jì)邏輯一行都不用動(dòng)。這里有一個(gè)很典型的業(yè)務(wù)細(xì)節(jié)很多企業(yè)在算人頭的時(shí)候“是否算入部門人數(shù)”并不是簡(jiǎn)單的112往往還有兼任、掛職、借調(diào)這些規(guī)則。如果一開始就把這些差異塞進(jìn)Department的統(tǒng)計(jì)方法里后期必然失控。組合模式的正確打開方式是把“一個(gè)人怎么統(tǒng)計(jì)”的規(guī)則下沉到葉子節(jié)點(diǎn)內(nèi)部讓每個(gè)人自己回答“我該算進(jìn)多少人頭”容器只管累加。這個(gè)設(shè)計(jì)思路能讓你避免大量“特例判斷”。2.3 菜單、分類與權(quán)限樹后臺(tái)管理系統(tǒng)的菜單渲染、商品多級(jí)分類、角色權(quán)限樹是Java開發(fā)碰到樹最多的三個(gè)地方。這些場(chǎng)景有個(gè)共同點(diǎn)節(jié)點(diǎn)除了結(jié)構(gòu)關(guān)系還帶著很多業(yè)務(wù)狀態(tài)比如菜單是否隱藏、分類是否啟用、權(quán)限節(jié)點(diǎn)的半選狀態(tài)。用組合模式建模時(shí)通常會(huì)將通用方法定義在抽象類里比如getName、getVisible、checkPermission。葉子節(jié)點(diǎn)自己判斷權(quán)限碼容器節(jié)點(diǎn)把判斷結(jié)果匯聚給父級(jí)。我最常用到的一個(gè)套路是節(jié)點(diǎn)的checkPermission()方法先檢查自己再遞歸子節(jié)點(diǎn)只要有一個(gè)節(jié)點(diǎn)有權(quán)限就返回true。這和權(quán)限樹“父節(jié)點(diǎn)有權(quán)限子節(jié)點(diǎn)沒權(quán)限”的逆向判斷完全合拍。權(quán)限樹還有一個(gè)細(xì)節(jié)值得多說前端渲染時(shí)經(jīng)常需要“半選”狀態(tài)就是父節(jié)點(diǎn)只有部分子節(jié)點(diǎn)被選中。這種情況下父節(jié)點(diǎn)不能簡(jiǎn)單返回true或false它需要同時(shí)統(tǒng)計(jì)“選中子節(jié)點(diǎn)數(shù)”和“總子節(jié)點(diǎn)數(shù)”然后用1/0/2三種狀態(tài)標(biāo)記。這種多態(tài)化判斷如果散落在外層寫起來費(fèi)勁放在Composite內(nèi)部反而很自然——因?yàn)榘脒x本來就是容器節(jié)點(diǎn)特有的問題葉子節(jié)點(diǎn)只會(huì)是選中或未選中。2.4 規(guī)則引擎與XML/JSON樹解析很多Java開發(fā)者不知道規(guī)則引擎里到處都是組合模式。一個(gè)優(yōu)惠規(guī)則可以是“滿199減100”這種葉子規(guī)則也可以是“滿199減100且僅限生鮮品類”這種組合規(guī)則。執(zhí)行的時(shí)候葉子規(guī)則自己判斷組合規(guī)則把子規(guī)則的結(jié)果用AND/OR合并。這類結(jié)構(gòu)用組合模式建模后新增規(guī)則類型只需要新增一個(gè)類不需要修改執(zhí)行器。我記得之前在訂單中心重構(gòu)優(yōu)惠券系統(tǒng)舊代碼里規(guī)則全部寫在一個(gè)超級(jí)大的RuleExecutor里面十幾個(gè)boolean方法互相調(diào)用改一個(gè)規(guī)則就擔(dān)心影響其他優(yōu)惠的疊加效果。重構(gòu)之后每個(gè)規(guī)則節(jié)點(diǎn)自己判斷組合節(jié)點(diǎn)用AND/OR聚合優(yōu)惠疊加邏輯瞬間變得透明。測(cè)試也好寫了可以直接構(gòu)造一棵規(guī)則樹指定結(jié)果驗(yàn)證聚合邏輯是否符合預(yù)期。再比如XML的DOM模型Element可以包含子Element也可以包含Text文本節(jié)點(diǎn)所有節(jié)點(diǎn)都實(shí)現(xiàn)Node接口——這本身就是組合模式的經(jīng)典實(shí)現(xiàn)。只要解析過XML的人其實(shí)早就接觸過組合模式只是沒意識(shí)到而已。JSON樹遍歷工具、表單動(dòng)態(tài)渲染引擎、審批流程的會(huì)簽/或簽節(jié)點(diǎn)設(shè)計(jì)本質(zhì)上也都是同一套思路。3. 實(shí)戰(zhàn)用組合模式實(shí)現(xiàn)商品套餐計(jì)算3.1 場(chǎng)景設(shè)定與接口設(shè)計(jì)我挑一個(gè)貼近電商業(yè)務(wù)的例子商品套餐。需求是這樣的商品可以是單品也可以是一個(gè)套餐。套餐里可以包含若干個(gè)單品也可以包含別的套餐。無論什么東西我都想知道總價(jià)、總件數(shù)、名稱列表。第一步定義抽象節(jié)點(diǎn)。采用組合模式的標(biāo)準(zhǔn)骨架。我這里先給出透明模式的寫法方便在一個(gè)類里演示完整結(jié)構(gòu)后面再講生產(chǎn)環(huán)境怎么改成安全模式public abstract class ProductNode { protected String name; public ProductNode(String name) { this.name name; } public abstract double getPrice(); public abstract int getCount(); public void add(ProductNode child) { throw new UnsupportedOperationException(當(dāng)前節(jié)點(diǎn)不支持添加子節(jié)點(diǎn)); } public ListProductNode getChildren() { throw new UnsupportedOperationException(當(dāng)前節(jié)點(diǎn)不是容器節(jié)點(diǎn)); } }這里把name設(shè)計(jì)成protected是為了讓子類直接使用getPrice和getCount做成抽象方法強(qiáng)制每個(gè)節(jié)點(diǎn)實(shí)現(xiàn)自己的計(jì)算邏輯。add和getChildren默認(rèn)不支持這樣葉子節(jié)點(diǎn)可以不實(shí)現(xiàn)它們。3.2 實(shí)現(xiàn)葉子節(jié)點(diǎn)和容器節(jié)點(diǎn)葉子節(jié)點(diǎn)就是單品價(jià)格是寫死的數(shù)量是1public class ProductItem extends ProductNode { private double price; public ProductItem(String name, double price) { super(name); this.price price; } Override public double getPrice() { return price; } Override public int getCount() { return 1; } }容器節(jié)點(diǎn)是套餐內(nèi)部維護(hù)一個(gè)子節(jié)點(diǎn)列表getPrice和getCount都是遞歸匯總public class ProductPackage extends ProductNode { private ListProductNode children new ArrayList(); public ProductPackage(String name) { super(name); } Override public void add(ProductNode child) { children.add(child); } Override public ListProductNode getChildren() { return children; } Override public double getPrice() { double total 0; for (ProductNode child : children) { total child.getPrice(); } return total; } Override public int getCount() { int count 0; for (ProductNode child : children) { count child.getCount(); } return count; } }注意兩個(gè)類的getPrice和getCount在調(diào)用方式上完全一致客戶端根本不需要判斷列表里的對(duì)象到底是ProductItem還是ProductPackage。這種“假裝自己是同一種東西”的能力就是組合模式的核心魔法。3.3 客戶端調(diào)用與結(jié)果驗(yàn)證模擬一個(gè)七夕禮盒套餐ProductPackage root new ProductPackage(七夕禮盒套裝); ProductPackage snacks new ProductPackage(零食大禮包); snacks.add(new ProductItem(巧克力, 99)); snacks.add(new ProductItem(曲奇餅干, 45)); root.add(snacks); root.add(new ProductItem(鮮花, 128)); System.out.println(總價(jià) root.getPrice()); System.out.println(總件數(shù) root.getCount());輸出結(jié)果總價(jià)272.0總件數(shù)3。完全符合預(yù)期。這里最妙的地方在于root本身也是一個(gè)ProductPackage它可以再被塞進(jìn)另一個(gè)更大的禮盒。只要你愿意可以無限嵌套而每一層的調(diào)用代碼長(zhǎng)得一模一樣。以后要增加“優(yōu)惠券節(jié)點(diǎn)”只需要新增一個(gè)ProductCoupon實(shí)現(xiàn)ProductNode改一行都不用改客戶端代碼。3.4 樹結(jié)構(gòu)和遞歸遍歷的工程實(shí)現(xiàn)業(yè)務(wù)系統(tǒng)里經(jīng)常要把這棵樹打印出來或者轉(zhuǎn)成前端需要的JSON結(jié)構(gòu)。加一個(gè)遞歸遍歷方法public void traverse(ProductNode node, String prefix) { System.out.println(prefix node.name); for (ProductNode child : node.getChildren()) { traverse(child, prefix ); } }調(diào)用后輸出的結(jié)構(gòu)長(zhǎng)這樣七夕禮盒套裝 零食大禮包 巧克力 曲奇餅干 鮮花對(duì)于只有價(jià)格和數(shù)量的場(chǎng)景這段代碼已經(jīng)很好用了。但生產(chǎn)環(huán)境往往還要應(yīng)對(duì)更復(fù)雜的遍歷需求我會(huì)加一個(gè)函數(shù)式接口增強(qiáng)它把“遍歷邏輯”和“業(yè)務(wù)處理”徹底分離public void traverse(ProductNode node, ConsumerProductNode action) { action.accept(node); for (ProductNode child : node.getChildren()) { traverse(child, action); } }調(diào)用的時(shí)候傳入任意處理邏輯比如篩選有效期內(nèi)的商品、計(jì)算平均價(jià)格、收集所有葉子節(jié)點(diǎn)名。這樣后續(xù)增加新的遍歷玩法時(shí)不需要改動(dòng)ProductNode這棵樹的代碼只新增一個(gè)Consumer實(shí)現(xiàn)即可。這種模式和Java 8之后的Stream思想非常契合代碼看起來也清爽得多。3.5 生產(chǎn)環(huán)境的增強(qiáng)安全模式、線程安全與泛型把上面的demo搬到生產(chǎn)環(huán)境前我會(huì)做三件事。第一改安全模式。把a(bǔ)dd、getChildren從ProductNode挪到ProductPackage或者單獨(dú)拆一個(gè)Composite接口出來避免葉子節(jié)點(diǎn)拋異常的可能。這個(gè)改動(dòng)的邊際成本很低但能減少一類隱蔽的運(yùn)行時(shí)錯(cuò)誤。你總不希望線上日志里出現(xiàn)“UnsupportedOperationException”之后再回頭改接口設(shè)計(jì)吧。第二處理并發(fā)。如果樹結(jié)構(gòu)會(huì)被多線程并發(fā)修改普通的ArrayList會(huì)出大問題。讀多寫少時(shí)children可以用CopyOnWriteArrayList寫頻繁時(shí)遍歷前先對(duì)children做一個(gè)快照防止迭代過程中出現(xiàn)ConcurrentModificationException。樹結(jié)構(gòu)并發(fā)修改是最容易出隱蔽Bug的地方之一而且復(fù)現(xiàn)困難壓測(cè)一跑幾百個(gè)線程同時(shí)加節(jié)點(diǎn)問題立刻爆發(fā)。第三加泛型。如果節(jié)點(diǎn)本身就是業(yè)務(wù)對(duì)象可以定義Node 讓T承載具體的業(yè)務(wù)數(shù)據(jù)這樣組合模式就和業(yè)務(wù)模型解耦了。我用過一個(gè)方案抽象節(jié)點(diǎn)只維護(hù)結(jié)構(gòu)具體業(yè)務(wù)數(shù)據(jù)放在泛型T里這樣一套樹結(jié)構(gòu)工具可以復(fù)用到菜單、分類、權(quán)限多個(gè)模塊代碼復(fù)用率很高。這三步做完才是能在線上扛得住業(yè)務(wù)的組合模式而不是上課用的玩具demo。4. 那些年踩過的坑組合模式避坑指南4.1 無限遞歸與棧溢出組合模式最大的安全風(fēng)險(xiǎn)就是循環(huán)引用。如果A節(jié)點(diǎn)添加的時(shí)候把B掛上去B又把自己的父節(jié)點(diǎn)A加回來遞歸調(diào)用瞬間進(jìn)入死循環(huán)直到StackOverflowError。這個(gè)問題在業(yè)務(wù)系統(tǒng)里出現(xiàn)的頻率比你想象的高得多——尤其是從數(shù)據(jù)庫(kù)加載樹結(jié)構(gòu)時(shí)數(shù)據(jù)臟了父ID指回來整個(gè)接口直接崩。我的習(xí)慣是在add方法里做兩個(gè)檢查一是禁止添加this本身二是遞歸檢查父節(jié)點(diǎn)鏈禁止把祖先節(jié)點(diǎn)加進(jìn)來。實(shí)現(xiàn)大約這樣public void add(ProductNode child) { if (child this) { throw new IllegalArgumentException(不能把自身作為子節(jié)點(diǎn)); } ProductNode current this; while (current ! null) { if (current child) { throw new IllegalArgumentException(不能把祖先節(jié)點(diǎn)作為子節(jié)點(diǎn)); } current current.parent; } children.add(child); }這里引入了parent字段順手解決了兩個(gè)問題找根節(jié)點(diǎn)和環(huán)檢測(cè)。不過要注意parent字段的維護(hù)需要在add和remove兩個(gè)方法里都做漏了就會(huì)產(chǎn)生“幽靈父節(jié)點(diǎn)”遍歷時(shí)倒是不影響但一旦用到parent屬性就全亂套了。4.2 刪除與內(nèi)存釋放remove方法有幾個(gè)細(xì)節(jié)容易被忽略。刪除一個(gè)容器節(jié)點(diǎn)時(shí)它下面的所有子孫節(jié)點(diǎn)如果還被其他業(yè)務(wù)對(duì)象引用著比如緩存會(huì)一直駐留內(nèi)存。我踩過一次坑一個(gè)權(quán)限樹每次刪除父節(jié)點(diǎn)子節(jié)點(diǎn)還留在本地緩存里結(jié)果用戶權(quán)限明明被刪了前端卻還能看到舊菜單。后來排查才知道是緩存沒清而緩存的key只存了子節(jié)點(diǎn)沒有關(guān)聯(lián)父節(jié)點(diǎn)。正確做法是刪除時(shí)清掉該節(jié)點(diǎn)的children列表或者配合WeakReference做緩存。同時(shí)刪除時(shí)要維護(hù)好parent引用否則getsParent和環(huán)檢測(cè)都會(huì)出問題。另外一個(gè)實(shí)踐細(xì)節(jié)如果樹很大刪除操作頻繁建議先刪除葉子、再向上刪除容器避免刪除過程中樹被破壞。4.3 遞歸性能深度很深怎么辦遞歸是組合模式最自然的使用方式但它也有物理極限。JVM默認(rèn)棧深大約幾百到幾千層業(yè)務(wù)里樹超過1000層雖然少見但確有發(fā)生比如深度分類樹、論壇蓋樓、超長(zhǎng)審批鏈。真遇到這種情況可以用顯式棧迭代替代遞歸public static void traverseIterative(ProductNode root) { DequeProductNode stack new ArrayDeque(); stack.push(root); while (!stack.isEmpty()) { ProductNode node stack.pop(); System.out.println(node.name); for (ProductNode child : node.getChildren()) { stack.push(child); } } }順序會(huì)從深度優(yōu)先變成逆序但結(jié)構(gòu)本身沒問題遍歷方法調(diào)整一下即可。很多人在面試時(shí)不會(huì)主動(dòng)聊這個(gè)細(xì)節(jié)但一旦說出來面試官會(huì)眼前一亮。除了遍歷還要注意遞歸方法里的臨時(shí)對(duì)象生命周期盡量用局部變量避免遞歸期間撐爆堆內(nèi)存。4.4 組合模式 vs 裝飾器模式別搞混組合模式和裝飾器模式都圍繞樹形結(jié)構(gòu)剛學(xué)的時(shí)候很容易混。簡(jiǎn)單區(qū)分組合模式解決“部分-整體”的層次問題葉子可以組成容器容器可以再套容器客戶端統(tǒng)一調(diào)用。裝飾器模式解決“動(dòng)態(tài)增強(qiáng)”問題把一個(gè)對(duì)象包在一個(gè)新對(duì)象里新對(duì)象在原有行為上增加職責(zé)包裝層數(shù)不強(qiáng)調(diào)“樹形組織”而是層層套殼。最直觀的記憶方式組合模式是橫向長(zhǎng)樹枝裝飾器是縱向套套娃。實(shí)際項(xiàng)目里兩個(gè)模式經(jīng)常合作先組合出樹再用裝飾器給節(jié)點(diǎn)加緩存、加日志、加權(quán)限校驗(yàn)。如果你在面試時(shí)能把這兩個(gè)模式的關(guān)系講清楚印象分會(huì)直接拉高——因?yàn)榇蠖鄶?shù)人只背定義沒人講清楚它們?nèi)绾未钆涫褂谩?.5 高頻問題速查表整理了一張我在實(shí)戰(zhàn)中經(jīng)常用到的問題速查表方便排查時(shí)對(duì)照問題現(xiàn)象根因分析處理方案遞歸調(diào)用棧溢出樹存在循環(huán)引用add時(shí)檢查this與祖先鏈刪除節(jié)點(diǎn)后子節(jié)點(diǎn)仍可訪問刪除未清空children刪除容器節(jié)點(diǎn)時(shí)遞歸清空葉子節(jié)點(diǎn)調(diào)用add拋異常透明模式的通病優(yōu)先改安全模式多線程遍歷樹數(shù)據(jù)錯(cuò)亂ArrayList并發(fā)修改CopyOnWriteArrayList或快照深度超1000層遞歸卡頓JVM默認(rèn)棧深限制顯式棧迭代遍歷新增節(jié)點(diǎn)類型改動(dòng)大缺少統(tǒng)一Component抽象從業(yè)務(wù)類型中抽取公共接口這個(gè)表也可以當(dāng)成面試復(fù)盤清單每個(gè)問題都要能展開講三五分鐘基本就沒問題了。4.6 面試官想聽什么一套可以照抄的回答思路組合模式在Java面試?yán)锍霈F(xiàn)頻率很高但大部分人只能說出定義沒有“項(xiàng)目味”。我的建議是按這五步答第一步描述場(chǎng)景點(diǎn)出痛點(diǎn)。比如“我在處理權(quán)限樹的時(shí)候節(jié)點(diǎn)分部門、用戶、角色三種統(tǒng)計(jì)規(guī)則又不一樣代碼里全是類型判斷每次加類型都改一遍”。第二步講組合模式怎么破局。把三種節(jié)點(diǎn)抽象成統(tǒng)一的PermissionNode部門和角色容器再持子節(jié)點(diǎn)列表統(tǒng)一遞歸處理。第三步給一個(gè)小例子能說代碼就不要只講概念。比如商品套餐算總價(jià)隨手畫一下三個(gè)角色的關(guān)系。你不需要背完整代碼關(guān)鍵是講清楚Component是抽象、Leaf是葉子、Composite持有List遞歸匯總。第四步主動(dòng)講缺點(diǎn)。透明模式的安全隱患、深遞歸的棧溢出風(fēng)險(xiǎn)、循環(huán)引用要預(yù)防說完這些面試官基本就知道你踩過坑。只講優(yōu)點(diǎn)的候選人大概率是背書的。第五步如果時(shí)間允許補(bǔ)一句組合模式和裝飾器模式的區(qū)別展現(xiàn)橫向?qū)Ρ饶芰?。我一般?huì)說“兩個(gè)模式都會(huì)遞歸套用對(duì)象但組合模式解決的是部分和整體的關(guān)系裝飾器解決的是職責(zé)疊加”這樣就把層次感帶出來了。最后再補(bǔ)一個(gè)實(shí)操細(xì)節(jié)如果你要處理的是數(shù)據(jù)庫(kù)里已經(jīng)存在的樹形數(shù)據(jù)比如一張菜單表parentId結(jié)構(gòu)組合模式依然適用——先從數(shù)據(jù)庫(kù)一次性查出來在內(nèi)存里組裝成樹再遞歸處理。組裝階段要注意防止數(shù)據(jù)臟導(dǎo)致的環(huán)引用這也是我前面強(qiáng)調(diào)add方法做環(huán)檢測(cè)的原因。我個(gè)人在實(shí)際項(xiàng)目里用得最多的其實(shí)是給抽象節(jié)點(diǎn)加parent引用這個(gè)細(xì)節(jié)它讓權(quán)限樹里的“節(jié)點(diǎn)移動(dòng)”“權(quán)限繼承”需求都變得非常簡(jiǎn)單。組合模式不炫技它真正的價(jià)值是讓一棵樹的結(jié)構(gòu)更健康讓后續(xù)加需求、改需求的時(shí)候不心驚膽戰(zhàn)。希望這篇文章能把組合模式講透下次你遇到樹形結(jié)構(gòu)時(shí)第一反應(yīng)不再是堆遞歸而是想想這里是不是該抽出Component了。