字段注入總為null？原理講透+五種解決方案實(shí)戰(zhàn)對(duì)比)
1. 這個(gè)讓無(wú)數(shù)Java開發(fā)者卡殼的問(wèn)題到底卡在哪只要用Spring做過(guò)幾年開發(fā)遲早會(huì)碰到這個(gè)需求想在工具類或者靜態(tài)方法里直接用Value或者Autowired把某個(gè)配置項(xiàng)或者某個(gè)Bean塞進(jìn)一個(gè)static字段里。結(jié)果寫完之后一跑字段還是null怎么注入都進(jìn)不去。網(wǎng)上搜一圈答案五花八門有的讓加Component有的讓寫setter有的直接說(shuō)靜態(tài)的不能注入。我早年第一次踩這個(gè)坑的時(shí)候以為是注解位置寫錯(cuò)了折騰了一下午才搞明白根本不是注解的問(wèn)題是Spring對(duì)象管理機(jī)制和Java靜態(tài)屬性本質(zhì)之間的沖突。這個(gè)坑之所以經(jīng)典是因?yàn)樗鼛缀跏敲總€(gè)Spring項(xiàng)目都會(huì)遇到的問(wèn)題。只要你是做Java后端開發(fā)的寫過(guò)工具類、靜態(tài)配置讀取、靜態(tài)緩存初始化這類代碼就繞不開它。哪怕你用Spring Boot寫了三年CRUD也遲早有一天會(huì)被一個(gè)靜態(tài)屬性的null卡住。先說(shuō)結(jié)論Spring的依賴注入是基于對(duì)象實(shí)例的而靜態(tài)屬性屬于類不是屬于實(shí)例。這個(gè)最基本的錯(cuò)位導(dǎo)致了你不管用Autowired還是Value直接標(biāo)注靜態(tài)字段Spring都無(wú)能為力。但是問(wèn)題既然存在解決方案自然也有。我這篇就把原理講透把常見的幾種解法都擺出來(lái)每個(gè)方案我會(huì)直接給出可復(fù)制的代碼、適用場(chǎng)景和坑點(diǎn)最后附上我實(shí)際項(xiàng)目里的完整案例。2. 先搞清楚Spring的Bean生命周期再說(shuō)為什么注入不進(jìn)靜態(tài)屬性2.1 Spring默認(rèn)注入機(jī)制的對(duì)象視角要理解這個(gè)問(wèn)題得先弄明白Spring是怎么把依賴送到你的代碼里的。Spring容器啟動(dòng)后會(huì)創(chuàng)建Bean實(shí)例然后掃描Autowired、Resource、Value這些注解在對(duì)象實(shí)例上進(jìn)行字段賦值或者調(diào)用setter方法。整個(gè)流程是實(shí)例化對(duì)象 → 屬性填充 → 初始化方法。你看這個(gè)流程的關(guān)鍵詞——實(shí)例化、對(duì)象、屬性填充全部都是針對(duì)實(shí)例層面。Spring容器維護(hù)的是一個(gè)個(gè)Bean實(shí)例這些實(shí)例被存在容器里當(dāng)你需要一個(gè)Bean時(shí)Spring把實(shí)例給你。而static字段是類級(jí)別的變量它不歸屬于任何一個(gè)實(shí)例類加載時(shí)就分配了內(nèi)存直接存在于方法區(qū)中按主流JVM的劃分方式來(lái)講的話。Spring的注入框架設(shè)計(jì)的初衷是管理對(duì)象圖和它們之間的依賴關(guān)系它通過(guò)對(duì)象引用來(lái)組裝系統(tǒng)。理論上它可以通過(guò)反射修改靜態(tài)字段的值——反射確實(shí)能做到所以問(wèn)題的關(guān)鍵不是技術(shù)上能不能改而是Spring默認(rèn)的設(shè)計(jì)根本就沒打算去處理靜態(tài)字段。它只處理實(shí)例字段這是它的工作邊界。2.2 為什么用了Autowired標(biāo)注static字段就是不行有人會(huì)想那我直接在字段上寫AutowiredSpring掃描的時(shí)候不該發(fā)現(xiàn)嗎這里有個(gè)容易被忽略的點(diǎn)Spring的依賴注入處理器比如AutowiredAnnotationBeanPostProcessor確實(shí)會(huì)掃描字段上的注解但它默認(rèn)處理的字段是實(shí)例字段。當(dāng)它判斷目標(biāo)字段帶有static修飾符時(shí)會(huì)直接跳過(guò)不做任何處理也不會(huì)報(bào)錯(cuò)。結(jié)果就是你的靜態(tài)字段依然是初始默認(rèn)值比如引用類型是null程序照常啟動(dòng)一切看起來(lái)正常但一調(diào)用就空指針。對(duì)于Value注入靜態(tài)字段也是如此。Spring在解析占位符比如${config.xxx}時(shí)只會(huì)把解析結(jié)果賦給實(shí)例字段。如果目標(biāo)字段是靜態(tài)的它不會(huì)去賦值日志里也不會(huì)出現(xiàn)任何異常提示這個(gè)靜默失敗的特性讓排查難度直接拉滿。2.3 日常開發(fā)中最常踩到靜態(tài)注入的場(chǎng)景這個(gè)需求幾乎都出現(xiàn)在工具類或者靜態(tài)方法里。我總結(jié)了一下主要就三種情況配置參數(shù)工具類一個(gè)ConfigUtil想用靜態(tài)方法getUploadPath()從配置文件里讀一個(gè)上傳路徑用Value(${file.upload-path})標(biāo)注靜態(tài)字段。靜態(tài)緩存/上下文類一個(gè)ContextHolder內(nèi)部有靜態(tài)Map或者靜態(tài)字段希望在應(yīng)用啟動(dòng)時(shí)從某個(gè)Bean里把數(shù)據(jù)填充進(jìn)去。工具類中調(diào)用業(yè)務(wù)服務(wù)一個(gè)DateUtil里需要調(diào)用某個(gè)第三方接口的客戶端Bean比如某個(gè)SDK的Client但工具方法全是靜態(tài)的沒法通過(guò)構(gòu)造器傳對(duì)象。這三種情況我都實(shí)際遇到過(guò)。很多人最初的直覺就是直接在靜態(tài)字段上加注解簡(jiǎn)單粗暴。結(jié)果就是null。然后開始懷疑注解語(yǔ)法、懷疑配置、懷疑Spring Boot版本最后才發(fā)現(xiàn)是靜態(tài)字段的鍋。3. 方案一setter方法注入最經(jīng)典的解法3.1 為什么setter方法能繞開這個(gè)限制既然靜態(tài)字段不能直接注入那就換個(gè)思路用非靜態(tài)的setter方法作為橋梁讓Spring把值通過(guò)實(shí)例方法傳進(jìn)來(lái)方法內(nèi)部再把值賦給靜態(tài)字段。這相當(dāng)于給靜態(tài)字段開了一個(gè)后門。因?yàn)閟etter方法本身是實(shí)例方法Spring完全可以通過(guò)反射調(diào)用它。Spring掃描到Autowired或Value標(biāo)注的方法時(shí)會(huì)執(zhí)行方法調(diào)用把依賴傳進(jìn)去方法內(nèi)部把參數(shù)賦給靜態(tài)字段。這樣就繞開了靜態(tài)字段不被處理的限制。3.2 配置類注入Value場(chǎng)景先看最簡(jiǎn)單、最常用的寫法比如要給靜態(tài)字段注入配置項(xiàng)Component public class FileConfig { private static String uploadPath; private static int maxFileSize; Value(${file.upload-path}) public void setUploadPath(String path) { FileConfig.uploadPath path; } Value(${file.max-size}) public void setMaxFileSize(int size) { FileConfig.maxFileSize size; } public static String getUploadPath() { return uploadPath; } public static int getMaxFileSize() { return maxFileSize; } }注意幾點(diǎn)類上必須加Component或者被Spring掃描到否則整個(gè)類都不會(huì)被容器管理setter方法永遠(yuǎn)不會(huì)被調(diào)用。方法名可以隨意關(guān)鍵是方法有Value注解Spring會(huì)把配置值解析后調(diào)用這個(gè)方法。這里我強(qiáng)烈建議在方法上加Value而不是在字段上加。雖然Spring也支持在方法參數(shù)上寫Value(${...})的方式但那種寫法在方法參數(shù)很多時(shí)容易混亂直接標(biāo)注方法最直觀。3.3 Bean依賴注入場(chǎng)景Autowired如果靜態(tài)字段需要的是一個(gè)Bean比如一個(gè)RedisTemplate或者某個(gè)服務(wù)類寫法類似Component public class CacheSupport { private static RedisTemplateString, Object redisTemplate; Autowired public void setRedisTemplate(RedisTemplateString, Object template) { CacheSupport.redisTemplate template; } public static void put(String key, Object value) { redisTemplate.opsForValue().set(key, value); } public static Object get(String key) { return redisTemplate.opsForValue().get(key); } }這里有個(gè)細(xì)節(jié)Autowired標(biāo)注的方法如果只有一個(gè)參數(shù)Spring會(huì)自動(dòng)按類型查找Bean并調(diào)用方法。這個(gè)方法可以是public、private甚至是包級(jí)可見的Spring都能調(diào)用。但我推薦用public一方面是語(yǔ)義清晰另一方面是某些代理機(jī)制對(duì)非public方法有潛在干擾雖然Spring自身反射調(diào)用沒問(wèn)題但沒必要給自己埋雷。3.4 這個(gè)方案的優(yōu)缺點(diǎn)和適用邊界這個(gè)方案是目前社區(qū)最主流、最推薦的方案。優(yōu)點(diǎn)很明顯代碼直觀理解成本低一個(gè)setter方法就能解決。不引入額外的復(fù)雜機(jī)制Spring原生支持。生命周期可信賴setter方法在Spring完成Bean屬性填充時(shí)調(diào)用時(shí)序可控。缺點(diǎn)也有一些靜態(tài)字段變成可變的了如果在后續(xù)代碼里不小心有人給靜態(tài)字段直接賦值可能造成意想不到的問(wèn)題。得額外寫setter方法代碼量會(huì)多一點(diǎn)。更重要的一個(gè)隱患如果有多個(gè)Spring上下文比如測(cè)試上下文、WebApplicationContext和RootApplicationContext并存這個(gè)類的靜態(tài)字段可能被不同容器反復(fù)賦值。雖然你在單上下文應(yīng)用里幾乎不會(huì)遇到但在某些老項(xiàng)目里要警惕。3.5 一個(gè)特別提示千萬(wàn)別在構(gòu)造器里給靜態(tài)字段賦值有人可能會(huì)說(shuō)既然setter能行那我直接在構(gòu)造器里寫this.uploadPath val不也一樣還真不一樣。Spring在實(shí)例化類時(shí)使用的是無(wú)參構(gòu)造器如果你把Value放在構(gòu)造器參數(shù)上構(gòu)造器注入會(huì)用另一種方式繞過(guò)靜態(tài)字段限制這個(gè)后面講。但如果你只是寫了一個(gè)普通的有參構(gòu)造器Spring實(shí)例化時(shí)根本不會(huì)調(diào)用它賦值邏輯不會(huì)執(zhí)行靜態(tài)字段還是null。還有人會(huì)在PostConstruct方法里給靜態(tài)字段賦值。這個(gè)方案的前提是這個(gè)類有實(shí)例字段能拿到值再在初始化方法里轉(zhuǎn)賦給靜態(tài)字段。這其實(shí)和setter方案是一個(gè)思路只是時(shí)機(jī)從setter階段挪到了初始化階段。如果你已經(jīng)有PostConstruct在做別的初始化邏輯順帶把靜態(tài)字段賦值進(jìn)去也是可以的。4. 方案二使用靜態(tài)代碼塊讀取Spring上下文直接暴力獲取4.1 ApplicationContextAware方案除了setter注入還有一類思路是繞過(guò)Spring注入機(jī)制直接獲取Spring容器然后從容器里拿Bean或者配置。這種方案的核心是讓某個(gè)工具類實(shí)現(xiàn)ApplicationContextAware接口把Spring容器存到靜態(tài)字段里之后在靜態(tài)代碼塊或者靜態(tài)方法中直接從容器獲取。Component public class SpringContextUtil implements ApplicationContextAware { private static ApplicationContext applicationContext; Override public void setApplicationContext(ApplicationContext context) throws BeansException { SpringContextUtil.applicationContext context; } public static T T getBean(ClassT clazz) { return applicationContext.getBean(clazz); } public static Object getBean(String name) { return applicationContext.getBean(name); } public static String getProperty(String key) { return applicationContext.getEnvironment().getProperty(key); } }寫好之后在任何一個(gè)靜態(tài)方法里都能這樣拿值public class CommonUtils { private static final String uploadPath; static { uploadPath SpringContextUtil.getProperty(file.upload-path); } public static String getUploadPath() { return uploadPath; } }靜態(tài)代碼塊在類加載的時(shí)候執(zhí)行SpringContextUtil里的容器肯定已經(jīng)初始化了嗎不一定。這個(gè)方案有一個(gè)致命時(shí)序問(wèn)題如果CommonUtils在Spring容器還沒完成初始化時(shí)就被某個(gè)類觸發(fā)了類加載靜態(tài)代碼塊執(zhí)行時(shí)SpringContextUtil.applicationContext還是null直接空指針。而且更麻煩的是類一旦加載完成靜態(tài)代碼塊不會(huì)再次執(zhí)行整個(gè)字段就永遠(yuǎn)都是初始值或者報(bào)錯(cuò)狀態(tài)。4.2 懶加載的單例持有者方案為了解決時(shí)序問(wèn)題可以用懶加載的方式把從容器取值的動(dòng)作推遲到靜態(tài)方法第一次被調(diào)用時(shí)Component public class SpringContextUtil implements ApplicationContextAware { private static ApplicationContext applicationContext; Override public void setApplicationContext(ApplicationContext context) { SpringContextUtil.applicationContext context; } public static ApplicationContext getApplicationContext() { return applicationContext; } } public class UploadPathHolder { public static String getUploadPath() { return SpringContextUtil.getApplicationContext() .getEnvironment() .getProperty(file.upload-path); } }每次調(diào)用都動(dòng)態(tài)從容器里獲取雖然多了一次容器查找的開銷但對(duì)于讀配置這種操作微乎其微換來(lái)的是絕對(duì)可靠的時(shí)序。這個(gè)方案的典型使用場(chǎng)景是工具類本身不想被Spring管理不想加Component又確實(shí)需要讀取Spring環(huán)境配置或獲取某個(gè)Bean。它讓你在任何普通類、任何靜態(tài)方法里都能拿到Spring容器里的東西靈活性極高。不過(guò)這個(gè)方案的缺點(diǎn)是侵入性比較強(qiáng)項(xiàng)目中多了一個(gè)靜態(tài)持有ApplicationContext的類等于全局暴露了容器。團(tuán)隊(duì)協(xié)作時(shí)別人可能隨手就在代碼里到處用SpringContextUtil.getBean(xxx)導(dǎo)致依賴關(guān)系變得隱蔽代碼的可測(cè)試性下降。我的建議是這只作為兜底手段在極少數(shù)setter方案無(wú)法處理的場(chǎng)景下才用。5. 方案三構(gòu)造器注入 靜態(tài)持有適合新代碼的優(yōu)雅做法5.1 用實(shí)例包裝靜態(tài)依賴如果你寫的是新代碼從設(shè)計(jì)角度考慮最干凈的做法是不要試圖讓靜態(tài)屬性直接依賴Spring而是在建一個(gè)非靜態(tài)的組件作為接口內(nèi)部通過(guò)靜態(tài)字段暴露訪問(wèn)點(diǎn)。這個(gè)方案比直接setter更優(yōu)雅的地方在于靜態(tài)字段使用final修飾不可變性更好也不存在被后續(xù)代碼篡改的風(fēng)險(xiǎn)。Component public class DateService { private static DateService instance; private final DateTimeFormatter formatter; private final ZoneId zoneId; public DateService(DateTimeFormatter formatter, ZoneId zoneId) { this.formatter formatter; this.zoneId zoneId; DateService.instance this; } public static DateService getInstance() { return instance; } public String format(LocalDateTime dateTime) { return formatter.format(dateTime); } public ZoneId getZoneId() { return zoneId; } }這個(gè)方案利用構(gòu)造器注入的時(shí)機(jī)Spring在構(gòu)造Bean實(shí)例時(shí)可以傳入依賴在構(gòu)造器內(nèi)部把當(dāng)前實(shí)例賦給靜態(tài)字段。因?yàn)镾pring的構(gòu)造器注入在非常早期就完成了后續(xù)其他依賴這個(gè)靜態(tài)字段的代碼調(diào)用DateService.getInstance()時(shí)實(shí)例引用已經(jīng)就緒。這個(gè)模式和setter方案本質(zhì)上是類似的但它在靜態(tài)字段持有實(shí)例而不是靜態(tài)字段直接持有值這個(gè)粒度上做了區(qū)分語(yǔ)義更清晰外部工具類通過(guò)DateService.getInstance().format(date)來(lái)使用服務(wù)而不是直接操作一大把靜態(tài)字段。5.2 什么時(shí)候優(yōu)先推薦構(gòu)造器持有我自己的經(jīng)驗(yàn)是當(dāng)這個(gè)工具類內(nèi)部有多個(gè)依賴超過(guò)2個(gè)Bean或配置項(xiàng)時(shí)優(yōu)先考慮這種靜態(tài)單例持有實(shí)例的模式。因?yàn)閟etter方案里靜態(tài)字段會(huì)越來(lái)越多工具類的公共靜態(tài)方法卻只是簡(jiǎn)單轉(zhuǎn)發(fā)代碼會(huì)顯得凌亂。而持有實(shí)例后調(diào)用方跟工具類的靜態(tài)方法解耦后續(xù)功能擴(kuò)展時(shí)你只需要改DateService內(nèi)部方法即可調(diào)用方無(wú)感。舉個(gè)例子一個(gè)工具類需要 Redis、KafkaTemplate、ObjectMapper 三個(gè)Bean用setter方案你要寫private static RedisTemplate redisTemplate; private static KafkaTemplate kafkaTemplate; private static ObjectMapper objectMapper; Autowired public void setRedisTemplate(RedisTemplate template) { ... } Autowired public void setKafkaTemplate(KafkaTemplate template) { ... } Autowired public void setObjectMapper(ObjectMapper mapper) { ... }代碼冗長(zhǎng)而且外部調(diào)用時(shí)依然通過(guò)靜態(tài)方法。如果用實(shí)例持有方案外部直接MessageTool.getInstance().sendMsg(...)內(nèi)部依賴全部作為實(shí)例字段由構(gòu)造器一次性傳入寫起來(lái)干凈很多。5.3 要注意實(shí)例可能為null這個(gè)方案有一個(gè)需要說(shuō)明的地方Spring容器加載是有順序的如果你的某個(gè)靜態(tài)方法在Spring完成這個(gè)工具Bean的構(gòu)造之前就被調(diào)用了instance可能還是null。通常只要不是啟動(dòng)早期階段這個(gè)問(wèn)題不會(huì)出現(xiàn)因?yàn)轭惣虞d并調(diào)用靜態(tài)方法通常發(fā)生在請(qǐng)求進(jìn)來(lái)之后Spring早就初始化完成了。但如果你是初始化監(jiān)聽器、定時(shí)任務(wù)這種啟動(dòng)階段代碼就得謹(jǐn)慎。此時(shí)穩(wěn)妥的做法是配合PostConstruct或者SmartInitializingSingleton做啟動(dòng)檢查確保靜態(tài)實(shí)例已就緒。6. 方案四通過(guò)Environment獲取配置最被低估的做法6.1 不注入字段直接每次讀環(huán)境前面講的方案都在把值注入到靜態(tài)字段這條路上繞來(lái)繞去。但我們換個(gè)思路靜態(tài)方法里其實(shí)不一定需要預(yù)先持有值完全可以每次調(diào)用時(shí)從Spring的Environment直接讀取配置。環(huán)境對(duì)象本身是確定的、只需要一次拿到的依賴。實(shí)現(xiàn)方式和ApplicationContextAware大同小異但更輕量Component public class ConfigEnv { private static Environment environment; Autowired public void setEnvironment(Environment env) { ConfigEnv.environment env; } public static String get(String key) { return environment.getProperty(key); } public static String get(String key, String defaultValue) { return environment.getProperty(key, defaultValue); } }使用端public class UploadUtil { public static String getUploadPath() { return ConfigEnv.get(file.upload-path, /tmp); } public static int getMaxFileSize() { return ConfigEnv.get(file.max-size, Integer.class, 1048576); } }這個(gè)做法的好處是靜態(tài)工具類不需要持有任何可變靜態(tài)字段每次調(diào)用從Environment讀最新值。這在配置中心動(dòng)態(tài)刷新場(chǎng)景下非常有用——比如配置在運(yùn)行時(shí)被修改了你不需要重新啟動(dòng)就能讀到新值。而前面setter方案注入的值是一次性的配置刷新后靜態(tài)字段里的舊值不會(huì)自己更新。6.2 跟ConfigurationProperties配合的升級(jí)版如果配置項(xiàng)很多比如有幾十個(gè)配置項(xiàng)工具類一個(gè)個(gè)去讀會(huì)寫到手酸。更優(yōu)雅的姿勢(shì)是用ConfigurationProperties建一個(gè)配置對(duì)象然后把這個(gè)對(duì)象注入給工具類的靜態(tài)字段Component ConfigurationProperties(prefix file) public class FileProperties { private String uploadPath; private int maxFileSize; public String getUploadPath() { return uploadPath; } public void setUploadPath(String uploadPath) { this.uploadPath uploadPath; } public int getMaxFileSize() { return maxFileSize; } public void setMaxFileSize(int maxFileSize) { this.maxFileSize maxFileSize; } }然后和setter方案結(jié)合Component public class FileConfigBridge { private static FileProperties fileProperties; Autowired public void setFileProperties(FileProperties props) { FileConfigBridge.fileProperties props; } public static FileProperties getProperties() { return fileProperties; } }之后工具類里通過(guò)FileConfigBridge.getProperties().getUploadPath()取值。這樣配置結(jié)構(gòu)清晰還能自動(dòng)獲得IDE的代碼補(bǔ)全配置項(xiàng)不會(huì)拼錯(cuò)字符串。我強(qiáng)烈推薦在配置項(xiàng)超過(guò)5個(gè)的場(chǎng)景用這種方式比散落的Value字符串好維護(hù)太多。7. 五種方案的橫評(píng)和選型建議我把能用的方案整理成一張表方便你對(duì)照選型方案核心思路優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景setter方法注入非靜態(tài)setter轉(zhuǎn)賦靜態(tài)字段簡(jiǎn)潔直觀Spring原生支持靜態(tài)字段可變配置刷新不生效大多數(shù)普通工具類ApplicationContextAware 靜態(tài)代碼塊獲取容器提前初始化不依賴Spring管理工具類時(shí)序風(fēng)險(xiǎn)大易類加載空指針盡量不推薦ApplicationContextAware 懶加載每次調(diào)用動(dòng)態(tài)獲取時(shí)序安全靈活通用全局暴露容器依賴隱蔽兜底方案特殊場(chǎng)景構(gòu)造器持有靜態(tài)實(shí)例靜態(tài)實(shí)例引用Bean結(jié)構(gòu)清晰適合多依賴啟動(dòng)早期可能為null新代碼多功能工具類Environment直接讀取每次動(dòng)態(tài)讀取配置支持配置刷新無(wú)靜態(tài)可變字段每次取值多一次環(huán)境查找配置動(dòng)態(tài)刷新場(chǎng)景說(shuō)實(shí)話我自己項(xiàng)目中90%的場(chǎng)景用setter方法注入就夠了剩下的10%基本是配置項(xiàng)比較多或者有動(dòng)態(tài)刷新需求會(huì)搭配ConfigurationProperties加Environment方案。至于ApplicationContextAware這種萬(wàn)能工具類我一般是當(dāng)作項(xiàng)目里的基礎(chǔ)設(shè)施放置一個(gè)SpringContextUtil備用但不鼓勵(lì)業(yè)務(wù)代碼里到處直接getBean。8. 實(shí)際項(xiàng)目中的完整案例從零寫一個(gè)靜態(tài)配置工具類8.1 需求場(chǎng)景假設(shè)項(xiàng)目里需要一個(gè)SmsUtil短信工具類所有業(yè)務(wù)代碼通過(guò)靜態(tài)方法發(fā)送短信。它需要以下依賴短信平臺(tái)配置appId、appSecret、signName來(lái)自配置文件RedisTemplate用于短信頻率限制、驗(yàn)證碼存儲(chǔ)一個(gè)SmsClientBean真正調(diào)用短信網(wǎng)關(guān)的客戶端8.2 兩種實(shí)現(xiàn)的完整代碼我先用setter方案寫一版Component public class SmsUtil { private static String appId; private static String appSecret; private static String signName; private static RedisTemplateString, Object redisTemplate; private static SmsClient smsClient; Value(${sms.app-id}) public void setAppId(String appId) { SmsUtil.appId appId; } Value(${sms.app-secret}) public void setAppSecret(String appSecret) { SmsUtil.appSecret appSecret; } Value(${sms.sign-name}) public void setSignName(String signName) { SmsUtil.signName signName; } Autowired public void setRedisTemplate(RedisTemplateString, Object template) { SmsUtil.redisTemplate template; } Autowired public void setSmsClient(SmsClient client) { SmsUtil.smsClient client; } public static boolean sendVerifyCode(String phone, String code) { String key sms:code: phone; // 同一號(hào)碼一分鐘內(nèi)只允許發(fā)送一次 Boolean exists redisTemplate.hasKey(key); if (Boolean.TRUE.equals(exists)) { return false; } redisTemplate.opsForValue().set(key, code, 5, TimeUnit.MINUTES); return smsClient.send(phone, signName, String.format(您的驗(yàn)證碼是%s5分鐘內(nèi)有效, code)); } public static boolean verifyCode(String phone, String code) { String key sms:code: phone; Object saved redisTemplate.opsForValue().get(key); if (saved ! null saved.toString().equals(code)) { redisTemplate.delete(key); return true; } return false; } }這套代碼在真實(shí)項(xiàng)目中可以直接用。業(yè)務(wù)代碼里就是SmsUtil.sendVerifyCode(138xxxx, 123456)這么簡(jiǎn)單完全不需要從Spring容器里取什么東西。再說(shuō)一遍使用條件SmsUtil必須被Spring掃描到。如果你把它放在掃描路徑之外或者類上沒加Component那么setter方法一次都不會(huì)被調(diào)用靜態(tài)字段全部是null運(yùn)行時(shí)會(huì)空指針。這是這個(gè)方案最容易被忽略的前提。再看另一個(gè)升級(jí)思路如果配置項(xiàng)很多我會(huì)把配置部分抽象成SmsPropertiesComponent ConfigurationProperties(prefix sms) public class SmsProperties { private String appId; private String appSecret; private String signName; // getter / setter 省略 }然后SmsUtil里只需要兩個(gè)setterComponent public class SmsUtil { private static SmsProperties smsProperties; private static SmsClient smsClient; Autowired public void setSmsProperties(SmsProperties props) { SmsUtil.smsProperties props; } Autowired public void setSmsClient(SmsClient client) { SmsUtil.smsClient client; } public static boolean sendVerifyCode(String phone, String code) { String template String.format(您的驗(yàn)證碼是%s5分鐘內(nèi)有效, code); return smsClient.send(phone, smsProperties.getSignName(), template); } }配置刷新、屬性校驗(yàn)都塞到SmsProperties里SmsUtil只關(guān)心業(yè)務(wù)邏輯職責(zé)劃分更清楚。8.3 多實(shí)例場(chǎng)景或者單元測(cè)試環(huán)境下的坑這個(gè)案例里還有一個(gè)容易踩的坑單元測(cè)試時(shí)Spring上下文沒有完全加載靜態(tài)字段不會(huì)通過(guò)setter被賦值。你如果想純寫一個(gè)POJO單測(cè)去測(cè)SmsUtil.sendVerifyCode會(huì)發(fā)現(xiàn)redisTemplate是null。解決方式一種是mockito去mock靜態(tài)方法但靜態(tài)方法mock比較麻煩。更推薦的是給SmsUtil增加一個(gè)包級(jí)可見的重新初始化方法用來(lái)在測(cè)試?yán)镒⑷雖ock對(duì)象VisibleForTesting static void reinitForTest(SmsProperties props, SmsClient client) { SmsUtil.smsProperties props; SmsUtil.smsClient client; }這樣測(cè)試?yán)镎{(diào)用SmsUtil.reinitForTest(mockProps, mockClient)就能注入mock不影響生產(chǎn)邏輯。這個(gè)方法雖然是為了測(cè)試開的口子但在團(tuán)隊(duì)開發(fā)中非常實(shí)用能少踩不少集成測(cè)試的坑。8.4 關(guān)于靜態(tài)字段的final修飾符爭(zhēng)論可能有人問(wèn)既然setter能賦靜態(tài)字段那我把字段定義成private static final再用setter賦值行不行答案是編譯都過(guò)不了。final表示這個(gè)字段只能賦值一次而且要求是在聲明處或者構(gòu)造器里初始化普通類的靜態(tài)final字段必須在靜態(tài)代碼塊中賦值。setter方法是在運(yùn)行時(shí)才調(diào)用的編譯器不允許你這么做。所以setter方案里的靜態(tài)字段必須是可變的不能加final。如果你追求final的不可變效果就得回到方案三的構(gòu)造器持有靜態(tài)實(shí)例思路靜態(tài)字段保存的是實(shí)例引用實(shí)例內(nèi)部的具體依賴可以都是final的。9. 常見問(wèn)題速查與獨(dú)家避坑清單9.1 靜態(tài)字段注入為null時(shí)的排查順序我遇到過(guò)不少同事拿著這個(gè)問(wèn)題來(lái)問(wèn)排查順序基本是固定的第一步確認(rèn)類被Spring掃描到。檢查類上有沒有Component/Service/Configuration等注解或者是不是在ComponentScan的掃描路徑下面。一個(gè)比較好的自檢手段在setter方法里加一行System.out.println或者打日志如果啟動(dòng)時(shí)沒有打印說(shuō)明類根本沒被管理。第二步確認(rèn)方法被識(shí)別。Value或者Autowired標(biāo)注的方法是否真的被調(diào)用。如果類被掃描到了但是方法沒被調(diào)用看看是不是方法簽名有問(wèn)題比如Value寫法里Spring解析占位符失敗導(dǎo)致啟動(dòng)報(bào)錯(cuò)占位符找不到配置項(xiàng)時(shí)默認(rèn)會(huì)啟動(dòng)失敗反而更容易排查。第三步確認(rèn)沒有多個(gè)Spring上下文。有些老項(xiàng)目用Spring SpringMVC或者Spring Spring Boot共存ContextLoaderListener和DispatcherServlet各創(chuàng)建一個(gè)容器你在一個(gè)容器里注入的值可能被另一個(gè)容器的setter調(diào)用覆蓋回null。這種情況最隱蔽而且很難從日志里看出來(lái)。排查方式在setter里打印一下當(dāng)前線程的上下文類名看看有沒有多個(gè)容器在調(diào)。第四步確認(rèn)靜態(tài)字段沒有被其他地方顯式置空。有些同事會(huì)在代碼里隨手xxx null這就沒辦法了。9.2 靜態(tài)字段在多線程下的可見性Spring setter方法注入發(fā)生在啟動(dòng)階段之后靜態(tài)字段就只讀不寫了所以基本不存在并發(fā)問(wèn)題。但如果在運(yùn)行時(shí)通過(guò)某種手段比如動(dòng)態(tài)配置刷新去修改靜態(tài)字段就得考慮可見性問(wèn)題。Java內(nèi)存模型不保證靜態(tài)字段在多線程下的可見性除非你用volatile或者加鎖。穩(wěn)妥做法如果靜態(tài)字段必然會(huì)在運(yùn)行時(shí)被更新聲明成private static volatile。雖然大部分場(chǎng)景用不上但一旦用上這個(gè)細(xì)節(jié)能幫你省掉很多詭異的偶發(fā)問(wèn)題。9.3 為什么我推薦盡量少用PostConstruct方案有一種常見的方案是先把依賴注入到實(shí)例字段再在PostConstruct里賦值給靜態(tài)字段。比如Component public class SomeHolder { Autowired private SomeService service; private static SomeService staticService; PostConstruct public void init() { SomeHolder.staticService this.service; } }這個(gè)方案能用但有一個(gè)潛在問(wèn)題PostConstruct的執(zhí)行時(shí)機(jī)是在Spring完成屬性填充之后、Bean初始化階段。如果你的某個(gè)靜態(tài)方法在Bean初始化之前就被調(diào)用了比如在另一個(gè)Bean的構(gòu)造器里調(diào)用或者某些非常早期的初始化代碼靜態(tài)字段就是null。而setter方案里只要依賴的對(duì)象屬性填充完成值就一定寫進(jìn)去了。兩者在時(shí)序上有微妙的差別setter階段比PostConstruct更早。所以如果兩者選其一我選setter方案。9.4 一個(gè)真正干凈的終極方案重新設(shè)計(jì)其實(shí)從架構(gòu)角度說(shuō)靜態(tài)屬性注入這個(gè)需求本身往往意味著設(shè)計(jì)上有可以優(yōu)化的地方。Spring的依賴注入機(jī)制鼓勵(lì)你用組合和實(shí)例方法而不是全局靜態(tài)狀態(tài)。如果業(yè)務(wù)代碼全都在Spring容器管理下最好別把依賴塞進(jìn)靜態(tài)方法而是直接注入Bean。但現(xiàn)實(shí)是工具類靜態(tài)方法在很多項(xiàng)目里太常見了徹底改造的成本很高。所以我的建議是新代碼盡量少寫全局靜態(tài)工具類老代碼用setter方案做最小改動(dòng)。如果有一天你發(fā)現(xiàn)靜態(tài)方法越來(lái)越多依賴越來(lái)越多那就是時(shí)候考慮把工具類改成實(shí)例Bean或者用方案三重構(gòu)了。9.5 我的一點(diǎn)實(shí)操心得踩過(guò)這個(gè)坑之后我現(xiàn)在寫工具類的習(xí)慣已經(jīng)固化了第一所有需要配置或依賴的靜態(tài)工具類統(tǒng)一用setter注入模式而且類上明確加Component便于他人識(shí)別第二配置項(xiàng)超過(guò)3個(gè)就建ConfigurationProperties類不讓Value散落遍地第三測(cè)試需要時(shí)保留一個(gè)reinitForTest的口子。這幾條規(guī)則讓我后面在這個(gè)問(wèn)題上幾乎沒再花過(guò)時(shí)間。最后分享一個(gè)容易被忽略的順帶好處setter注入方案的類也可以被繼承和重寫。因?yàn)樗瞧胀⊿pring組件你在測(cè)試?yán)锟梢灾苯觧ew一個(gè)實(shí)例調(diào)用setter注入自己的假數(shù)據(jù)再驗(yàn)證靜態(tài)方法邏輯而不需要真的去啟動(dòng)整個(gè)Spring容器。這個(gè)靈活性是直接Autowired靜態(tài)字段的方案完全做不到的。 Spring靜態(tài)字段注入總為null？原理講透+五種解決方案實(shí)戰(zhàn)對(duì)比
1. 這個(gè)讓無(wú)數(shù)Java開發(fā)者卡殼的問(wèn)題到底卡在哪只要用Spring做過(guò)幾年開發(fā)遲早會(huì)碰到這個(gè)需求想在工具類或者靜態(tài)方法里直接用Value或者Autowired把某個(gè)配置項(xiàng)或者某個(gè)Bean塞進(jìn)一個(gè)static字段里。結(jié)果寫完之后一跑字段還是null怎么注入都進(jìn)不去。網(wǎng)上搜一圈答案五花八門有的讓加Component有的讓寫setter有的直接說(shuō)靜態(tài)的不能注入。我早年第一次踩這個(gè)坑的時(shí)候以為是注解位置寫錯(cuò)了折騰了一下午才搞明白根本不是注解的問(wèn)題是Spring對(duì)象管理機(jī)制和Java靜態(tài)屬性本質(zhì)之間的沖突。這個(gè)坑之所以經(jīng)典是因?yàn)樗鼛缀跏敲總€(gè)Spring項(xiàng)目都會(huì)遇到的問(wèn)題。只要你是做Java后端開發(fā)的寫過(guò)工具類、靜態(tài)配置讀取、靜態(tài)緩存初始化這類代碼就繞不開它。哪怕你用Spring Boot寫了三年CRUD也遲早有一天會(huì)被一個(gè)靜態(tài)屬性的null卡住。先說(shuō)結(jié)論Spring的依賴注入是基于對(duì)象實(shí)例的而靜態(tài)屬性屬于類不是屬于實(shí)例。這個(gè)最基本的錯(cuò)位導(dǎo)致了你不管用Autowired還是Value直接標(biāo)注靜態(tài)字段Spring都無(wú)能為力。但是問(wèn)題既然存在解決方案自然也有。我這篇就把原理講透把常見的幾種解法都擺出來(lái)每個(gè)方案我會(huì)直接給出可復(fù)制的代碼、適用場(chǎng)景和坑點(diǎn)最后附上我實(shí)際項(xiàng)目里的完整案例。2. 先搞清楚Spring的Bean生命周期再說(shuō)為什么注入不進(jìn)靜態(tài)屬性2.1 Spring默認(rèn)注入機(jī)制的對(duì)象視角要理解這個(gè)問(wèn)題得先弄明白Spring是怎么把依賴送到你的代碼里的。Spring容器啟動(dòng)后會(huì)創(chuàng)建Bean實(shí)例然后掃描Autowired、Resource、Value這些注解在對(duì)象實(shí)例上進(jìn)行字段賦值或者調(diào)用setter方法。整個(gè)流程是實(shí)例化對(duì)象 → 屬性填充 → 初始化方法。你看這個(gè)流程的關(guān)鍵詞——實(shí)例化、對(duì)象、屬性填充全部都是針對(duì)實(shí)例層面。Spring容器維護(hù)的是一個(gè)個(gè)Bean實(shí)例這些實(shí)例被存在容器里當(dāng)你需要一個(gè)Bean時(shí)Spring把實(shí)例給你。而static字段是類級(jí)別的變量它不歸屬于任何一個(gè)實(shí)例類加載時(shí)就分配了內(nèi)存直接存在于方法區(qū)中按主流JVM的劃分方式來(lái)講的話。Spring的注入框架設(shè)計(jì)的初衷是管理對(duì)象圖和它們之間的依賴關(guān)系它通過(guò)對(duì)象引用來(lái)組裝系統(tǒng)。理論上它可以通過(guò)反射修改靜態(tài)字段的值——反射確實(shí)能做到所以問(wèn)題的關(guān)鍵不是技術(shù)上能不能改而是Spring默認(rèn)的設(shè)計(jì)根本就沒打算去處理靜態(tài)字段。它只處理實(shí)例字段這是它的工作邊界。2.2 為什么用了Autowired標(biāo)注static字段就是不行有人會(huì)想那我直接在字段上寫AutowiredSpring掃描的時(shí)候不該發(fā)現(xiàn)嗎這里有個(gè)容易被忽略的點(diǎn)Spring的依賴注入處理器比如AutowiredAnnotationBeanPostProcessor確實(shí)會(huì)掃描字段上的注解但它默認(rèn)處理的字段是實(shí)例字段。當(dāng)它判斷目標(biāo)字段帶有static修飾符時(shí)會(huì)直接跳過(guò)不做任何處理也不會(huì)報(bào)錯(cuò)。結(jié)果就是你的靜態(tài)字段依然是初始默認(rèn)值比如引用類型是null程序照常啟動(dòng)一切看起來(lái)正常但一調(diào)用就空指針。對(duì)于Value注入靜態(tài)字段也是如此。Spring在解析占位符比如${config.xxx}時(shí)只會(huì)把解析結(jié)果賦給實(shí)例字段。如果目標(biāo)字段是靜態(tài)的它不會(huì)去賦值日志里也不會(huì)出現(xiàn)任何異常提示這個(gè)靜默失敗的特性讓排查難度直接拉滿。2.3 日常開發(fā)中最常踩到靜態(tài)注入的場(chǎng)景這個(gè)需求幾乎都出現(xiàn)在工具類或者靜態(tài)方法里。我總結(jié)了一下主要就三種情況配置參數(shù)工具類一個(gè)ConfigUtil想用靜態(tài)方法getUploadPath()從配置文件里讀一個(gè)上傳路徑用Value(${file.upload-path})標(biāo)注靜態(tài)字段。靜態(tài)緩存/上下文類一個(gè)ContextHolder內(nèi)部有靜態(tài)Map或者靜態(tài)字段希望在應(yīng)用啟動(dòng)時(shí)從某個(gè)Bean里把數(shù)據(jù)填充進(jìn)去。工具類中調(diào)用業(yè)務(wù)服務(wù)一個(gè)DateUtil里需要調(diào)用某個(gè)第三方接口的客戶端Bean比如某個(gè)SDK的Client但工具方法全是靜態(tài)的沒法通過(guò)構(gòu)造器傳對(duì)象。這三種情況我都實(shí)際遇到過(guò)。很多人最初的直覺就是直接在靜態(tài)字段上加注解簡(jiǎn)單粗暴。結(jié)果就是null。然后開始懷疑注解語(yǔ)法、懷疑配置、懷疑Spring Boot版本最后才發(fā)現(xiàn)是靜態(tài)字段的鍋。3. 方案一setter方法注入最經(jīng)典的解法3.1 為什么setter方法能繞開這個(gè)限制既然靜態(tài)字段不能直接注入那就換個(gè)思路用非靜態(tài)的setter方法作為橋梁讓Spring把值通過(guò)實(shí)例方法傳進(jìn)來(lái)方法內(nèi)部再把值賦給靜態(tài)字段。這相當(dāng)于給靜態(tài)字段開了一個(gè)后門。因?yàn)閟etter方法本身是實(shí)例方法Spring完全可以通過(guò)反射調(diào)用它。Spring掃描到Autowired或Value標(biāo)注的方法時(shí)會(huì)執(zhí)行方法調(diào)用把依賴傳進(jìn)去方法內(nèi)部把參數(shù)賦給靜態(tài)字段。這樣就繞開了靜態(tài)字段不被處理的限制。3.2 配置類注入Value場(chǎng)景先看最簡(jiǎn)單、最常用的寫法比如要給靜態(tài)字段注入配置項(xiàng)Component public class FileConfig { private static String uploadPath; private static int maxFileSize; Value(${file.upload-path}) public void setUploadPath(String path) { FileConfig.uploadPath path; } Value(${file.max-size}) public void setMaxFileSize(int size) { FileConfig.maxFileSize size; } public static String getUploadPath() { return uploadPath; } public static int getMaxFileSize() { return maxFileSize; } }注意幾點(diǎn)類上必須加Component或者被Spring掃描到否則整個(gè)類都不會(huì)被容器管理setter方法永遠(yuǎn)不會(huì)被調(diào)用。方法名可以隨意關(guān)鍵是方法有Value注解Spring會(huì)把配置值解析后調(diào)用這個(gè)方法。這里我強(qiáng)烈建議在方法上加Value而不是在字段上加。雖然Spring也支持在方法參數(shù)上寫Value(${...})的方式但那種寫法在方法參數(shù)很多時(shí)容易混亂直接標(biāo)注方法最直觀。3.3 Bean依賴注入場(chǎng)景Autowired如果靜態(tài)字段需要的是一個(gè)Bean比如一個(gè)RedisTemplate或者某個(gè)服務(wù)類寫法類似Component public class CacheSupport { private static RedisTemplateString, Object redisTemplate; Autowired public void setRedisTemplate(RedisTemplateString, Object template) { CacheSupport.redisTemplate template; } public static void put(String key, Object value) { redisTemplate.opsForValue().set(key, value); } public static Object get(String key) { return redisTemplate.opsForValue().get(key); } }這里有個(gè)細(xì)節(jié)Autowired標(biāo)注的方法如果只有一個(gè)參數(shù)Spring會(huì)自動(dòng)按類型查找Bean并調(diào)用方法。這個(gè)方法可以是public、private甚至是包級(jí)可見的Spring都能調(diào)用。但我推薦用public一方面是語(yǔ)義清晰另一方面是某些代理機(jī)制對(duì)非public方法有潛在干擾雖然Spring自身反射調(diào)用沒問(wèn)題但沒必要給自己埋雷。3.4 這個(gè)方案的優(yōu)缺點(diǎn)和適用邊界這個(gè)方案是目前社區(qū)最主流、最推薦的方案。優(yōu)點(diǎn)很明顯代碼直觀理解成本低一個(gè)setter方法就能解決。不引入額外的復(fù)雜機(jī)制Spring原生支持。生命周期可信賴setter方法在Spring完成Bean屬性填充時(shí)調(diào)用時(shí)序可控。缺點(diǎn)也有一些靜態(tài)字段變成可變的了如果在后續(xù)代碼里不小心有人給靜態(tài)字段直接賦值可能造成意想不到的問(wèn)題。得額外寫setter方法代碼量會(huì)多一點(diǎn)。更重要的一個(gè)隱患如果有多個(gè)Spring上下文比如測(cè)試上下文、WebApplicationContext和RootApplicationContext并存這個(gè)類的靜態(tài)字段可能被不同容器反復(fù)賦值。雖然你在單上下文應(yīng)用里幾乎不會(huì)遇到但在某些老項(xiàng)目里要警惕。3.5 一個(gè)特別提示千萬(wàn)別在構(gòu)造器里給靜態(tài)字段賦值有人可能會(huì)說(shuō)既然setter能行那我直接在構(gòu)造器里寫this.uploadPath val不也一樣還真不一樣。Spring在實(shí)例化類時(shí)使用的是無(wú)參構(gòu)造器如果你把Value放在構(gòu)造器參數(shù)上構(gòu)造器注入會(huì)用另一種方式繞過(guò)靜態(tài)字段限制這個(gè)后面講。但如果你只是寫了一個(gè)普通的有參構(gòu)造器Spring實(shí)例化時(shí)根本不會(huì)調(diào)用它賦值邏輯不會(huì)執(zhí)行靜態(tài)字段還是null。還有人會(huì)在PostConstruct方法里給靜態(tài)字段賦值。這個(gè)方案的前提是這個(gè)類有實(shí)例字段能拿到值再在初始化方法里轉(zhuǎn)賦給靜態(tài)字段。這其實(shí)和setter方案是一個(gè)思路只是時(shí)機(jī)從setter階段挪到了初始化階段。如果你已經(jīng)有PostConstruct在做別的初始化邏輯順帶把靜態(tài)字段賦值進(jìn)去也是可以的。4. 方案二使用靜態(tài)代碼塊讀取Spring上下文直接暴力獲取4.1 ApplicationContextAware方案除了setter注入還有一類思路是繞過(guò)Spring注入機(jī)制直接獲取Spring容器然后從容器里拿Bean或者配置。這種方案的核心是讓某個(gè)工具類實(shí)現(xiàn)ApplicationContextAware接口把Spring容器存到靜態(tài)字段里之后在靜態(tài)代碼塊或者靜態(tài)方法中直接從容器獲取。Component public class SpringContextUtil implements ApplicationContextAware { private static ApplicationContext applicationContext; Override public void setApplicationContext(ApplicationContext context) throws BeansException { SpringContextUtil.applicationContext context; } public static T T getBean(ClassT clazz) { return applicationContext.getBean(clazz); } public static Object getBean(String name) { return applicationContext.getBean(name); } public static String getProperty(String key) { return applicationContext.getEnvironment().getProperty(key); } }寫好之后在任何一個(gè)靜態(tài)方法里都能這樣拿值public class CommonUtils { private static final String uploadPath; static { uploadPath SpringContextUtil.getProperty(file.upload-path); } public static String getUploadPath() { return uploadPath; } }靜態(tài)代碼塊在類加載的時(shí)候執(zhí)行SpringContextUtil里的容器肯定已經(jīng)初始化了嗎不一定。這個(gè)方案有一個(gè)致命時(shí)序問(wèn)題如果CommonUtils在Spring容器還沒完成初始化時(shí)就被某個(gè)類觸發(fā)了類加載靜態(tài)代碼塊執(zhí)行時(shí)SpringContextUtil.applicationContext還是null直接空指針。而且更麻煩的是類一旦加載完成靜態(tài)代碼塊不會(huì)再次執(zhí)行整個(gè)字段就永遠(yuǎn)都是初始值或者報(bào)錯(cuò)狀態(tài)。4.2 懶加載的單例持有者方案為了解決時(shí)序問(wèn)題可以用懶加載的方式把從容器取值的動(dòng)作推遲到靜態(tài)方法第一次被調(diào)用時(shí)Component public class SpringContextUtil implements ApplicationContextAware { private static ApplicationContext applicationContext; Override public void setApplicationContext(ApplicationContext context) { SpringContextUtil.applicationContext context; } public static ApplicationContext getApplicationContext() { return applicationContext; } } public class UploadPathHolder { public static String getUploadPath() { return SpringContextUtil.getApplicationContext() .getEnvironment() .getProperty(file.upload-path); } }每次調(diào)用都動(dòng)態(tài)從容器里獲取雖然多了一次容器查找的開銷但對(duì)于讀配置這種操作微乎其微換來(lái)的是絕對(duì)可靠的時(shí)序。這個(gè)方案的典型使用場(chǎng)景是工具類本身不想被Spring管理不想加Component又確實(shí)需要讀取Spring環(huán)境配置或獲取某個(gè)Bean。它讓你在任何普通類、任何靜態(tài)方法里都能拿到Spring容器里的東西靈活性極高。不過(guò)這個(gè)方案的缺點(diǎn)是侵入性比較強(qiáng)項(xiàng)目中多了一個(gè)靜態(tài)持有ApplicationContext的類等于全局暴露了容器。團(tuán)隊(duì)協(xié)作時(shí)別人可能隨手就在代碼里到處用SpringContextUtil.getBean(xxx)導(dǎo)致依賴關(guān)系變得隱蔽代碼的可測(cè)試性下降。我的建議是這只作為兜底手段在極少數(shù)setter方案無(wú)法處理的場(chǎng)景下才用。5. 方案三構(gòu)造器注入 靜態(tài)持有適合新代碼的優(yōu)雅做法5.1 用實(shí)例包裝靜態(tài)依賴如果你寫的是新代碼從設(shè)計(jì)角度考慮最干凈的做法是不要試圖讓靜態(tài)屬性直接依賴Spring而是在建一個(gè)非靜態(tài)的組件作為接口內(nèi)部通過(guò)靜態(tài)字段暴露訪問(wèn)點(diǎn)。這個(gè)方案比直接setter更優(yōu)雅的地方在于靜態(tài)字段使用final修飾不可變性更好也不存在被后續(xù)代碼篡改的風(fēng)險(xiǎn)。Component public class DateService { private static DateService instance; private final DateTimeFormatter formatter; private final ZoneId zoneId; public DateService(DateTimeFormatter formatter, ZoneId zoneId) { this.formatter formatter; this.zoneId zoneId; DateService.instance this; } public static DateService getInstance() { return instance; } public String format(LocalDateTime dateTime) { return formatter.format(dateTime); } public ZoneId getZoneId() { return zoneId; } }這個(gè)方案利用構(gòu)造器注入的時(shí)機(jī)Spring在構(gòu)造Bean實(shí)例時(shí)可以傳入依賴在構(gòu)造器內(nèi)部把當(dāng)前實(shí)例賦給靜態(tài)字段。因?yàn)镾pring的構(gòu)造器注入在非常早期就完成了后續(xù)其他依賴這個(gè)靜態(tài)字段的代碼調(diào)用DateService.getInstance()時(shí)實(shí)例引用已經(jīng)就緒。這個(gè)模式和setter方案本質(zhì)上是類似的但它在靜態(tài)字段持有實(shí)例而不是靜態(tài)字段直接持有值這個(gè)粒度上做了區(qū)分語(yǔ)義更清晰外部工具類通過(guò)DateService.getInstance().format(date)來(lái)使用服務(wù)而不是直接操作一大把靜態(tài)字段。5.2 什么時(shí)候優(yōu)先推薦構(gòu)造器持有我自己的經(jīng)驗(yàn)是當(dāng)這個(gè)工具類內(nèi)部有多個(gè)依賴超過(guò)2個(gè)Bean或配置項(xiàng)時(shí)優(yōu)先考慮這種靜態(tài)單例持有實(shí)例的模式。因?yàn)閟etter方案里靜態(tài)字段會(huì)越來(lái)越多工具類的公共靜態(tài)方法卻只是簡(jiǎn)單轉(zhuǎn)發(fā)代碼會(huì)顯得凌亂。而持有實(shí)例后調(diào)用方跟工具類的靜態(tài)方法解耦后續(xù)功能擴(kuò)展時(shí)你只需要改DateService內(nèi)部方法即可調(diào)用方無(wú)感。舉個(gè)例子一個(gè)工具類需要 Redis、KafkaTemplate、ObjectMapper 三個(gè)Bean用setter方案你要寫private static RedisTemplate redisTemplate; private static KafkaTemplate kafkaTemplate; private static ObjectMapper objectMapper; Autowired public void setRedisTemplate(RedisTemplate template) { ... } Autowired public void setKafkaTemplate(KafkaTemplate template) { ... } Autowired public void setObjectMapper(ObjectMapper mapper) { ... }代碼冗長(zhǎng)而且外部調(diào)用時(shí)依然通過(guò)靜態(tài)方法。如果用實(shí)例持有方案外部直接MessageTool.getInstance().sendMsg(...)內(nèi)部依賴全部作為實(shí)例字段由構(gòu)造器一次性傳入寫起來(lái)干凈很多。5.3 要注意實(shí)例可能為null這個(gè)方案有一個(gè)需要說(shuō)明的地方Spring容器加載是有順序的如果你的某個(gè)靜態(tài)方法在Spring完成這個(gè)工具Bean的構(gòu)造之前就被調(diào)用了instance可能還是null。通常只要不是啟動(dòng)早期階段這個(gè)問(wèn)題不會(huì)出現(xiàn)因?yàn)轭惣虞d并調(diào)用靜態(tài)方法通常發(fā)生在請(qǐng)求進(jìn)來(lái)之后Spring早就初始化完成了。但如果你是初始化監(jiān)聽器、定時(shí)任務(wù)這種啟動(dòng)階段代碼就得謹(jǐn)慎。此時(shí)穩(wěn)妥的做法是配合PostConstruct或者SmartInitializingSingleton做啟動(dòng)檢查確保靜態(tài)實(shí)例已就緒。6. 方案四通過(guò)Environment獲取配置最被低估的做法6.1 不注入字段直接每次讀環(huán)境前面講的方案都在把值注入到靜態(tài)字段這條路上繞來(lái)繞去。但我們換個(gè)思路靜態(tài)方法里其實(shí)不一定需要預(yù)先持有值完全可以每次調(diào)用時(shí)從Spring的Environment直接讀取配置。環(huán)境對(duì)象本身是確定的、只需要一次拿到的依賴。實(shí)現(xiàn)方式和ApplicationContextAware大同小異但更輕量Component public class ConfigEnv { private static Environment environment; Autowired public void setEnvironment(Environment env) { ConfigEnv.environment env; } public static String get(String key) { return environment.getProperty(key); } public static String get(String key, String defaultValue) { return environment.getProperty(key, defaultValue); } }使用端public class UploadUtil { public static String getUploadPath() { return ConfigEnv.get(file.upload-path, /tmp); } public static int getMaxFileSize() { return ConfigEnv.get(file.max-size, Integer.class, 1048576); } }這個(gè)做法的好處是靜態(tài)工具類不需要持有任何可變靜態(tài)字段每次調(diào)用從Environment讀最新值。這在配置中心動(dòng)態(tài)刷新場(chǎng)景下非常有用——比如配置在運(yùn)行時(shí)被修改了你不需要重新啟動(dòng)就能讀到新值。而前面setter方案注入的值是一次性的配置刷新后靜態(tài)字段里的舊值不會(huì)自己更新。6.2 跟ConfigurationProperties配合的升級(jí)版如果配置項(xiàng)很多比如有幾十個(gè)配置項(xiàng)工具類一個(gè)個(gè)去讀會(huì)寫到手酸。更優(yōu)雅的姿勢(shì)是用ConfigurationProperties建一個(gè)配置對(duì)象然后把這個(gè)對(duì)象注入給工具類的靜態(tài)字段Component ConfigurationProperties(prefix file) public class FileProperties { private String uploadPath; private int maxFileSize; public String getUploadPath() { return uploadPath; } public void setUploadPath(String uploadPath) { this.uploadPath uploadPath; } public int getMaxFileSize() { return maxFileSize; } public void setMaxFileSize(int maxFileSize) { this.maxFileSize maxFileSize; } }然后和setter方案結(jié)合Component public class FileConfigBridge { private static FileProperties fileProperties; Autowired public void setFileProperties(FileProperties props) { FileConfigBridge.fileProperties props; } public static FileProperties getProperties() { return fileProperties; } }之后工具類里通過(guò)FileConfigBridge.getProperties().getUploadPath()取值。這樣配置結(jié)構(gòu)清晰還能自動(dòng)獲得IDE的代碼補(bǔ)全配置項(xiàng)不會(huì)拼錯(cuò)字符串。我強(qiáng)烈推薦在配置項(xiàng)超過(guò)5個(gè)的場(chǎng)景用這種方式比散落的Value字符串好維護(hù)太多。7. 五種方案的橫評(píng)和選型建議我把能用的方案整理成一張表方便你對(duì)照選型方案核心思路優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景setter方法注入非靜態(tài)setter轉(zhuǎn)賦靜態(tài)字段簡(jiǎn)潔直觀Spring原生支持靜態(tài)字段可變配置刷新不生效大多數(shù)普通工具類ApplicationContextAware 靜態(tài)代碼塊獲取容器提前初始化不依賴Spring管理工具類時(shí)序風(fēng)險(xiǎn)大易類加載空指針盡量不推薦ApplicationContextAware 懶加載每次調(diào)用動(dòng)態(tài)獲取時(shí)序安全靈活通用全局暴露容器依賴隱蔽兜底方案特殊場(chǎng)景構(gòu)造器持有靜態(tài)實(shí)例靜態(tài)實(shí)例引用Bean結(jié)構(gòu)清晰適合多依賴啟動(dòng)早期可能為null新代碼多功能工具類Environment直接讀取每次動(dòng)態(tài)讀取配置支持配置刷新無(wú)靜態(tài)可變字段每次取值多一次環(huán)境查找配置動(dòng)態(tài)刷新場(chǎng)景說(shuō)實(shí)話我自己項(xiàng)目中90%的場(chǎng)景用setter方法注入就夠了剩下的10%基本是配置項(xiàng)比較多或者有動(dòng)態(tài)刷新需求會(huì)搭配ConfigurationProperties加Environment方案。至于ApplicationContextAware這種萬(wàn)能工具類我一般是當(dāng)作項(xiàng)目里的基礎(chǔ)設(shè)施放置一個(gè)SpringContextUtil備用但不鼓勵(lì)業(yè)務(wù)代碼里到處直接getBean。8. 實(shí)際項(xiàng)目中的完整案例從零寫一個(gè)靜態(tài)配置工具類8.1 需求場(chǎng)景假設(shè)項(xiàng)目里需要一個(gè)SmsUtil短信工具類所有業(yè)務(wù)代碼通過(guò)靜態(tài)方法發(fā)送短信。它需要以下依賴短信平臺(tái)配置appId、appSecret、signName來(lái)自配置文件RedisTemplate用于短信頻率限制、驗(yàn)證碼存儲(chǔ)一個(gè)SmsClientBean真正調(diào)用短信網(wǎng)關(guān)的客戶端8.2 兩種實(shí)現(xiàn)的完整代碼我先用setter方案寫一版Component public class SmsUtil { private static String appId; private static String appSecret; private static String signName; private static RedisTemplateString, Object redisTemplate; private static SmsClient smsClient; Value(${sms.app-id}) public void setAppId(String appId) { SmsUtil.appId appId; } Value(${sms.app-secret}) public void setAppSecret(String appSecret) { SmsUtil.appSecret appSecret; } Value(${sms.sign-name}) public void setSignName(String signName) { SmsUtil.signName signName; } Autowired public void setRedisTemplate(RedisTemplateString, Object template) { SmsUtil.redisTemplate template; } Autowired public void setSmsClient(SmsClient client) { SmsUtil.smsClient client; } public static boolean sendVerifyCode(String phone, String code) { String key sms:code: phone; // 同一號(hào)碼一分鐘內(nèi)只允許發(fā)送一次 Boolean exists redisTemplate.hasKey(key); if (Boolean.TRUE.equals(exists)) { return false; } redisTemplate.opsForValue().set(key, code, 5, TimeUnit.MINUTES); return smsClient.send(phone, signName, String.format(您的驗(yàn)證碼是%s5分鐘內(nèi)有效, code)); } public static boolean verifyCode(String phone, String code) { String key sms:code: phone; Object saved redisTemplate.opsForValue().get(key); if (saved ! null saved.toString().equals(code)) { redisTemplate.delete(key); return true; } return false; } }這套代碼在真實(shí)項(xiàng)目中可以直接用。業(yè)務(wù)代碼里就是SmsUtil.sendVerifyCode(138xxxx, 123456)這么簡(jiǎn)單完全不需要從Spring容器里取什么東西。再說(shuō)一遍使用條件SmsUtil必須被Spring掃描到。如果你把它放在掃描路徑之外或者類上沒加Component那么setter方法一次都不會(huì)被調(diào)用靜態(tài)字段全部是null運(yùn)行時(shí)會(huì)空指針。這是這個(gè)方案最容易被忽略的前提。再看另一個(gè)升級(jí)思路如果配置項(xiàng)很多我會(huì)把配置部分抽象成SmsPropertiesComponent ConfigurationProperties(prefix sms) public class SmsProperties { private String appId; private String appSecret; private String signName; // getter / setter 省略 }然后SmsUtil里只需要兩個(gè)setterComponent public class SmsUtil { private static SmsProperties smsProperties; private static SmsClient smsClient; Autowired public void setSmsProperties(SmsProperties props) { SmsUtil.smsProperties props; } Autowired public void setSmsClient(SmsClient client) { SmsUtil.smsClient client; } public static boolean sendVerifyCode(String phone, String code) { String template String.format(您的驗(yàn)證碼是%s5分鐘內(nèi)有效, code); return smsClient.send(phone, smsProperties.getSignName(), template); } }配置刷新、屬性校驗(yàn)都塞到SmsProperties里SmsUtil只關(guān)心業(yè)務(wù)邏輯職責(zé)劃分更清楚。8.3 多實(shí)例場(chǎng)景或者單元測(cè)試環(huán)境下的坑這個(gè)案例里還有一個(gè)容易踩的坑單元測(cè)試時(shí)Spring上下文沒有完全加載靜態(tài)字段不會(huì)通過(guò)setter被賦值。你如果想純寫一個(gè)POJO單測(cè)去測(cè)SmsUtil.sendVerifyCode會(huì)發(fā)現(xiàn)redisTemplate是null。解決方式一種是mockito去mock靜態(tài)方法但靜態(tài)方法mock比較麻煩。更推薦的是給SmsUtil增加一個(gè)包級(jí)可見的重新初始化方法用來(lái)在測(cè)試?yán)镒⑷雖ock對(duì)象VisibleForTesting static void reinitForTest(SmsProperties props, SmsClient client) { SmsUtil.smsProperties props; SmsUtil.smsClient client; }這樣測(cè)試?yán)镎{(diào)用SmsUtil.reinitForTest(mockProps, mockClient)就能注入mock不影響生產(chǎn)邏輯。這個(gè)方法雖然是為了測(cè)試開的口子但在團(tuán)隊(duì)開發(fā)中非常實(shí)用能少踩不少集成測(cè)試的坑。8.4 關(guān)于靜態(tài)字段的final修飾符爭(zhēng)論可能有人問(wèn)既然setter能賦靜態(tài)字段那我把字段定義成private static final再用setter賦值行不行答案是編譯都過(guò)不了。final表示這個(gè)字段只能賦值一次而且要求是在聲明處或者構(gòu)造器里初始化普通類的靜態(tài)final字段必須在靜態(tài)代碼塊中賦值。setter方法是在運(yùn)行時(shí)才調(diào)用的編譯器不允許你這么做。所以setter方案里的靜態(tài)字段必須是可變的不能加final。如果你追求final的不可變效果就得回到方案三的構(gòu)造器持有靜態(tài)實(shí)例思路靜態(tài)字段保存的是實(shí)例引用實(shí)例內(nèi)部的具體依賴可以都是final的。9. 常見問(wèn)題速查與獨(dú)家避坑清單9.1 靜態(tài)字段注入為null時(shí)的排查順序我遇到過(guò)不少同事拿著這個(gè)問(wèn)題來(lái)問(wèn)排查順序基本是固定的第一步確認(rèn)類被Spring掃描到。檢查類上有沒有Component/Service/Configuration等注解或者是不是在ComponentScan的掃描路徑下面。一個(gè)比較好的自檢手段在setter方法里加一行System.out.println或者打日志如果啟動(dòng)時(shí)沒有打印說(shuō)明類根本沒被管理。第二步確認(rèn)方法被識(shí)別。Value或者Autowired標(biāo)注的方法是否真的被調(diào)用。如果類被掃描到了但是方法沒被調(diào)用看看是不是方法簽名有問(wèn)題比如Value寫法里Spring解析占位符失敗導(dǎo)致啟動(dòng)報(bào)錯(cuò)占位符找不到配置項(xiàng)時(shí)默認(rèn)會(huì)啟動(dòng)失敗反而更容易排查。第三步確認(rèn)沒有多個(gè)Spring上下文。有些老項(xiàng)目用Spring SpringMVC或者Spring Spring Boot共存ContextLoaderListener和DispatcherServlet各創(chuàng)建一個(gè)容器你在一個(gè)容器里注入的值可能被另一個(gè)容器的setter調(diào)用覆蓋回null。這種情況最隱蔽而且很難從日志里看出來(lái)。排查方式在setter里打印一下當(dāng)前線程的上下文類名看看有沒有多個(gè)容器在調(diào)。第四步確認(rèn)靜態(tài)字段沒有被其他地方顯式置空。有些同事會(huì)在代碼里隨手xxx null這就沒辦法了。9.2 靜態(tài)字段在多線程下的可見性Spring setter方法注入發(fā)生在啟動(dòng)階段之后靜態(tài)字段就只讀不寫了所以基本不存在并發(fā)問(wèn)題。但如果在運(yùn)行時(shí)通過(guò)某種手段比如動(dòng)態(tài)配置刷新去修改靜態(tài)字段就得考慮可見性問(wèn)題。Java內(nèi)存模型不保證靜態(tài)字段在多線程下的可見性除非你用volatile或者加鎖。穩(wěn)妥做法如果靜態(tài)字段必然會(huì)在運(yùn)行時(shí)被更新聲明成private static volatile。雖然大部分場(chǎng)景用不上但一旦用上這個(gè)細(xì)節(jié)能幫你省掉很多詭異的偶發(fā)問(wèn)題。9.3 為什么我推薦盡量少用PostConstruct方案有一種常見的方案是先把依賴注入到實(shí)例字段再在PostConstruct里賦值給靜態(tài)字段。比如Component public class SomeHolder { Autowired private SomeService service; private static SomeService staticService; PostConstruct public void init() { SomeHolder.staticService this.service; } }這個(gè)方案能用但有一個(gè)潛在問(wèn)題PostConstruct的執(zhí)行時(shí)機(jī)是在Spring完成屬性填充之后、Bean初始化階段。如果你的某個(gè)靜態(tài)方法在Bean初始化之前就被調(diào)用了比如在另一個(gè)Bean的構(gòu)造器里調(diào)用或者某些非常早期的初始化代碼靜態(tài)字段就是null。而setter方案里只要依賴的對(duì)象屬性填充完成值就一定寫進(jìn)去了。兩者在時(shí)序上有微妙的差別setter階段比PostConstruct更早。所以如果兩者選其一我選setter方案。9.4 一個(gè)真正干凈的終極方案重新設(shè)計(jì)其實(shí)從架構(gòu)角度說(shuō)靜態(tài)屬性注入這個(gè)需求本身往往意味著設(shè)計(jì)上有可以優(yōu)化的地方。Spring的依賴注入機(jī)制鼓勵(lì)你用組合和實(shí)例方法而不是全局靜態(tài)狀態(tài)。如果業(yè)務(wù)代碼全都在Spring容器管理下最好別把依賴塞進(jìn)靜態(tài)方法而是直接注入Bean。但現(xiàn)實(shí)是工具類靜態(tài)方法在很多項(xiàng)目里太常見了徹底改造的成本很高。所以我的建議是新代碼盡量少寫全局靜態(tài)工具類老代碼用setter方案做最小改動(dòng)。如果有一天你發(fā)現(xiàn)靜態(tài)方法越來(lái)越多依賴越來(lái)越多那就是時(shí)候考慮把工具類改成實(shí)例Bean或者用方案三重構(gòu)了。9.5 我的一點(diǎn)實(shí)操心得踩過(guò)這個(gè)坑之后我現(xiàn)在寫工具類的習(xí)慣已經(jīng)固化了第一所有需要配置或依賴的靜態(tài)工具類統(tǒng)一用setter注入模式而且類上明確加Component便于他人識(shí)別第二配置項(xiàng)超過(guò)3個(gè)就建ConfigurationProperties類不讓Value散落遍地第三測(cè)試需要時(shí)保留一個(gè)reinitForTest的口子。這幾條規(guī)則讓我后面在這個(gè)問(wèn)題上幾乎沒再花過(guò)時(shí)間。最后分享一個(gè)容易被忽略的順帶好處setter注入方案的類也可以被繼承和重寫。因?yàn)樗瞧胀⊿pring組件你在測(cè)試?yán)锟梢灾苯觧ew一個(gè)實(shí)例調(diào)用setter注入自己的假數(shù)據(jù)再驗(yàn)證靜態(tài)方法邏輯而不需要真的去啟動(dòng)整個(gè)Spring容器。這個(gè)靈活性是直接Autowired靜態(tài)字段的方案完全做不到的。