直接開聊。Spring Bean的生命周期這幾乎是所有Java后端工程師繞不開的話題面試要問出問題要排查寫框架組件要用。網(wǎng)上講這個(gè)的文章一抓一大把但很多要么是源碼流水賬要么是八股文式的階段背誦讀完你還是不知道怎么用它解決實(shí)際問題。我準(zhǔn)備換個(gè)講法不列枯燥的階段表而是直接從為什么需要理解它切入把生命周期里最關(guān)鍵的幾個(gè)擴(kuò)展點(diǎn)、循環(huán)依賴對(duì)生命周期的影響、作用域如何改寫生命周期這些真正影響你寫代碼的東西講透最后附上我實(shí)際排查過的幾個(gè)詭異報(bào)錯(cuò)。這篇東西適合剛學(xué)Spring想建立整體認(rèn)知的初學(xué)者也適合寫了好幾年業(yè)務(wù)代碼但沒系統(tǒng)梳理過Bean生命周期的老手。1. 一張圖看懂Spring Bean從誕生到銷毀的全過程先別急著記那些生僻接口我們先建立整體畫面感。一個(gè)Bean在Spring容器里從無到有大致要經(jīng)過這么幾個(gè)階段實(shí)例化構(gòu)造函數(shù)/工廠方法 ↓ 屬性填充依賴注入 ↓ Aware回調(diào)BeanNameAware、BeanFactoryAware、ApplicationContextAware ↓ BeanPostProcessor前置處理postProcessBeforeInitialization ↓ 初始化InitializingBean.afterPropertiesSet / PostConstruct / init-method ↓ BeanPostProcessor后置處理postProcessAfterInitialization ↓ 就緒開始被使用 ↓ 容器關(guān)閉 → 銷毀DisposableBean.destroy / PreDestroy / destroy-method注意我故意把PostConstruct和InitializingBean、init-method放在同一個(gè)階段里是因?yàn)樗鼈儽举|(zhì)上都是在初始化這個(gè)時(shí)機(jī)執(zhí)行的但是執(zhí)行順序有講究。這個(gè)后面單獨(dú)講。1.1 實(shí)例化和屬性填充Bean的出生與進(jìn)食實(shí)例化這一步很多人有誤解覺得不就是new一個(gè)對(duì)象嗎對(duì)也不對(duì)。Spring確實(shí)是通過構(gòu)造函數(shù)創(chuàng)建Bean實(shí)例的但它不是簡簡單單地調(diào)用構(gòu)造函數(shù)就完事而是先拿到BeanDefinition判斷是構(gòu)造器注入還是無參構(gòu)造再?zèng)Q定怎么創(chuàng)建。如果你用了構(gòu)造器注入那Spring得先把構(gòu)造函數(shù)所需的所有依賴都準(zhǔn)備好才能進(jìn)行實(shí)例化。這也是為什么構(gòu)造器注入只適合強(qiáng)依賴的場景——它要求依賴必須先存在。實(shí)例化完成之后是屬性填充也就是我們常說的依賴注入。這里要特別注意Autowired、Resource、Value這些注解的解析都是在屬性填充階段完成的。也就是說當(dāng)一個(gè)Bean的屬性填充階段跑完它的普通字段依賴、配置值、引用的其他Bean基本都已經(jīng)就位了。如果你在構(gòu)造函數(shù)里直接使用this.someService這種字段大概率拿到的是null原因就在這里——Spring還沒走到屬性填充這一步。1.2 初始化階段Bean的成人禮對(duì)象new出來了屬性也都填充好了但這時(shí)候Bean還不是一個(gè)完全體。比如你可能需要在依賴全部注入后做一些數(shù)據(jù)初始化、資源打開、緩存預(yù)熱、校驗(yàn)配置等工作。這些工作就應(yīng)該放在初始化階段做。Spring提供了一堆在初始化階段做文章的入口我把它們按優(yōu)先級(jí)列一下PostConstruct注解標(biāo)注的方法InitializingBean接口的afterPropertiesSet()方法Bean(initMethod ...)或XML里配置的init-method網(wǎng)上有很多文章說這幾個(gè)的執(zhí)行順序是固定的但在我的實(shí)測(cè)中順序是PostConstruct先執(zhí)行然后是afterPropertiesSet()最后是initMethod。注意Spring不同版本在細(xì)節(jié)上可能有調(diào)整但大體就是這個(gè)順序。為什么PostConstruct排最前面因?yàn)樗贘DK里定義CommonAnnotationBeanPostProcessor這個(gè)處理器會(huì)優(yōu)先處理它。1.3 銷毀階段Bean的身后事容器關(guān)閉的時(shí)候Spring會(huì)執(zhí)行Bean的銷毀邏輯。同樣有三個(gè)入口PreDestroy注解標(biāo)注的方法DisposableBean接口的destroy()方法Bean(destroyMethod ...)或XML里的destroy-method銷毀階段主要用于釋放資源比如關(guān)閉數(shù)據(jù)庫連接池、關(guān)閉線程池、解除注冊(cè)表項(xiàng)等。我這里踩過一個(gè)很典型的坑單例Bean持有線程池如果不在銷毀階段顯式關(guān)閉線程池應(yīng)用重啟時(shí)經(jīng)常出現(xiàn)線程泄漏的告警。2. 為什么Bean生命周期值得你花時(shí)間搞懂——三個(gè)扎心場景前面流程看上去不算復(fù)雜但真正值錢的是理解這些階段背后能解決什么問題。我見過太多人在這幾個(gè)場景栽跟頭全是因?yàn)閷?duì)生命周期理解不透。2.1 場景一靜態(tài)工具類里使用Spring Bean調(diào)用時(shí)總是報(bào)空指針這個(gè)場景極其常見。有人寫了一個(gè)RedisUtils靜態(tài)工具類然后在里面定義了一個(gè)靜態(tài)的RedisTemplate字段想著通過Autowired給它賦值結(jié)果運(yùn)行時(shí)發(fā)現(xiàn)字段始終是null。問題出在哪靜態(tài)字段的注入不是Spring的默認(rèn)能力。Autowired只能作用于Spring管理的Bean實(shí)例上靜態(tài)字段屬于類級(jí)別Spring不會(huì)幫你自動(dòng)注入。這時(shí)候正確的做法是讓RedisUtils成為一個(gè)Spring Bean然后在Bean初始化階段把自身賦給靜態(tài)字段。比如實(shí)現(xiàn)InitializingBean接口Component public class RedisUtils implements InitializingBean { private static RedisTemplateString, String redisTemplate; Resource private RedisTemplateString, String injectedRedisTemplate; Override public void afterPropertiesSet() { redisTemplate injectedRedisTemplate; } public static String get(String key) { return redisTemplate.opsForValue().get(key); } }這個(gè)小技巧的本質(zhì)就是把實(shí)例注入轉(zhuǎn)化為靜態(tài)字段初始化而完成轉(zhuǎn)換的時(shí)機(jī)就是Bean生命周期中的afterPropertiesSet()階段。理解了生命周期你才能明白這段代碼為什么這么寫。2.2 場景二配置類里Bean初始化依賴了另一個(gè)Bean的中間狀態(tài)數(shù)據(jù)對(duì)不上很多人在Configuration配置類里這么寫B(tài)ean public DataSource dataSource() { DataSource dataSource new HikariDataSource(); // 設(shè)置一堆參數(shù) return dataSource; } Bean public JdbcTemplate jdbcTemplate(DataSource dataSource) { return new JdbcTemplate(dataSource); }看起來沒問題但如果dataSource()方法里依賴了一個(gè)尚未初始化完成的Bean就很容易踩坑。比如你在dataSource()里讀取一個(gè)配置Bean的屬性而這個(gè)配置Bean本身也在初始化中那讀到的可能就是默認(rèn)值不是最終值。這就是生命周期理解不夠造成的。配置Bean如果實(shí)現(xiàn)了InitializingBean那只有等它的afterPropertiesSet()跑完它的屬性才真正就位。你在另一個(gè)Bean的創(chuàng)建過程里去讀它時(shí)機(jī)上是不可控的。解決辦法一是把依賴關(guān)系理清楚二是利用DependsOn強(qiáng)制指定順序三是在ApplicationRunner之類的階段做后置檢查。2.3 場景三攔截器或過濾器里面注入的Service為null這也是老生常談的問題了。你在Spring MVC里注冊(cè)了一個(gè)HandlerInterceptor然后在里面Autowired了一個(gè)UserService結(jié)果請(qǐng)求進(jìn)來的時(shí)候發(fā)現(xiàn)userService是null。原因并不復(fù)雜攔截器實(shí)例可能不是Spring Bean而是通過WebMvcConfigurer.addInterceptors()注冊(cè)時(shí)手動(dòng)new出來的。手動(dòng)new出來的對(duì)象不在Spring容器管理范圍內(nèi)Spring自然不會(huì)幫你做依賴注入。這個(gè)問題的解法依然是讓攔截器本身成為Spring BeanComponent public class AuthInterceptor implements HandlerInterceptor { Resource private UserService userService; // ... }然后在配置類里注入這個(gè)BeanConfiguration public class WebConfig implements WebMvcConfigurer { Resource private AuthInterceptor authInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authInterceptor).addPathPatterns(/**); } }這里面的核心邏輯還是一樣讓Bean的創(chuàng)建和依賴注入都交給Spring托管Spring才有機(jī)會(huì)在生命周期里完成注入動(dòng)作。反過來說每當(dāng)你發(fā)現(xiàn)一個(gè)對(duì)象無法使用自動(dòng)注入時(shí)第一反應(yīng)應(yīng)該是它到底是不是Spring管理的Bean。3. 核心擴(kuò)展點(diǎn)拆解BeanPostProcessor與各類Aware接口的實(shí)戰(zhàn)玩法如果說Bean生命周期是一臺(tái)精密儀器那BeanPostProcessor就是你在儀器上裝的各種傳感器和閥門。Spring的AOP、代理、注解處理統(tǒng)統(tǒng)依賴它。3.1 BeanPostProcessor每個(gè)Bean初始化前后的必經(jīng)檢查站先看一個(gè)簡單示例Component public class LogBeanPostProcessor implements BeanPostProcessor { Override public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { if (bean instanceof UserService) { System.out.println([BEFORE] beanName 即將初始化); } return bean; } Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { if (bean instanceof UserService) { System.out.println([AFTER] beanName 初始化完成); } return bean; } }注意兩個(gè)重點(diǎn)。第一postProcessAfterInitialization的返回值非常關(guān)鍵。如果你想對(duì)某個(gè)Bean做代理增強(qiáng)比如Transactional、Async的代理生成就是在這個(gè)方法里把原始Bean替換成代理Bean的。如果你在這里返回nullSpring之后的流程會(huì)直接出問題因?yàn)槿萜髂玫降囊镁蛿嗔?。第二BeanPostProcessor是針對(duì)容器內(nèi)所有Bean的不是單個(gè)Bean。所以寫的時(shí)候一定要做好類型過濾否則日志量會(huì)爆炸性能也會(huì)受影響。3.2 用BeanPostProcessor模擬Spring AOP的代理增強(qiáng)過程理解了BeanPostProcessor你其實(shí)就理解了Spring AOP的動(dòng)態(tài)代理是從哪里介入的。我寫個(gè)簡化版的代理邏輯給你看Component public class LogAspectBeanPostProcessor implements BeanPostProcessor { Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { if (bean instanceof OrderService) { Object proxyBean Proxy.newProxyInstance( bean.getClass().getClassLoader(), bean.getClass().getInterfaces(), (proxy, method, args) - { System.out.println([AOP] 方法執(zhí)行前: method.getName()); Object result method.invoke(bean, args); System.out.println([AOP] 方法執(zhí)行后: method.getName()); return result; } ); return proxyBean; } return bean; } }這段代碼雖然簡陋但和Spring AOP在生命周期中做代理的時(shí)機(jī)是一致的目標(biāo)Bean已經(jīng)完成初始化然后在postProcessAfterInitialization階段被包裝成代理對(duì)象。代理對(duì)象替換了原始對(duì)象后續(xù)所有通過容器獲取的Bean拿到的都是這個(gè)代理。這解釋了另一個(gè)經(jīng)典問題為什么this調(diào)用同一個(gè)類中的Transactional方法時(shí)事務(wù)不生效因?yàn)槭聞?wù)代理只對(duì)從容器中取出的引用有效this指向的是原始對(duì)象不是代理對(duì)象方法調(diào)用直接走原始邏輯事務(wù)沒有介入的機(jī)會(huì)。3.3 Aware接口全家桶讓Bean知道自己在容器里的身份Aware接口是一組以Aware結(jié)尾的接口作用是給Bean注入容器層面的信息。常用的有這些接口注入的信息典型用途BeanNameAwareBean在容器中的名稱需要感知自己beanName的場景BeanFactoryAware所屬的BeanFactory需要?jiǎng)討B(tài)獲取其他Bean的工廠場景ApplicationContextAware容器上下文獲取Spring容器中的各種能力EnvironmentAware環(huán)境配置讀取環(huán)境變量、配置文件的場景ResourceLoaderAware資源加載器加載classpath下資源的場景這里我說一下實(shí)際經(jīng)驗(yàn)。ApplicationContextAware是使用率最高的一個(gè)很多人喜歡在工具類里通過它獲取ApplicationContext然后實(shí)現(xiàn)一個(gè)SpringContextHolder。但要注意ApplicationContextAware回調(diào)發(fā)生在Bean初始化之前的Aware階段所以不要在實(shí)現(xiàn)類的主構(gòu)造函數(shù)中直接調(diào)用SpringContextHolder.getBean()因?yàn)槿萜骺赡苓€沒調(diào)用Aware回調(diào)此時(shí)工具類里的applicationContext字段還是null。3.4 初始化三種寫法的選型建議PostConstruct、InitializingBean、init-method都能在初始化階段干活那我該用哪個(gè)我的建議是業(yè)務(wù)代碼優(yōu)先用PostConstruct因?yàn)樗荍ava標(biāo)準(zhǔn)注解不依賴Spring特有接口將來如果脫離Spring環(huán)境代碼可遷移性更強(qiáng)?？蚣艽a或者通用組件可以考慮InitializingBean因?yàn)樗荢pring原生機(jī)制語義明確處理順序上更可控。init-method適合在配置類里給第三方庫的Bean做初始化動(dòng)作不需要改第三方代碼。4. 三級(jí)緩存與循環(huán)依賴生命周期中隱藏的作弊機(jī)制既然聊生命周期就繞不開循環(huán)依賴這個(gè)話題。熱搜詞里也有spring三級(jí)緩存原理這確實(shí)是Spring生命周期中最讓人迷惑的設(shè)計(jì)之一。4.1 為什么循環(huán)依賴會(huì)和生命周期沖突先看一個(gè)典型的循環(huán)依賴場景Service public class UserService { Resource private OrderService orderService; } Service public class OrderService { Resource private UserService userService; }如果沒有特殊機(jī)制這個(gè)場景會(huì)直接導(dǎo)致創(chuàng)建失敗。原因順著生命周期思考就清楚了。當(dāng)Spring創(chuàng)建UserService時(shí)先實(shí)例化對(duì)象然后進(jìn)入屬性填充階段發(fā)現(xiàn)需要OrderService于是轉(zhuǎn)而去創(chuàng)建OrderService。OrderService實(shí)例化后進(jìn)入屬性填充發(fā)現(xiàn)需要UserService于是又轉(zhuǎn)回去創(chuàng)建UserService。但是此刻UserService還在創(chuàng)建過程中沒有走到postProcessAfterInitialization嚴(yán)格來說它還不能算一個(gè)完整的Bean。如果Spring死板地等UserService完全初始化那雙方就僵住了永遠(yuǎn)等不到對(duì)方就緒形成死鎖。Spring的解決辦法是提前暴露半成品對(duì)象。也就是在UserService實(shí)例化完成、尚未完成屬性填充和初始化的時(shí)候先把這個(gè)半成品引用存入一個(gè)緩存讓后續(xù)需要它的Bean可以先拿著這個(gè)引用頂著等UserService徹底初始化完成后再去補(bǔ)充完整能力。這個(gè)半成品緩存的機(jī)制就是三級(jí)緩存的核心邏輯。4.2 三級(jí)緩存到底是什么直接看代碼// 一級(jí)緩存存放已經(jīng)完全創(chuàng)建好的單例Bean private final MapString, Object singletonObjects new ConcurrentHashMap(256); // 二級(jí)緩存存放提前暴露的早期單例Bean半成品 private final MapString, Object earlySingletonObjects new ConcurrentHashMap(16); // 三級(jí)緩存存放ObjectFactory用于生成早期引用 private final MapString, ObjectFactory? singletonFactories new HashMap(16);三級(jí)緩存的設(shè)計(jì)邏輯是這樣的一級(jí)緩存是最終狀態(tài)所有創(chuàng)建完的Bean都在這里。三級(jí)緩存存的是ObjectFactory工廠對(duì)象這個(gè)工廠可以在需要的時(shí)候創(chuàng)建出早期引用。之所以不直接存對(duì)象是為了在生成早期引用時(shí)還能有機(jī)會(huì)插入AOP代理。也就是說如果這個(gè)Bean最終需要被代理那么提前暴露的應(yīng)該是代理對(duì)象而不是原始對(duì)象。二級(jí)緩存是三級(jí)緩存的成品化保存處。ObjectFactory.getObject()執(zhí)行完之后得到早期引用把這個(gè)引用放入二級(jí)緩存同時(shí)移除三級(jí)緩存中的工廠對(duì)象。4.3 三級(jí)緩存解析的具體流程我盡可能用容易理解的方式描述一遍。UserService開始創(chuàng)建實(shí)例化完成之后Spring把它包裝成ObjectFactory放入三級(jí)緩存。然后進(jìn)入屬性填充階段發(fā)現(xiàn)依賴OrderService于是先嘗試從一級(jí)緩存獲取沒拿到再從二級(jí)緩存獲取也沒有最后從三級(jí)緩存獲取拿到的是ObjectFactory。執(zhí)行ObjectFactory.getObject()得到UserService的早期引用放入二級(jí)緩存同時(shí)移除三級(jí)緩存條目。這時(shí)創(chuàng)建OrderService時(shí)將早期引用注入進(jìn)去即可。OrderService創(chuàng)建完成后UserService繼續(xù)執(zhí)行屬性填充、初始化最終創(chuàng)建完成后放入一級(jí)緩存。此時(shí)二級(jí)緩存里的早期引用和一級(jí)緩存里的完整引用是同一個(gè)對(duì)象嗎不一定。如果UserService在postProcessAfterInitialization階段被替換成了代理對(duì)象那早期引用和最終引用就不是同一個(gè)對(duì)象了。這也是AOP和循環(huán)依賴疊加時(shí)會(huì)出現(xiàn)的經(jīng)典坑。4.4 一個(gè)經(jīng)典坑AOP代理對(duì)象的槍口對(duì)準(zhǔn)誰如果UserService沒有AOP增強(qiáng)那么提前暴露的早期引用和最終創(chuàng)建的Bean是同一個(gè)對(duì)象一切風(fēng)平浪靜。如果UserService需要AOP代理事情就變得微妙了。因?yàn)樘崆氨┞兜膶?duì)象是在AOP代理生成之前就創(chuàng)建的OrderService持有的UserService引用是原始對(duì)象。而容器最終放入一級(jí)緩存的UserService是代理對(duì)象。這會(huì)導(dǎo)致什么后果如果OrderService里調(diào)用userService.someMethod()走的是原始對(duì)象的方法事務(wù)、日志等AOP功能全部失效。但Spring其實(shí)已經(jīng)考慮過這個(gè)問題。它的處理方式是在getEarlyBeanReference()階段就通過SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference()方法提前生成代理對(duì)象保證提前暴露的引用就是代理對(duì)象。也就是說只要循環(huán)依賴調(diào)整順序正確AOP代理在提前暴露時(shí)就已經(jīng)完成了后面postProcessAfterInitialization階段會(huì)保持同一個(gè)代理實(shí)例不再重復(fù)創(chuàng)建。這就能解釋為什么有人會(huì)發(fā)現(xiàn)在某些循環(huán)依賴場景下Transactional代理的創(chuàng)建時(shí)機(jī)和其他場景不一樣。本質(zhì)上都是為了拿到同一個(gè)代理引用而做的特殊處理。4.5 哪些循環(huán)依賴Spring解決不了三級(jí)緩存是個(gè)復(fù)雜的補(bǔ)償機(jī)制但它不是萬能的。以下情況容器會(huì)直接拋BeanCurrentlyInCreationException構(gòu)造器注入的循環(huán)依賴。因?yàn)闃?gòu)造器注入要求在實(shí)例化之前就準(zhǔn)備好依賴這時(shí)候不可能提前暴露半成品畢竟連對(duì)象都還沒new出來。Async注解的Bean循環(huán)依賴。異步代理的創(chuàng)建時(shí)機(jī)比較特殊普遍不建議在Async相關(guān)的Bean之間互相依賴。設(shè)置了DependsOn強(qiáng)制依賴關(guān)系的Bean循環(huán)依賴。單例之外的其他作用域循環(huán)依賴比如prototype因?yàn)閜rototype作用域的Bean不緩存根本無從提前暴露。我個(gè)人的習(xí)慣是盡量避免循環(huán)依賴。它不是必須解決的deadlock更多時(shí)候是一種設(shè)計(jì)上的壞味道。循環(huán)依賴的Bean往往意味著職責(zé)邊界不清晰。與其依賴三級(jí)緩存的精巧機(jī)制不如把循環(huán)依賴的依賴關(guān)系抽出來放到第三方的組件里統(tǒng)一維護(hù)。5. Bean的作用域如何改寫B(tài)ean的生命周期劇本生命周期不是一套固定不變的劇本它受作用域影響很大。不同作用域下Bean的創(chuàng)建次數(shù)、緩存方式、銷毀時(shí)機(jī)都完全不同。5.1 singleton默認(rèn)的一次一生singleton作用域下Spring容器只會(huì)創(chuàng)建一個(gè)Bean實(shí)例。這個(gè)實(shí)例在一級(jí)緩存中存活直到容器關(guān)閉時(shí)統(tǒng)一銷毀。注意singleton不等于享元模式但思想接近。因?yàn)樗凰姓{(diào)用方共享所以如果你在單例Bean里定義了可變狀態(tài)字段并發(fā)訪問時(shí)就會(huì)有線程安全問題。我之前遇到過一個(gè)實(shí)際問題一個(gè)單例服務(wù)里維護(hù)了一個(gè)Map做本地緩存沒有做并發(fā)控制結(jié)果線上出現(xiàn)偶發(fā)數(shù)據(jù)錯(cuò)亂。排查半天發(fā)現(xiàn)是HashMap并發(fā)寫入導(dǎo)致的。解決方式要么用ConcurrentHashMap要么加鎖要么把緩存拆到專門的組件里。singleton作用域Bean的銷毀時(shí)機(jī)也比較晚它是容器關(guān)閉時(shí)批量處理的。如果單個(gè)Bean持有昂貴的資源比如數(shù)據(jù)庫連接池等待容器關(guān)閉時(shí)統(tǒng)一清理可能太晚尤其是應(yīng)用在運(yùn)行期間反復(fù)創(chuàng)建和銷毀容器的場景。不過這種情況比較少見。5.2 prototype每次getBean都是從頭走一遍prototype作用域下每次從容器獲取Bean都會(huì)創(chuàng)建一個(gè)新實(shí)例。也就是說完整生命周期中實(shí)例化→屬性填充→初始化會(huì)反復(fù)執(zhí)行。但注意Spring對(duì)prototype作用域的Bean有一個(gè)明顯的區(qū)別容器只負(fù)責(zé)創(chuàng)建和初始化不負(fù)責(zé)銷毀。這句話怎么理解Spring容器在關(guān)閉時(shí)只會(huì)對(duì)singleton作用域的Bean調(diào)用銷毀回調(diào)prototype的Bean則被放養(yǎng)因?yàn)槿萜鞑恢滥愕降壮钟辛硕嗌賯€(gè)它的實(shí)例也無從跟蹤清理。這帶來一個(gè)很實(shí)際的坑如果prototypeBean實(shí)現(xiàn)了DisposableBean或配置了destroy-method那你不能指望容器關(guān)閉時(shí)幫你釋放資源。你需要自己在使用完Bean之后手動(dòng)清理或者借助Scope(prototype) 自定義后置處理器的組合來管理。5.3 request、session、applicationWeb場景下的生命周期變體request、session、application這三個(gè)作用域是Web專屬的。它們的生命周期對(duì)應(yīng)了Web請(qǐng)求、會(huì)話和應(yīng)用啟動(dòng)。比如request作用域的Bean在一次HTTP請(qǐng)求內(nèi)有效請(qǐng)求結(jié)束就銷毀。session作用域類似在用戶會(huì)話內(nèi)有效。這幾個(gè)作用域在Spring MVC里用得不少比如把一個(gè)Bean聲明為request作用域讓它持有當(dāng)前用戶的請(qǐng)求信息避免手動(dòng)從RequestContextHolder里取。但要注意這些作用域在使用時(shí)要確保當(dāng)前線程里有對(duì)應(yīng)的Web上下文否則RequestContextHolder會(huì)拿到nullBean創(chuàng)建失敗。5.4 作用域選型和生命周期管理建議我的建議是默認(rèn)全部用singleton因?yàn)樗阅茏詈?、損耗最小、也最容易排查問題。確實(shí)需要不同狀態(tài)隔離的場景優(yōu)先考慮把狀態(tài)放到方法級(jí)或者使用ThreadLocal而不是直接改成prototype。prototype會(huì)帶來更高的創(chuàng)建開銷和更復(fù)雜的資源回收問題。只有當(dāng)你明確需要每次都獲得一個(gè)全新獨(dú)立實(shí)例且資源開銷可以承受時(shí)才選擇prototype。6. 實(shí)戰(zhàn)排查那些年我們一起踩過的Bean生命周期坑理論講再多不如實(shí)戰(zhàn)來得實(shí)在。這一節(jié)我整理幾個(gè)我之前實(shí)際遇到和排查過的經(jīng)典問題附帶完整的排查思路。因?yàn)槲冶旧聿冗^的坑也不少很多問題排查到最后回溯到根因時(shí)發(fā)現(xiàn)就是生命周期某一環(huán)出了問題。6.1 報(bào)錯(cuò)Error creating bean with name xxx: Invocation of init method failed這個(gè)報(bào)錯(cuò)應(yīng)該是Spring開發(fā)者最常見的報(bào)錯(cuò)之一了。字面意思是在調(diào)用Bean的初始化方法時(shí)拋出了異常。排查思路很簡單。先看堆棧確定是哪個(gè)Bean的哪個(gè)初始化方法報(bào)錯(cuò)如果是PostConstruct方法報(bào)錯(cuò)說明初始化邏輯失敗比如配置數(shù)據(jù)沒準(zhǔn)備好或者依賴的資源暫不可用。如果是afterPropertiesSet()報(bào)錯(cuò)通常是校驗(yàn)邏輯不滿足比如某個(gè)必填配置項(xiàng)為空。如果是init-method報(bào)錯(cuò)可能是第三方組件初始化失敗。這類問題九成是初始化邏輯本身的問題建議在初始化方法里做好防御式校驗(yàn)把關(guān)鍵參數(shù)打印出來避免異常信息過于模糊。另外不要在PostConstruct里做長時(shí)間阻塞操作比如遠(yuǎn)程調(diào)用因?yàn)锽ean初始化是在容器啟動(dòng)階段完成的一個(gè)Bean卡住整個(gè)應(yīng)用就起不來。我之前見過有人在PostConstruct里調(diào)外部接口做數(shù)據(jù)同步結(jié)果外部接口響應(yīng)超時(shí)整個(gè)服務(wù)啟動(dòng)被拖了十幾分鐘。后來改成了異步監(jiān)聽ApplicationReadyEvent再做這些操作啟動(dòng)速度快了很多。6.2 循環(huán)依賴報(bào)錯(cuò)BeanCurrentlyInCreationException這個(gè)報(bào)錯(cuò)出現(xiàn)的時(shí)候完整堆棧里通常會(huì)附帶類似Requested bean is currently in creation: Is there an unresolvable circular reference?的信息。排查方式也不復(fù)雜。第一步根據(jù)堆棧定位哪些Bean存在相互引用。第二步看它們是通過構(gòu)造器注入還是setter/字段注入。如果是構(gòu)造器注入那結(jié)論基本明確Spring解決不了這種場景需要手動(dòng)重構(gòu)。第三步如果既不是構(gòu)造器注入代碼里也沒有明顯的依賴環(huán)那多半是間接循環(huán)依賴比如A依賴BB依賴CC又依賴A中間繞了好幾層需要把整條鏈看全。我見過一個(gè)比較隱蔽的場景A依賴BB依賴CC依賴A但A和C之間的依賴是通過Lazy注解標(biāo)注的。Lazy在注入時(shí)生成一個(gè)代理對(duì)象調(diào)用時(shí)才真正解析依賴所以Spring可以借此打破循環(huán)。這種解法雖然有效但是會(huì)讓排查鏈路變得更復(fù)雜不建議大量使用。更推薦的做法是拆掉循環(huán)依賴本身。6.3 后臺(tái)日志頻繁打印BeanNameAware/BeanFactoryAware not called或者Aware注入的字段為null這個(gè)問題遇到過的人應(yīng)該不少。當(dāng)你實(shí)現(xiàn)了一個(gè)Aware接口結(jié)果字段還是null第一反應(yīng)不要懷疑Spring壞了先檢查這個(gè)Bean到底是不是容器管理的。比如你通過new UserService()這樣的方式創(chuàng)建了Bean那它肯定不在容器管理范圍內(nèi)Aware回調(diào)和依賴注入都不會(huì)生效。還有一種情況是Bean雖然聲明了但被Configuration里的某個(gè)Bean方法手動(dòng)覆蓋了容器里最終存的不是你定義的那個(gè)實(shí)例。排查時(shí)可以打一下啟動(dòng)日志確定注冊(cè)進(jìn)容器的到底是誰。6.4 FeignClient、RedisTemplate這類框架組件的生命周期特殊性如果你用Spring Cloud應(yīng)該知道FeignClient是通過feign的構(gòu)建器在運(yùn)行時(shí)創(chuàng)建的。它的生命周期其實(shí)不完全等同于普通Spring BeanFeignClient的代理由FeignClientFactoryBean生成創(chuàng)建的時(shí)機(jī)是在Autowired注入發(fā)生的時(shí)候而不是應(yīng)用啟動(dòng)時(shí)。所以如果你在PostConstruct里提前使用FeignClient可能會(huì)觸發(fā)它的懶加載創(chuàng)建邏輯有時(shí)候會(huì)出現(xiàn)意想不到的初始化順序問題。RedisTemplate也有類似的情況它本身是個(gè)普通Bean但它在初始化時(shí)會(huì)通過afterPropertiesSet()創(chuàng)建內(nèi)部的一些序列化器。如果某個(gè)Bean在RedisTemplate還沒完成初始化時(shí)就引用了它就可能取到不完整的RedisTemplate。所以依賴順序還是那句話讓Spring按照依賴圖管理順序不要在一個(gè)Bean的初始化里依賴另一個(gè)正在初始化中的Bean。6.5 快速定位Bean生命周期問題的排查清單我把排查思路整理成一張速查表排障時(shí)對(duì)著看能省不少時(shí)間癥狀可能原因排查方向初始化報(bào)異常初始化方法內(nèi)部邏輯出錯(cuò)查看堆棧定位到具體方法檢查配置和依賴屬性注入為nullBean不是容器管理或注入時(shí)機(jī)不對(duì)確認(rèn)Bean是否由Spring創(chuàng)建檢查字段是否被static修飾循環(huán)依賴創(chuàng)建失敗構(gòu)造器注入循環(huán)或prototype循環(huán)定位依賴鏈重構(gòu)依賴關(guān)系靜態(tài)工具類無法注入靜態(tài)字段不支持自動(dòng)注入通過InitializingBean或PostConstruct賦值事務(wù)/異步不生效this調(diào)用內(nèi)部方法代理未介入從容器獲取代理對(duì)象或拆類prototype Bean資源未釋放容器不管理prototype銷毀手動(dòng)清理或使用自定義銷毀邏輯這張表是我日常排障時(shí)常用到的基本能覆蓋絕大多數(shù)生命周期相關(guān)的坑。6.6 安全相關(guān)的一個(gè)小提醒關(guān)于Spring框架本身的安全性也是個(gè)老話題了。熱搜詞里出現(xiàn)了類似Spring Framework目錄遍歷漏洞的條目雖然說的是CVE-2024-38819這類已披露的舊漏洞但我每次看到還是要啰嗦一句框架版本一定要及時(shí)升級(jí)。就Spring框架而言版本滯后是很多已知漏洞能夠被利用的直接原因。Bean生命周期的討論再深入也頂不住一個(gè)不打補(bǔ)丁的底層框架被別人攻破。生命周期相關(guān)代碼里經(jīng)常會(huì)打開文件資源、網(wǎng)絡(luò)連接這些地方尤其要小心路徑穿越和資源泄漏問題別把用戶輸入直接拼接到文件路徑里。7. 生命周期源碼閱讀建議從哪里入手最快我不是很喜歡一上來就扔幾百行源碼但對(duì)生命周期來說如果你能從源碼層面驗(yàn)證一遍自己理解的流程會(huì)記得非常牢。給你一條我自己覺得效率最高的閱讀路徑。7.1 從AbstractApplicationContext.refresh()切入Spring容器的啟動(dòng)核心是refresh()方法。它是了解全球流程的總?cè)肟谏芷谙嚓P(guān)的掃描、注冊(cè)、創(chuàng)建都從這里展開。你不需要逐行看完重點(diǎn)是看finishBeanFactoryInitialization()這一行它負(fù)責(zé)實(shí)例化所有非懶加載的單例Bean。點(diǎn)進(jìn)去你會(huì)看到preInstantiateSingletons()再往深層走就是getBean()。7.2 核心方法鏈路追蹤想真正看清生命周期的那幾步核心鏈路大概是這樣AbstractBeanFactory.doGetBean() → getSingleton(beanName, () - createBean(...)) → AbstractAutowireCapableBeanFactory.createBean() → doCreateBean() → createBeanInstance() // 實(shí)例化 → populateBean() // 屬性填充 → initializeBean() // 初始化 → invokeAwareMethods() // Aware回調(diào) → applyBeanPostProcessorsBeforeInitialization() → invokeInitMethods() // 初始化方法 → applyBeanPostProcessorsAfterInitialization()建議不要順著源碼死盯而是斷點(diǎn)打在關(guān)鍵方法上運(yùn)行一個(gè)極簡的測(cè)試工程看每個(gè)階段的執(zhí)行順序和參數(shù)變化。我看到很多人說源碼枯燥其實(shí)是方法不對(duì)。源碼這東西最好是帶著問題去讀比如你就帶著為什么字段注入為null這個(gè)問題去讀populateBean()會(huì)理解得特別快。7.3 動(dòng)手驗(yàn)證生命周期最直觀的方式實(shí)踐是最好的理解方式。你可以寫一個(gè)簡單的驗(yàn)證工程定義一個(gè)UserService讓它實(shí)現(xiàn)BeanNameAware、BeanFactoryAware、InitializingBean、DisposableBean同時(shí)在Bean配置上指定initMethod和destroyMethod再注冊(cè)一個(gè)BeanPostProcessor在前后置處理里打印日志。啟動(dòng)容器時(shí)觀察日志順序關(guān)閉容器時(shí)再觀察銷毀順序。這樣跑一遍實(shí)際看到的東西遠(yuǎn)比背十遍八股文有用。而且你還會(huì)發(fā)現(xiàn)很多文檔里沒有細(xì)講的細(xì)節(jié)比如PostConstruct和InitializingBean到底誰先執(zhí)行配置了destroyMethod和DisposableBean.destroy()時(shí)誰會(huì)先跑。8. 關(guān)于Bean生命周期我最后想分享的一些經(jīng)驗(yàn)聊了這么多最后分享幾條我自己在實(shí)戰(zhàn)中的體會(huì)也是我教團(tuán)隊(duì)新人時(shí)反復(fù)強(qiáng)調(diào)的重點(diǎn)。第一處理生命周期相關(guān)問題時(shí)先判斷這個(gè)對(duì)象到底是不是Spring容器管理的Bean。很多靈異問題比如注入為null、Aware不生效、事務(wù)不生效根因都是這里。你把這個(gè)前提確認(rèn)了至少一半的坑可以避開。第二BeanPostProcessor是Spring最強(qiáng)大的擴(kuò)展點(diǎn)之一但它也是雙刃劍。因?yàn)樗鼘?duì)容器內(nèi)所有Bean生效一旦邏輯處理不當(dāng)性能損耗是全局的。寫這類組件時(shí)一定要做精確的類型匹配并且保證處理邏輯足夠輕量不要在里面做重IO操作。第三初始化階段不是萬能收容所。很多操作其實(shí)不適合在PostConstruct或afterPropertiesSet()里做。比如依賴外部系統(tǒng)的數(shù)據(jù)同步、耗時(shí)較長的預(yù)熱邏輯這些放到ApplicationRunner和ApplicationReadyEvent階段執(zhí)行更合理。前者是Bean準(zhǔn)備階段后者是應(yīng)用啟動(dòng)完成后區(qū)分清楚能讓啟動(dòng)速度更快也更不容易被外部依賴拖垮。第四對(duì)PostConstruct和PreDestroy保持偏愛。它們是JDK標(biāo)準(zhǔn)注解不依賴Spring特有接口代碼可遷移性更好。如果你寫的模塊未來有可能脫離Spring容器運(yùn)行用標(biāo)準(zhǔn)注解會(huì)比用Spring原生的InitializingBean更安全。第五循環(huán)依賴的頂層設(shè)計(jì)方案一定要以消除為目標(biāo)。三級(jí)緩存的機(jī)制再精妙也只是妥協(xié)方案。它增加了理解和排查的復(fù)雜度也帶來了一些和AOP代理相關(guān)的邊界問題。能通過拆分對(duì)象、引入中間層來消除循環(huán)依賴的話永遠(yuǎn)比依賴框架機(jī)制去兜底更可靠。關(guān)于Spring Bean生命周期能分享的暫時(shí)就是這些。如果你們?cè)趯?shí)際項(xiàng)目中還遇到過什么和生命周期相關(guān)的詭異問題或者對(duì)哪個(gè)階段有不同理解歡迎一起討論。這類問題往往越聊越清楚很多隱藏的知識(shí)點(diǎn)也都是在排查中慢慢浮現(xiàn)出來的。