自動化在DevOps中的力量：簡化軟件開發和交付
自動化在DevOps中扮演著重要角色，它提升了DevOps的效能。通過自動化工具和方法，DevOps團隊可以實現以下目標：消除手動和重復性任務。簡化流程。在整個軟件開發生命周期中實現更
環境：SpringBoot3.3.0
在Spring Boot中，@Configuration注解用于聲明配置類，以定義和注冊Bean對象。這些Bean對象可以是普通的業務組件，也可以是特殊的處理器，如BeanPostProcessor或BeanFactoryPostProcessor，用于在Spring容器中對其他Bean進行額外的處理。接下來我們將詳細的介紹關于在SpringBoot環境下各種不正確的配置導致的各種問題。
當我們在一個配置類中使用@PostConstruct注解并且在其方法內部去引用其它Bean時，將會出現循環依賴錯誤，如下示例：
@Configurationpublic class AppConfig { @PostConstruct public void init() { dao() ; System.out.println("AppConfig init...") ; } @Bean DAO dao() { return new DAO() ; }}在init()方法中調用dao()方法后，將無正確的啟動SpringBoot，拋出如下錯誤
圖片
循環依賴錯誤，導致該錯誤的原因是非靜態@Bean方法在語義上需要一個完全初始化的配置類實例來調用；簡單點說就是在調用dao方法時需要完全的初始化AppConfig類，但是@PostConstruct注解的方法在執行時當前的這個AppConfig并沒有完全的執行完成。要解決該問題可以通過如下2種方式：
開啟循環依賴
spring: main: allow-circular-references: true從SpringBoot2.6+開始默認不允許循環依賴。這樣SpringBoot程序就能正確啟動，不過這不是最好的方式也不推薦該種方式。
將上面的dao方法聲明為static方法；
@Beanpublic static DAO dao() { return new DAO() ;}static修飾的方法不需要包裹它的配置類提起初始化完成。這也是最為推薦的方法。
當通過 @Bean 定義 BeanPostProcessor 和 BeanFactoryPostProcessor 時可能導致當前配置依賴注入的bean將不會生效（也就是@Autowired和@Value注解可能沒有生效），如下示例：
@Configurationpublic class AppConfig { @Value("${pack.title}") private String title ; @Override public String toString() { return "AppConfig [title=" + title + "]"; }}配置文件中配置信息；
pack: title: xxxooo控制臺輸出
AppConfig [title=xxxooo]沒有問題；但是如果你在AppConfig配置類中注冊BeanPostProcessor后會出現什么情況呢？
自定義BeanPostProcessor；
public class PackBeanPostProcessor implements BeanPostProcessor { // TODO}通過@Bean注冊上面的BeanPostProcessor；
@Beanpublic PackBeanPostProcessor packBeanPostProcessor() { return new PackBeanPostProcessor() ;}再次運行服務，控制臺輸出
AppConfig [title=xxxooo]還是能正確的輸出！？注意接下來我們對上面的自定義處理器做如下修改；
public class PackBeanPostProcessor implements BeanPostProcessor, PriorityOrdered { // TODO @Override public int getOrder() { return -1 ; }}這時候我們去實現了PriorityOrdered優先級接口，并將優先級設置的比較的高。如上調整后再次啟動服務
AppConfig [title=null]問題出現了配置的屬性并沒有正確的解析注入，這是因為在默認情況下處理@Value注解的處理器的優先級低于你當前自定義處理器的優先級，所以這就導致了問題。同樣的如果你使用@Autowired或@Resource也將會導致問題，如下示例：
@Configurationpublic class AppConfig { @Resource private Person person ;}輸出結果：
AppConfig [persnotallow=null]同樣不能被注入；
要解決該問題可以通過如下2種方式：
通過實現ApplicationContextInitializer接口；
public class PackApplicationContextInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> { @Override public void initialize(ConfigurableApplicationContext context) { context.getBeanFactory().addBeanPostProcessor(new PackBeanPostProcessor()); }}注冊該實現；
org.springframework.context.Applicatinotallow=/com.pack.PackApplicationContextInitializer這種方式實現非常麻煩；推薦下面的第二種方式
將@Bean對應的方法聲明為static即可。
@Beanpublic static PackBeanPostProcessor packBeanPostProcessor() { return new PackBeanPostProcessor() ;}將該方法聲明為static后，那么容器在獲取BeanPostProcessor是不需要先實例化包裹它的類的實例。
其實對于@Configuration注解的配置類，如果你有需要注入的對象，官方建議采用參數的方式注入，如下示例：
@Configurationpublic class AppConfig { private final Person person ; public AppConfig(Person person) { this.person = person ; }}構造函數注入也是在任何形式下的推薦注入方式。
本文鏈接：http://www.tebozhan.com/showinfo-26-99024-0.html當心！請不要在SpringBoot中再犯這樣嚴重的錯誤
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Rust編程語言到底是不是炒作的噱頭？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號