“面試官Spring Bean 生命周期詳解”這道題大概是Spring面試中出現(xiàn)頻率最高的前五名。我在幾次技術招聘里試過回答基本分成三類一類是背了流程但順序說反一類能說出實例化、屬性填充、初始化、銷毀但說不清Aware回調、BeanPostProcessor、InitializingBean這些擴展點到底卡在哪一步第三類能把這套東西完整講下來但追到循環(huán)依賴和三級緩存就明顯發(fā)虛。這篇文章就是把這道題從“能答”拆到“能講漂亮”。我會把Bean生命周期的完整節(jié)點、每類擴展點的設計意圖、源碼里的關鍵路徑還有面試官最可能順藤摸瓜追問的三級緩存原理全部串起來。適合正在準備Spring面試的Java開發(fā)也適合想真正理解IoC容器工作方式的后端工程師。你完全可以照這個框架去準備答完這道題面試官基本不會再拿“你背過八股”來打發(fā)你。1. 先把 Bean 生命周期的全流程跑一遍1.1 從 BeanDefinition 到可用實例到底經歷了什么很多人一上來就背“實例化、屬性填充、初始化、銷毀”但漏了最前面的一步Bean進入容器管理從BeanDefinition開始。Spring容器啟動時先解析XML、注解、JavaConfig等配置信息把它們統(tǒng)一轉成BeanDefinition注冊到BeanFactory的注冊表里。這一步可理解成“先造好圖紙不急著造產品”。BeanDefinition里面記錄著類名、作用域、是否懶加載、初始化方法名、銷毀方法名、依賴關系等全部元數(shù)據(jù)。之后所有Bean的創(chuàng)建都是拿著這份圖紙去做的。然后才輪到單個Bean的創(chuàng)建。在默認的ApplicationContext場景下所有非懶加載的單例Bean會在容器啟動階段被批量實例化也就是refresh()過程中的finishBeanFactoryInitialization這一步。原型Bean則不著急等每次getBean時才創(chuàng)建。單個Bean從創(chuàng)建到銷毀核心流程我習慣分成十個節(jié)點實例化createBeanInstance通過構造器或工廠方法創(chuàng)建對象此時對象剛有內存屬性全是默認值。合并BeanDefinition并處理注解元數(shù)據(jù)applyMergedBeanDefinitionPostProcessors解析Autowired、Resource、PostConstruct等注解的元數(shù)據(jù)。屬性填充populateBean通過AutowiredAnnotationBeanPostProcessor等后置處理器完成依賴注入把Autowired字段、構造器參數(shù)、Value配置等賦值進去。提前曝光earlySingletonExposure如果是單例且允許循環(huán)引用把ObjectFactory放入三級緩存。Aware回調BeanNameAware、BeanClassLoaderAware、BeanFactoryAware由容器直接調用ApplicationContextAware通過后置處理器回調。BeanPostProcessor前置處理postProcessBeforeInitialization被逐個調用。自定義初始化實現(xiàn)了InitializingBean則調用afterPropertiesSet配置了init-method或Bean(initMethod)則調用對應方法。BeanPostProcessor后置處理postProcessAfterInitialization被逐個調用AOP代理就是在這一步通過AbstractAutoProxyCreator生成的。使用Bean。容器關閉時銷毀PreDestroy、DisposableBean.destroy、destroy-method依次執(zhí)行。注意區(qū)分“實例化”和“初始化”。實例化只是new了一個對象屬性都還是null真正說一個Bean能干活了要等初始化和屬性填充全部完成。這個區(qū)分面試時主動說出來就已經比一半候選人強了。1.2 一張表看懂各階段的觸發(fā)時機與核心機制把上面對應的機制和常見實現(xiàn)整理成一張表方便記憶階段觸發(fā)時機核心機制常見實現(xiàn)BeanDefinition注冊容器啟動階段配置解析Configuration、ComponentScan實例化getBean或啟動預實例化構造器/工廠方法new、Scope(prototype)時按需創(chuàng)建屬性填充實例化之后、初始化之前BeanPostProcessorAutowired、Resource、Value提前曝光單例創(chuàng)建過程中三級緩存循環(huán)依賴場景用到Aware回調屬性填充后、初始化前后容器回調BeanNameAware、ApplicationContextAware初始化屬性填充完成后后置處理器自定義方法PostConstruct、afterPropertiesSet、init-methodAOP代理初始化后BeanPostProcessor動態(tài)代理的子類化包裝使用初始化完成業(yè)務調用—銷毀容器關閉回調PreDestroy、DisposableBean、destroy-method這張表最大的價值是讓你看到Spring的整個生命周期不是一條“順序調用”的直線而是圍繞著BeanPostProcessor和容器回調把多個機制拼起來的。面試時能畫出這張表的邏輯就說明你不是死記硬背。1.3 BeanFactory 與 ApplicationContext 的生命周期差異很多初學者不知道上面這套完整流程只有在ApplicationContext包括Spring Boot里的內置容器里才會全量觸發(fā)。如果你用的是最底層的BeanFactory生命周期會縮水不少。BeanFactory只是最基礎的IoC容器默認懶加載Bean默認只注冊少數(shù)內置處理器很多擴展機制需要手動注冊。ApplicationContext在BeanFactory之上做了大量增強啟動時預實例化單例Bean自動注冊AutowiredAnnotationBeanPostProcessor、CommonAnnotationBeanPostProcessor、ApplicationContextAwareProcessor等一堆內置后置處理器還會自動執(zhí)行BeanFactoryPostProcessor。這個差異你要能一句話說出來BeanFactory提供的是最小可用的容器能力ApplicationContext提供了企業(yè)級容器的完整生命周期管理。面試里追問“你用的BeanFactory還是ApplicationContext”時能講清這個區(qū)別會很加分。2. 擴展點為什么設置這么多拆開看設計意圖2.1 兩類 Processor 的角色差異Spring生命周期里最容易搞混的是BeanFactoryPostProcessor和BeanPostProcessor。名字像職責完全不同。BeanFactoryPostProcessor作用于BeanDefinition階段在所有Bean實例化之前執(zhí)行你可以修改BeanDefinition本身的屬性、作用域、甚至替換類名。最典型的場景就是修改配置類中被硬編碼的參數(shù)。舉例來說我曾在不停機的環(huán)境下用自定義BeanFactoryPostProcessor把某個第三方依賴Bean的作用域從singleton改成prototype效果立竿見影。BeanPostProcessor則作用于Bean實例之后、初始化前后它改的是對象本身。Autowired注解的解析、AOP代理的生成、PostConstruct方法的調用全部是通過各種BeanPostProcessor實現(xiàn)的。注意BeanFactoryPostProcessor和BeanPostProcessor的執(zhí)行時機和對象模型完全不同一個是改“圖紙”一個是改“產品”。面試官很喜歡用這道題來區(qū)分你是真懂還是背書這個區(qū)別自己體會一下。2.2 Aware 一族讓 Bean 感知容器的時機設計Aware接口在Spring里是一類標記接口實現(xiàn)它的Bean可以從容器中獲取資源。比如BeanNameAware能拿到當前Bean在容器中的名字ApplicationContextAware能拿到ApplicationContext對象。它們的出現(xiàn)是為了解決一個問題Bean明明被容器管理卻不知道容器在哪、自己叫什么。為什么不直接把ApplicationContext注入所有Bean因為會強耦合容器Bean無法脫離Spring容器使用還會增加內存占用。Aware的設計是“按需索取”你實現(xiàn)了哪個接口容器才回調哪個方法。這跟Autowired自動注入風格不一樣更像是一種顯式表達“我需要什么”的聲明。需要注意Aware回調的時機也分兩撥。BeanNameAware、BeanClassLoaderAware、BeanFactoryAware是在initializeBean方法里直接調用比較早ApplicationContextAware則是通過ApplicationContextAwareProcessor這個BeanPostProcessor在postProcessBeforeInitialization階段觸發(fā)稍微靠后一點。在實際業(yè)務代碼中我們很少自己實現(xiàn)ApplicationContextAware因為Spring已經封裝了ApplicationContextHolder之類的工具但作為面試知識點你得明白它的觸發(fā)原理。2.3 初始化三件套的優(yōu)先級PostConstruct、afterPropertiesSet、init-method同一個Bean身上可以同時用三種方式定義初始化邏輯PostConstruct注解、實現(xiàn)InitializingBean接口、配置init-method屬性。它們的執(zhí)行順序基本固定PostConstruct先執(zhí)行然后afterPropertiesSet最后init-method。原因也很直接PostConstruct不是Spring自己的注解而是JSR-250標準注解Spring通過CommonAnnotationBeanPostProcessor把它掛在postProcessBeforeInitialization階段觸發(fā)所以在標準初始化方法之前天然先執(zhí)行。InitializingBean的afterPropertiesSet在Spring源碼里直接調用init-method是最后定義的兜底方案因此排在最后。如果配置類里有這樣一段代碼可以眼見為實Component public class InitOrderBean implements InitializingBean { PostConstruct public void postConstruct() { System.out.println(1. PostConstruct); } Override public void afterPropertiesSet() { System.out.println(2. InitializingBean.afterPropertiesSet); } BeanInitMethod public void customInit() { System.out.println(3. init-method); } }運行后輸出順序就是1、2、3。銷毀階段順序也類似PreDestroy先執(zhí)行接著DisposableBean.destroy最后destroy-method。這個優(yōu)先級問題面試出現(xiàn)的頻率很高強烈建議你親手寫一個Bean跑一遍。真跑一次比背十次都牢。3. 源碼脈絡從 refresh 到 initializeBean3.1 refresh() 里 Bean 是如何被批量創(chuàng)建的要深入理解生命周期繞不開AbstractApplicationContext.refresh()。這是Spring容器的啟動入口我們平時說的“容器啟動”其實就是執(zhí)行了refresh()。這個方法里面有幾個關鍵步驟和Bean生命周期直接掛鉤invokeBeanFactoryPostProcessors(beanFactory)執(zhí)行BeanFactoryPostProcessor包括處理Configuration、ComponentScan的ConfigurationClassPostProcessor就是在這步工作的。它是生命周期最靠前的擴展點。registerBeanPostProcessors(beanFactory)注冊各種BeanPostProcessor。注意這里只是注冊不執(zhí)行執(zhí)行要等Bean實例化之后。finishBeanFactoryInitialization(beanFactory)實例化所有非懶加載單例Bean。這一步是單個Bean生命周期的真正起點。Override public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { // 準備刷新設置啟動時間、活躍標志等 prepareRefresh(); // 創(chuàng)建或獲取 BeanFactory ConfigurableListableBeanFactory beanFactory obtainFreshBeanFactory(); // 準備BeanFactory設置類加載器、表達式解析器等 prepareBeanFactory(beanFactory); // ... 模板方法子類可擴展 // 執(zhí)行BeanFactoryPostProcessor invokeBeanFactoryPostProcessors(beanFactory); // 注冊BeanPostProcessor registerBeanPostProcessors(beanFactory); // 初始化消息源、事件廣播器等 // ... // 實例化所有非懶加載單例Bean finishBeanFactoryInitialization(beanFactory); // 完成刷新發(fā)布事件 finishRefresh(); } }面試時不要求背源碼能說出refresh()里“先處理BeanFactoryPostProcessor、再注冊BeanPostProcessor、最后實例化所有單例Bean”這個順序就已經把生命周期前半場的上下文說清楚了。3.2 doCreateBean從實例化到提前曝光的完整步驟單個Bean的創(chuàng)建核心邏輯在AbstractAutowireCapableBeanFactory.doCreateBean方法里。這個方法每一步都有對應的外部擴展點可以說是Spring生命周期的“五臟六腑”。protected Object doCreateBean(String beanName, RootBeanDefinition mbd, Object[] args) { BeanWrapper instanceWrapper null; if (mbd.isSingleton()) { instanceWrapper this.factoryBeanInstanceCache.remove(beanName); } if (instanceWrapper null) { // 1. 實例化Bean instanceWrapper createBeanInstance(beanName, mbd, args); } Object bean instanceWrapper.getWrappedInstance(); // 2. 提前曝光單例且允許循環(huán)引用時把ObjectFactory放入三級緩存 boolean earlySingletonExposure (mbd.isSingleton() this.allowCircularReferences isSingletonCurrentlyInCreation(beanName)); if (earlySingletonExposure) { addSingletonFactory(beanName, new ObjectFactoryObject() { Override public Object getObject() throws BeansException { return getEarlyBeanReference(beanName, mbd, bean); } }); } Object exposedObject bean; try { // 3. 屬性填充 populateBean(beanName, mbd, instanceWrapper); // 4. 初始化 exposedObject initializeBean(beanName, exposedObject, mbd); } catch (Throwable ex) { // ... } return exposedObject; }注意第2步的提前曝光這是循環(huán)依賴能成立的基礎但也是很多人在面試中講不出所以然的點。它并沒有把Bean本身放到緩存而是放了一個ObjectFactory真正被別人引用時才調用getObject()生成“早期引用”。這個設計在后面講三級緩存時會展開。3.3 initializeBean 中的四步調用鏈initializeBean是單個Bean生命周期的“核心調度室”它把Aware回調、前置處理、初始化方法、后置處理串在一起protected Object initializeBean(String beanName, Object bean, RootBeanDefinition mbd) { // 1. 直接回調BeanNameAware、BeanClassLoaderAware、BeanFactoryAware invokeAwareMethods(beanName, bean); // 2. BeanPostProcessor前置處理PostConstruct等方法在這里觸發(fā) Object wrappedBean bean; if (mbd null || !mbd.isSynthetic()) { wrappedBean applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName); } // 3. 初始化方法InitializingBean.afterPropertiesSet init-method try { invokeInitMethods(beanName, wrappedBean, mbd); } catch (Throwable ex) { throw new BeanCreationException(...); } // 4. BeanPostProcessor后置處理AOP代理在這里生成 if (mbd null || !mbd.isSynthetic()) { wrappedBean applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName); } return wrappedBean; }這一步最關鍵的是理解調用順序前置處理在初始化方法之前后置處理在初始化方法之后。AOP代理是在第4步生成的所以如果你在before階段拿到的還是原始對象在after階段拿到的才可能是代理對象。很多自定義BeanPostProcessor的代碼里就會刻意利用這個時機差。4. 生命周期里最大的暗礁循環(huán)依賴與三級緩存4.1 循環(huán)依賴到底卡在哪個環(huán)節(jié)假如有兩個BeanA依賴BB依賴AA和B互相引用對方。Spring能創(chuàng)建出A和B嗎答案取決于注入方式。如果是構造器注入Spring會直接拋異常無法解決如果是setter注入或字段注入Autowired就是在屬性填充階段工作Spring就能通過三級緩存把循環(huán)依賴破掉。為什么構造器注入不行因為A的構造器執(zhí)行時需要B已經存在可此時B還沒創(chuàng)建Spring根本拿不到B對象而A本身也還沒完成實例化沒法提前暴露任何東西。形象點說這就好比“你還沒出生就要先見到一個需要你出生之后才能見到的人”。setter和字段注入就沒這個問題它們發(fā)生在populateBean階段此時A已經實例化完成并且已經把ObjectFactory放進了三級緩存。B在創(chuàng)建過程中需要A時就能通過三級緩存拿回A的早期引用不管A還沒填充完屬性先把引用用起來。4.2 三級緩存解決的是什么問題三級緩存存在于DefaultSingletonBeanRegistry里實際上就是三個Map// 一級緩存最終成品完整的單例Bean MapString, Object singletonObjects new ConcurrentHashMap(256); // 二級緩存提前曝光的早期引用半成品Bean MapString, Object earlySingletonObjects new ConcurrentHashMap(16); // 三級緩存可以工廠式生成早期引用的ObjectFactory MapString, ObjectFactory? singletonFactories new HashMap(16);用A和B互相依賴的場景推演一遍創(chuàng)建AgetSingleton(A)未命中創(chuàng)建A實例此時A屬性還是空的。調用addSingletonFactory把A的ObjectFactory存入三級緩存。populateBean(A)發(fā)現(xiàn)A依賴B于是getSingleton(B)創(chuàng)建B實例B也執(zhí)行addSingletonFactory把B的ObjectFactory存入三級緩存。populateBean(B)發(fā)現(xiàn)B依賴A于是getSingleton(A, true)此時allowEarlyReferencetrue一級緩存沒有A二級緩存沒有A就從三級緩存找到A的ObjectFactory調用getObject()得到早期引用A把早期引用A放入二級緩存并從三級緩存刪除然后返回給BB把A注入成功。B完成屬性填充和初始化把完整B放入一級緩存。A繼續(xù)populateBean拿到B完成填充和初始化把完整A放入一級緩存。這個過程中最關鍵的是第6步從三級緩存返回的“早期引用”是一個還沒完成初始化的半成品。B拿到這個半成品去填充屬性沒問題因為B只是持有引用并不要求A在那一刻已經完全可用。對應源碼里getSingleton的核心邏輯protected Object getSingleton(String beanName, boolean allowEarlyReference) { Object singletonObject this.singletonObjects.get(beanName); if (singletonObject null isSingletonCurrentlyInCreation(beanName)) { singletonObject this.earlySingletonObjects.get(beanName); if (singletonObject null allowEarlyReference) { synchronized (this.singletonObjects) { singletonObject this.singletonObjects.get(beanName); if (singletonObject null) { singletonObject this.earlySingletonObjects.get(beanName); if (singletonObject null) { ObjectFactory? singletonFactory this.singletonFactories.get(beanName); if (singletonFactory ! null) { singletonObject singletonFactory.getObject(); this.earlySingletonObjects.put(beanName, singletonObject); this.singletonFactories.remove(beanName); } } } } } } return singletonObject; }注意這個方法里加了一個synchronized鎖因為三級緩存里的singletonFactories不是線程安全的HashMap必須在并發(fā)環(huán)境下鎖住操作。細節(jié)雖小但面試時能說出來會顯得你真的讀過源碼。4.3 為什么是三級緩存而不是二級或一級這個問題幾乎每逢追問必考。我的回答思路分三層。第一層一級緩存不可能一級緩存存放的必須是完整可用的單例Bean。早期引用是一個屬性還沒填充完的半成品放到一級緩存等于把一個殘次品對外開放別的地方拿到的就是錯誤數(shù)據(jù)。第二層二級緩存為什么不夠如果只有二級緩存意味著在無循環(huán)依賴的普通場景里所有單例Bean也必須提前放進二級緩存。那Spring就不得不對每個Bean在提前曝光時都嘗試做AOP代理。這個行為會改變AOP的默認觸發(fā)時機很可能造成代理重復、代理失效、無辜對象被包裝等一堆問題。第三層三級緩存的意義在于“延遲決策”三級緩存里存的不是Bean而是ObjectFactory。Spring并不知道一個Bean到底需不需要AOP代理它知道這個決策要等到真正有人引用它時才能做。只有在發(fā)生循環(huán)依賴、提前引用被觸發(fā)的那一刻才調用getEarlyBeanReference去生成可能被代理過的早期引用。這個設計既解決了循環(huán)依賴又保證了AOP代理的正確性。用一句話概括三級緩存是為了同時滿足“解決循環(huán)依賴”和“保持AOP代理時機不被打亂”兩個要求Spring在注冊表設計上給出的最優(yōu)雅方案。這里還要提一個關鍵點如果Bean方法上配置了事務切面、自定義切面等AOP配置在提前曝光階段就會通過AbstractAutoProxyCreator生成代理。所以你在開發(fā)中看到循環(huán)依賴的Bean拿到的很可能是一個“長得像A”的代理對象而不是A自己的實例。5. 面試怎么把這道題講漂亮應答框架與追問庫5.1 3到5分鐘的應答框架如果你面試時碰到這道題我建議按“總分總”的方式組織回答控制時長在3到5分鐘。先給一句話總覽Bean生命周期可以分成實例化、屬性填充、初始化、使用、銷毀五個大階段Spring通過BeanPostProcessor和各類回調接口把擴展點嵌入其中。然后快速過節(jié)點不要卡頓。從createBeanInstance開始一句“屬性填充階段通過populateBean完成依賴注入”一句“初始化階段先回調Aware再走Before后置處理器然后調InitializingBean最后走After后置處理器”再補一句“AOP代理就是在After后置處理器里通過AbstractAutoProxyCreator生成的”這時候面試官眼神已經不一樣了。接著主動拋出亮點如果讓我補充一個實踐點我會說Spring為單例Bean提供了三級緩存用來解決循環(huán)依賴核心是ObjectFactory的延遲決策。最后做個簡短收束整個設計本質上就是模板方法模式每種擴展點都對應一個特定階段給業(yè)務留下充分的可定制空間。5.2 高頻追問與參考思路追問參考思路BeanPostProcessor和BeanFactoryPostProcessor區(qū)別前者改實例后者改BeanDefinition前者執(zhí)行在實例化之后后者執(zhí)行在實例化之前。三級緩存為什么用ObjectFactory延遲決策代理的產生時機保證無循環(huán)依賴時AOP照常有循環(huán)依賴時提前生成代理。PostConstruct、afterPropertiesSet、init-method執(zhí)行順序依次執(zhí)行因為PostConstruct掛在postProcessBeforeInitialization上。prototype的Bean會走完整銷毀回調嗎不會Spring不管理prototype的銷毀回調除非自定義DestructionAwareBeanPostProcessor。構造器注入的循環(huán)依賴為什么不行實例化前需要參數(shù)此時還沒有提前曝光對象三級緩存幫不上忙。什么時候會觸發(fā)Bean提前曝光單例、允許循環(huán)引用、isSingletonCurrentlyInCreation為true時。Autowired在哪個階段生效屬性填充階段通過AutowiredAnnotationBeanPostProcessor。銷毀回調順序PreDestroy - DisposableBean.destroy - destroy-method。每個追問的回答后面如果能跟上“為什么”或“源碼里怎么體現(xiàn)”這個印象分就拿到手了。5.3 容易說錯的幾個細節(jié)我面試時聽到過很多“差一點但就是不對”的回答集中在這幾個細節(jié)上。第一把PostConstruct說成在afterPropertiesSet之后執(zhí)行。前面已經說過它是通過postProcessBeforeInitialization觸發(fā)的所以最先執(zhí)行。第二說Bean創(chuàng)建完就立即銷毀。銷毀只有在ApplicationContext關閉close方法時才會觸發(fā)正常運行時Bean常駐容器常駐內存不存在創(chuàng)建完就銷毀。第三把BeanPostProcessor的兩個方法都放在初始化之后。postProcessBeforeInitialization在初始化之前postProcessAfterInitialization在初始化之后這個先后關系涉及AOP和Aware回調說錯了很致命。第四以為二級緩存只放AOP代理對象。實際上二級緩存放的是所有被提前引用的半成品Bean只不過如果Bean需要代理這個引用是代理對象。第五說“BeanFactory和ApplicationContext生命周期完全一樣”。這個差異前面章節(jié)講了健忘的話現(xiàn)在翻回去再看一遍。6. 實戰(zhàn)排查生命周期相關的坑與埋點技巧6.1 PostConstruct 不執(zhí)行先查這四件事實際開發(fā)中很多人遇到的最詭異問題就是“為什么我的PostConstruct方法沒跑”。排查順序建議從外到內。第一依賴包是否齊全。Spring 5.3.x之前用的是javax.annotationSpring 6.x之后遷移到jakarta.annotation如果包沒引或者引錯注解根本不會被識別。第二使用XML配置時是否注冊了CommonAnnotationBeanPostProcessor。用注解驅動開發(fā)時Spring會自動注冊但是老項目里手工配置BeanFactory時這步可能被漏掉。第三方法簽名是不是寫錯了。PostConstruct要求方法無參數(shù)、非靜態(tài)、無返回值如果方法帶參數(shù)或者返回了非void在CDI規(guī)范下該方法是無效的。第四Bean是否真的被容器管理。如果通過new的方式創(chuàng)建對象那Bean生命周期自然不生效注解也不會有任何反應。這類問題在工具類中特別常見。6.2 初始化順序錯亂與“不可預測”的列表Spring對多個Bean之間的初始化順序默認不保證。如果業(yè)務邏輯依賴某個Bean先初始化必須顯式聲明依賴關系。常見的控制方式有四種DependsOn注解指定被依賴Bean先初始化Order注解控制同一類型組件的加載順序實現(xiàn)PriorityOrdered接口在BeanFactoryPostProcessor中直接排序。最推薦的是DependsOn它表達的是“依賴關系”而不僅是“先后順序”語義更清晰。我曾在一個微服務項目里遇到過啟動時初始化順序錯亂導致監(jiān)聽器重復注冊的問題。排查后確認是多個Runner沒有控制先后順序后來統(tǒng)一改成DependsOn加Order雙管齊下問題解決。順帶提一句不要在初始化方法里做長耗時或需要外部依賴的操作這會讓Spring Boot的啟動時間直線上升而且很容易掩蓋真實依賴順序的問題。6.3 讓生命周期為我所用埋點觀測的真實案例如果你想知道每個Bean初始化耗時多少完全不用上復雜的監(jiān)控工具寫一個BeanPostProcessor就能搞定。Component public class LifecycleLogBeanPostProcessor implements BeanPostProcessor { private final MapString, Long startTimeMap new ConcurrentHashMap(); Override public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { startTimeMap.put(beanName, System.currentTimeMillis()); return bean; } Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { Long start startTimeMap.get(beanName); if (start ! null) { long cost System.currentTimeMillis() - start; System.out.println(Bean [ beanName ] 初始化耗時: cost ms); startTimeMap.remove(beanName); } return bean; } }這段代碼會把所有Bean的初始化耗時輸出到控制臺。排查啟動慢問題時它就是一把快速定位的尺子。還有一類場景在生命周期里特別容易踩雷在DisposableBean的destroy方法里訪問其他Bean。銷毀階段不是按創(chuàng)建的反序執(zhí)行的Spring只保證同一個Bean內部回調順序不保證Bean之間的銷毀順序。如果你的銷毀邏輯依賴另一個Bean很可能已經拿到一個正在銷毀中的對象。我的建議是銷毀邏輯里只做最低限度的清理工作不要把業(yè)務補償邏輯放在這里。按我的經驗來說這道題很多人答不好不是不知道流程而是不理解“為什么Spring要設置這么多擴展點”。你準備的時候別死背順序而是把Spring想解決的問題——對象創(chuàng)建、依賴裝配、擴展定制、代理增強、銷毀清理——按問題去記面試時從問題講機制給面試官的感覺就完全是另一個層次。最后再分享一個小技巧。準備這道題時自己開一個Spring Boot工程定義兩個互相依賴的Bean分別實現(xiàn)InitializingBean、PostConstruct、各寫Aware接口再加一個自定義BeanPostProcessor全項目打上日志。跑一遍你會看到所有回調的觸發(fā)順序和對象狀態(tài)。親手觀察一遍比背十遍八股都牢。等你能解釋為什么需要三級緩存的時候你已經不只是會背八股的人而是真正理解IoC容器的那個人。