1. 為什么你需要一個SpringUtil先說個我經(jīng)常遇到的場景。代碼里封裝了一個工具類比如Excel導(dǎo)出、脫敏處理、異步日志上報這些類往往沒有被Spring托管方法都是靜態(tài)的。某天產(chǎn)品要求在這個工具類里調(diào)用某個Mapper或者Service查數(shù)據(jù)你第一反應(yīng)是Autowired塞進去結(jié)果發(fā)現(xiàn)工具類不是Spring Bean注入操作直接被無視字段為null運行時報空指針。我早期踩過這個坑后來老老實實寫了SpringUtil把Spring容器上下文存到一個靜態(tài)字段里以后無論哪個類無論是不是Bean只要想拿容器里的對象一行代碼搞定。本質(zhì)上SpringUtil做的是“從容器外訪問容器內(nèi)對象”的橋接底層依賴ApplicationContextAware接口或靜態(tài)注入ApplicationContext核心就一個方法getBean(ClassT clazz)。這套寫法在中小型項目里極其常見尤其適合以下人群寫通用組件的開發(fā)、做框架封裝的老手、以及剛接觸Spring不久但需要處理“非Bean類里拿Bean”問題的初學(xué)者。你只要理解了Spring容器的基本概念就能直接抄作業(yè)。順帶解釋一下熱詞里反復(fù)出現(xiàn)的“Spring容器”“對象”這幾個概念的對應(yīng)關(guān)系。Spring容器本質(zhì)上是一個Map結(jié)構(gòu)beanName對應(yīng)bean實例容器啟動時根據(jù)配置或注解完成對象的創(chuàng)建和依賴注入。SpringUtil干的事就是拿到這個Map的管理入口也就是ApplicationContext的引用從而在任意位置按名或按類型取出對象。理解了這個底層邏輯之后再看到各種封裝變體都能一眼看穿。2. 核心實現(xiàn)從ApplicationContextAware到靜態(tài)緩存2.1 經(jīng)典寫法實現(xiàn)ApplicationContextAware接口最主流、文檔里最常見的方式是讓工具類實現(xiàn)ApplicationContextAware接口。Spring在容器啟動時會把ApplicationContext本身作為參數(shù)回調(diào)到setApplicationContext方法里你只需要把它存到靜態(tài)變量中就完成了整個橋接。下面是我項目中一直在用的完整代碼注釋也寫得比較詳細(xì)可以直接復(fù)制修改。package com.example.common.util; import org.springframework.beans.BeansException; import org.springframework.context.ApplicationContext; import org.springframework.context.ApplicationContextAware; import org.springframework.stereotype.Component; Component public class SpringUtil implements ApplicationContextAware { private static ApplicationContext applicationContext; Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { SpringUtil.applicationContext applicationContext; } public static ApplicationContext getApplicationContext() { return applicationContext; } /** * 按名稱獲取Bean */ SuppressWarnings(unchecked) public static T T getBean(String name) { if (applicationContext null) { throw new IllegalStateException(Spring容器尚未初始化無法獲取Bean); } return (T) applicationContext.getBean(name); } /** * 按類型獲取Bean */ public static T T getBean(ClassT clazz) { if (applicationContext null) { throw new IllegalStateException(Spring容器尚未初始化無法獲取Bean); } return applicationContext.getBean(clazz); } /** * 按名稱類型獲取Bean避免類型轉(zhuǎn)換隱患 */ public static T T getBean(String name, ClassT clazz) { if (applicationContext null) { throw new IllegalStateException(Spring容器尚未初始化無法獲取Bean); } return applicationContext.getBean(name, clazz); } }有幾個細(xì)節(jié)值得展開講。第一Component注解不能省。因為ApplicationContextAware的回調(diào)發(fā)生在Bean初始化階段如果SpringUtil本身不被注冊成BeanSpring根本沒有機會調(diào)用setApplicationContext。很多人把這個類寫完之后忘記加注解導(dǎo)致靜態(tài)字段一直是null排查半天。第二靜態(tài)字段不能加final。有人習(xí)慣寫private static final ApplicationContext applicationContext然后發(fā)現(xiàn)編譯報錯或者賦值無效因為final字段在構(gòu)造器里完成初始化而setApplicationContext是在Bean屬性填充階段被回調(diào)的這倆時機對不上。第三這里我加了判空保護。當(dāng)工具類在容器啟動早期被調(diào)用時applicationContext可能還是null如果直接getBean會拋NullPointerException。顯式拋出IllegalStateException并附上中文提示能讓你在排查問題時第一時間知道是容器沒初始化而不是堆棧里一行莫名其妙的空指針。2.2 靜態(tài)注入模式不用實現(xiàn)接口的方案另一種常見寫法是利用ApplicationContext的靜態(tài)注入本質(zhì)和ApplicationContextAware沒有區(qū)別只是把回調(diào)入口換成了構(gòu)造器注入。這里展示一個變體。Component public class SpringUtil { private static ApplicationContext applicationContext; Autowired public SpringUtil(ApplicationContext applicationContext) { SpringUtil.applicationContext applicationContext; } public static T T getBean(ClassT clazz) { return applicationContext.getBean(clazz); } }這段代碼的核心邏輯是Spring在創(chuàng)建SpringUtil這個Bean時發(fā)現(xiàn)構(gòu)造器需要一個ApplicationContext類型的參數(shù)于是自動把容器本身傳進來再通過構(gòu)造器賦值給靜態(tài)字段。兩種方案我都用過實際體驗差異不大。ApplicationContextAware更“正統(tǒng)”因為它本身就是為了讓Bean感知容器而設(shè)計的接口語義清晰構(gòu)造器注入的方式更簡潔少寫一個接口方法。但如果你的項目里已經(jīng)大量使用構(gòu)造器注入保持一致也未嘗不可。需要特別注意的是無論用哪種方式都必須保證SpringUtil被Spring管理否則靜態(tài)字段永遠(yuǎn)是空的。另外提一句有些老項目里能看到PostConstruct配合Resource的寫法也就是在初始化方法里手動賦值。這種方案也能跑通但多一個方法可讀性沒有前兩種好我一般不推薦新手用。2.3 獲取Bean的三個方法各有什么講究很多人認(rèn)為getBean就是一行代碼的事沒什么可說的。實際上三個重載方法的適用場景完全不同選錯了會埋坑。getBean(String name)是純按名稱獲取返回值是Object通常需要強轉(zhuǎn)。這個方法的隱患在于如果同類型存在多個Bean按類型獲取會失敗但按名稱獲取不會反之如果名稱拼錯了運行時直接拋NoSuchBeanDefinitionException。所以當(dāng)你明確知道beanName且不糾結(jié)類型安全時用它最直接。getBean(ClassT clazz)是純按類型獲取。這是我用得最多的方式因為類型安全編譯器能幫你檢查大部分錯誤。前提是容器里該類型只能有一個Bean否則會拋NoUniqueBeanDefinitionException。遇到多個實現(xiàn)類的場景可以用Primary標(biāo)記主Bean或者按名稱獲取。getBean(String name, ClassT clazz)是前兩者的結(jié)合體既校驗名稱又校驗類型嚴(yán)格程度最高。如果你在寫框架代碼不確定調(diào)用方會塞什么參數(shù)過來建議使用這個重載。我個人建議在業(yè)務(wù)代碼里默認(rèn)用getBean(ClassT)把類型檢查的工作交給容器最簡單也最不容易出錯。3. 實際應(yīng)用在非Spring環(huán)境中安全獲取Bean3.1 典型場景工具類、定時任務(wù)、監(jiān)聽器、線程池寫SpringUtil的目的就是為了在“容器管不到的地方”使用容器對象。我實際項目中遇到頻率最高的場景有四種。第一種是自定義工具類。比如DateUtils、RegexUtils、JsonUtils這些都是靜態(tài)方法類本身沒有被Spring托管。當(dāng)某個靜態(tài)方法內(nèi)部需要調(diào)用Service時注入行不通直接SpringUtil.getBean(XxxService.class)最省事。第二種是定時任務(wù)框架。你的項目可能用了QuartzJob類由Quartz實例化Spring不參與管理。Job內(nèi)部要操作數(shù)據(jù)庫通常的做法是在Job執(zhí)行方法里調(diào)用SpringUtil.getBean(XxxMapper.class)。第三種是監(jiān)聽器和過濾器。尤其是OncePerRequestFilter它由Web容器管理不在Spring容器內(nèi)但你又需要拿到Spring的Service。雖然可以通過WebApplicationContextUtils.getWebApplicationContext間接獲取但代碼不如SpringUtil簡潔。第四種是多線程場景。在Thread子類或Runnable實現(xiàn)里成員變量不會被Spring注入。我一般在線程run方法里直接SpringUtil.getBean來獲取依賴比如異步通知、異步寫日志、數(shù)據(jù)補償任務(wù)。public class OrderTimeoutTask implements Runnable { private Long orderId; public OrderTimeoutTask(Long orderId) { this.orderId orderId; } Override public void run() { // Spring容器外的線程里無法通過注入獲取依賴 OrderService orderService SpringUtil.getBean(OrderService.class); orderService.cancelTimeoutOrder(orderId); } }這里有一個注意點線程內(nèi)部獲取Bean時容器早已完成初始化所以不用擔(dān)心applicationContext為空的“啟動期問題”。但是線程池一旦緩存了長期存活的線程Bean的獲取也是穩(wěn)定可靠的前提是你沒有在項目里搞動態(tài)銷毀Bean這類操作。3.2 通過SpringUtil讀取配置和環(huán)境信息除了獲取Bean持有ApplicationContext引用后你還能順手獲取配置信息、環(huán)境Profile、發(fā)布事件等。很多人把SpringUtil局限在getBean上其實它的擴展能力被低估了。讀取配置是最實用的擴展。有時候代碼里需要讀取配置中心的某個Key但當(dāng)前類又不是配置屬性類。用Value注入雖然可以但靜態(tài)方法里用不了Value。此時可以通過Environment對象讀取public static String getProperty(String key) { return applicationContext.getEnvironment().getProperty(key); } public static String getProperty(String key, String defaultValue) { return applicationContext.getEnvironment().getProperty(key, defaultValue); }判斷當(dāng)前環(huán)境也常用public static boolean isDev() { Environment environment applicationContext.getEnvironment(); return environment.acceptsProfiles(Profiles.of(dev)); }換一個角度看只要持有ApplicationContext你就等于擁有了Spring容器的“遙控器”。用得好可以在不破壞Spring管理規(guī)則的前提下大幅提升編碼效率用不好容易寫出Servlet容器加載時直接NPE的代碼。核心原則是只在容器啟動完成后使用避免在ApplicationContext初始化階段強行調(diào)用。3.3 用ApplicationContext發(fā)布事件實現(xiàn)模塊解耦Spring自帶的ApplicationEvent機制非常適合做模塊解耦而且通過SpringUtil可以隨時發(fā)布事件不需要注入ApplicationEventPublisher。定義一個事件類public class OrderCreatedEvent extends ApplicationEvent { private Long orderId; public OrderCreatedEvent(Object source, Long orderId) { super(source); this.orderId orderId; } public Long getOrderId() { return orderId; } }在業(yè)務(wù)代碼中哪怕當(dāng)前類不是Service也不是Controller也能直接發(fā)布事件SpringUtil.getApplicationContext().publishEvent(new OrderCreatedEvent(this, orderId));監(jiān)聽端就是一個普通的EventListener方法。這樣做的好處是訂單創(chuàng)建的核心流程不用關(guān)心后續(xù)要通知誰、要扣多少庫存、要發(fā)什么短信這些全部由監(jiān)聽器異步處理。用Async配合線程池還能實現(xiàn)異步化。這個玩法放在SpringUtil的能力矩陣?yán)锸俏艺J(rèn)為被大多數(shù)人忽略但價值極高的一個點。如果你正在設(shè)計一個中大型項目的骨架可以在SpringUtil里封裝一個publishEvent靜態(tài)方法讓所有非Bean類都能參與到事件驅(qū)動架構(gòu)里。4. 常見問題與排查技巧實錄4.1 啟動階段調(diào)用getBean返回null或拋空指針這個問題幾乎人人都會遇到。項目啟動時某些ApplicationRunner、PostConstruct注解的方法、配置類中的初始化邏輯在容器還沒完全初始化時就調(diào)用了SpringUtil此時applicationContext尚未賦值。我習(xí)慣的排查套路分三步。第一步確認(rèn)SpringUtil本身有沒有被掃描到。檢查啟動類所在包路徑是否覆蓋SpringUtil所在的包如果覆蓋不到Component就白寫了。第二步確認(rèn)調(diào)用時機。Spring的ApplicationContextAware#setApplicationContext是在Bean初始化階段回調(diào)的但其他Bean的PostConstruct方法可能在它之前執(zhí)行。如果兩個類都在PostConstruct里干活另一個類的初始化順序排在SpringUtil之前就可能拿到null。第三步根據(jù)項目啟動日志確認(rèn)當(dāng)前執(zhí)行到哪一步。Spring啟動日志里能看到Root WebApplicationContext相關(guān)的初始化信息如果自己代碼的執(zhí)行點早于BeanFactory完成預(yù)實例化很可能就是時機問題。最簡單的規(guī)避方式是把必須在啟動階段執(zhí)行的邏輯放到ApplicationReadyEvent監(jiān)聽器里此時容器已經(jīng)全部就緒。例如Component public class StartupRunner { EventListener(ApplicationReadyEvent.class) public void onReady() { // 此時 SpringUtil 一定可用 XxxService service SpringUtil.getBean(XxxService.class); service.init(); } }如果你不想改代碼也可以在SpringUtil里加一個“延遲初始化”的保護邏輯第一次調(diào)用getBean時如果發(fā)現(xiàn)容器還沒就緒就拋出一個語義明確的異常而不是讓NPE掩蓋真實問題。4.2 多上下文環(huán)境導(dǎo)致拿錯了BeanSpring MVC項目里存在父子容器結(jié)構(gòu)DispatcherServlet創(chuàng)建子容器ContextLoaderListener創(chuàng)建父容器。如果你的SpringUtil被父容器掃描到但它持有的ApplicationContext是父容器而Controller里的Service在子容器中g(shù)etBean查不到就報NoSuchBeanDefinitionException。典型表現(xiàn)非Web層的類調(diào)用SpringUtil.getBean一切正常Controller層調(diào)用卻拿不到Bean或者反過來兩個地方拿到的同一類型Bean實例不是同一個。解決思路有兩個。第一個通過ContextLoader.getCurrentWebApplicationContext()獲取線程綁定的WebApplicationContext。第二個在SpringBoot項目中盡量保證所有Bean都在同一個容器中不要手動創(chuàng)建子容器也不要在DispatcherServlet里單獨配置掃描路徑。其實SpringBoot默認(rèn)已經(jīng)避開了父子容器問題如果你還在用傳統(tǒng)的SSM架構(gòu)這里要多留一個心眼。4.3 靜態(tài)工具類導(dǎo)致循環(huán)依賴或初始化順序混亂有一種誤用模式是這樣的某個Service通過SpringUtil.getBean獲取了另一個Service而另一個Service又反過來通過SpringUtil.getBean獲取第一個Service。由于是運行時強取這種循環(huán)依賴不會被Spring的循環(huán)依賴檢測機制捕獲但可能造成邏輯上的死循環(huán)或數(shù)據(jù)不一致。另一個容易出問題的地方是構(gòu)造器中調(diào)用SpringUtil.getBean。Spring創(chuàng)建Bean時會先執(zhí)行構(gòu)造器如果構(gòu)造器里需要依賴另一個Bean而這個Bean又還在創(chuàng)建中就可能拿到一個未初始化完成的對象。我的經(jīng)驗是不要在構(gòu)造器中調(diào)用SpringUtil。如果Bean初始化時需要依賴其他Bean直接用正常的注入方式Spring會自動處理依賴順序。4.4 方法速查表常見報錯信息原因解決方案IllegalStateException: Spring容器尚未初始化啟動早期調(diào)用SpringUtil改用ApplicationReadyEvent觸發(fā)初始化邏輯NullPointerException靜態(tài)字段未賦值SpringUtil未被掃描檢查Component注解與包掃描路徑NoSuchBeanDefinitionException按名稱/類型查不到Bean確認(rèn)beanName拼寫、類型是否為接口、是否在子容器NoUniqueBeanDefinitionException同類型存在多個實現(xiàn)使用Primary或按名稱指定BeanBeanNotOfRequiredTypeException按名稱獲取的Bean類型與預(yù)期不符使用getBean(String, ClassT)重載方法這些坑我基本都踩過一遍整理出來就是一張速查表。遇到問題先對號入座能省下不少排查時間。5. 進階玩法與優(yōu)化思路5.1 泛型方法與延遲獲取讓工具類更好用上面的基礎(chǔ)工具類已經(jīng)能覆蓋大多數(shù)場景但如果你要把它做成公司內(nèi)部的通用組件還可以再加一層封裝。getBean返回后通常要強轉(zhuǎn)或直接接收但有些業(yè)務(wù)場景需要延遲獲取Bean。比如一個事件監(jiān)聽器里你希望每次執(zhí)行時才拿到最新的Bean實例而不是在監(jiān)聽器創(chuàng)建時就固化引用。此時可以用ObjectProviderpublic static T ObjectProviderT getBeanProvider(ClassT clazz) { return applicationContext.getBeanProvider(clazz); }調(diào)用方可以getIfAvailable()獲取Bean如果容器中沒有該類型就返回null不會拋異常。這個特性在可選依賴場景下非常有用比如某個模塊存在就調(diào)用它的邏輯不存在就跳過。泛型方面我看到過有人封裝getBeanOfType內(nèi)部用ResolvableType實現(xiàn)支持獲取ListXxx、MapString, Xxx這類集合類型。但說實話多數(shù)項目用不到真正需要時直接注入ListXxx更優(yōu)雅。不建議把SpringUtil做得太重保持單一職責(zé)獲取對象就只負(fù)責(zé)獲取對象。5.2 靜態(tài)字段注入的替代方案手動注冊Bean如果你連Component都不想寫也可以直接在配置類里手動注冊SpringUtil本質(zhì)一樣Configuration public class SpringUtilConfig { Bean public SpringUtil springUtil() { return new SpringUtil(); } }這種做法的適用場景是SpringUtil所在的jar包不在主應(yīng)用掃描路徑內(nèi)而你又不希望讓掃描路徑無限擴大通過Import或Bean顯式注冊就很有必要。另外還有一個細(xì)節(jié)有些人在多模塊項目里把SpringUtil放在一個公共模塊業(yè)務(wù)模塊引用之后發(fā)現(xiàn)applicationContext還是null。大概率是公共模塊里的ComponentScan沒有覆蓋到或者公共模塊的類被框架過濾了。此時用Import(SpringUtil.class)或者采用上面這種Bean顯式注冊問題立刻解決。5.3 ThreadLocal與RequestContextHolder的補充既然聊到容器對象我順便提一下Spring里另一個非常容易和SpringUtil一起使用的工具RequestContextHolder。當(dāng)你在非Spring管理的類中需要拿到當(dāng)前請求的HttpServletRequest時可以直接HttpServletRequest request ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();這個工具同樣是從容器上下文中解耦的對象獲取方式配合SpringUtil一起使用時很多框架層的代碼可以寫得非常干凈。但它依賴線程上下文如果在異步線程里使用會失效需要手動把請求屬性傳遞進去這是一個隱藏的坑值得留意。6. 一些使用心得和收尾前面寫了實現(xiàn)、應(yīng)用、排坑和進階最后分享幾條比較個人的心得。在實際項目中我不太建議把SpringUtil當(dāng)成“萬能鑰匙”到處getBean。正常情況下所有Bean應(yīng)該通過Spring依賴注入來協(xié)作SpringUtil只是為了處理“容器外”的場景。如果一個Service里到處是SpringUtil.getBean(Xxx.class)說明依賴關(guān)系設(shè)計可能出了問題應(yīng)該調(diào)整思路讓被依賴的對象通過構(gòu)造器注入進來。我自己的使用邊界很明確工具類內(nèi)部偶爾調(diào)用第三方框架的Job、Listener中調(diào)用以及組件封裝時為了避免注入鏈過長而調(diào)用。業(yè)務(wù)Service之間的依賴一律走注入。還有一點SpringUtil的靜態(tài)字段會隨著Spring容器的重新加載而更新在單元測試中反復(fù)啟動容器時要確保上一次的容器已經(jīng)關(guān)閉否則可能拿到舊容器的引用。測試?yán)镂乙话銜右粋€DirtiesContext或者在AfterEach里清空靜態(tài)字段避免上下文串了。如果你準(zhǔn)備在公司的項目中推廣SpringUtil建議在編碼規(guī)范里明確標(biāo)注它的使用場景和禁止使用場景這樣后來的人不會誤用。給工具類加上清晰的javadoc說明“為什么存在”和“什么時候別用”比寫十行注釋講參數(shù)更重要。這個方向還能繼續(xù)擴展比如把getBean包裝成帶緩存的形式、增加可觀測性日志等但我建議保持工具輕盈避免把一個靜態(tài)工具類做成“服務(wù)定位器”反模式。最后再分享一個小技巧如果你用的是Spring Boot可以在啟動日志里加一行輸出確認(rèn)SpringUtil是否成功持有的ApplicationContext。比如在setApplicationContext里打一行INFO日志“SpringUtil context initialized”。以后排查問題一看日志就知道這個組件有沒有被正確裝配。這個不起眼的細(xì)節(jié)在聯(lián)調(diào)環(huán)境里救過我很多次。