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