這篇文章主要介紹了SpringBoot打印啟動(dòng)時(shí)異常堆棧信息的示例分析，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

成都創(chuàng)新互聯(lián)公司企業(yè)建站,10余年網(wǎng)站建設(shè)經(jīng)驗(yàn)，專(zhuān)注于網(wǎng)站建設(shè)技術(shù)，精于網(wǎng)頁(yè)設(shè)計(jì)，有多年建站和網(wǎng)站代運(yùn)營(yíng)經(jīng)驗(yàn)，設(shè)計(jì)師為客戶(hù)打造網(wǎng)絡(luò)企業(yè)風(fēng)格，提供周到的建站售前咨詢(xún)和貼心的售后服務(wù)。對(duì)于網(wǎng)站制作、成都做網(wǎng)站中不同領(lǐng)域進(jìn)行深入了解和探索，創(chuàng)新互聯(lián)在網(wǎng)站建設(shè)中充分了解客戶(hù)行業(yè)的需求，以靈動(dòng)的思維在網(wǎng)頁(yè)中充分展現(xiàn)，通過(guò)對(duì)客戶(hù)行業(yè)精準(zhǔn)市場(chǎng)調(diào)研，為客戶(hù)提供的解決方案。

SpringBoot在項(xiàng)目啟動(dòng)時(shí)如果遇到異常并不能友好的打印出具體的堆棧錯(cuò)誤信息，我們只能查看到簡(jiǎn)單的錯(cuò)誤消息，以致于并不能及時(shí)解決發(fā)生的問(wèn)題，針對(duì)這個(gè)問(wèn)題SpringBoot提供了故障分析儀的概念（failure-analyzer），內(nèi)部根據(jù)不同類(lèi)型的異常提供了一些實(shí)現(xiàn)，我們?nèi)绻胱远x該怎么去做？

FailureAnalyzer

SpringBoot提供了啟動(dòng)異常分析接口FailureAnalyzer，該接口位于org.springframework.boot.diagnosticspackage內(nèi)。
內(nèi)部?jī)H提供一個(gè)分析的方法，源碼如下所示：

@FunctionalInterface
public interface FailureAnalyzer {

 /**
  * Returns an analysis of the given {@code failure}, or {@code null} if no analysis
  * was possible.
  * @param failure the failure
  * @return the analysis or {@code null}
  */
 FailureAnalysis analyze(Throwable failure);

}

該接口會(huì)把遇到的異常對(duì)象實(shí)例Throwable failure交付給實(shí)現(xiàn)類(lèi)，實(shí)現(xiàn)類(lèi)進(jìn)行自定義處理。

AbstractFailureAnalyzer

AbstractFailureAnalyzer是FailureAnalyzer的基礎(chǔ)實(shí)現(xiàn)抽象類(lèi)，實(shí)現(xiàn)了FailureAnalyzer定義的analyze(Throwable failure)方法，并提供了一個(gè)指定異常類(lèi)型的抽象方法analyze(Throwable rootFailure, T cause)，源碼如下所示：

public abstract class AbstractFailureAnalyzer implements FailureAnalyzer {

 @Override
 public FailureAnalysis analyze(Throwable failure) {
  T cause = findCause(failure, getCauseType());
  if (cause != null) {
   return analyze(failure, cause);
  }
  return null;
 }

 /**
  * Returns an analysis of the given {@code rootFailure}, or {@code null} if no
  * analysis was possible.
  * @param rootFailure the root failure passed to the analyzer
  * @param cause the actual found cause
  * @return the analysis or {@code null}
  */
 protected abstract FailureAnalysis analyze(Throwable rootFailure, T cause);

 /**
  * Return the cause type being handled by the analyzer. By default the class generic
  * is used.
  * @return the cause type
  */
 @SuppressWarnings("unchecked")
 protected Class getCauseType() {
  return (Class) ResolvableType.forClass(AbstractFailureAnalyzer.class, getClass()).resolveGeneric();
 }

 @SuppressWarnings("unchecked")
 protected final  E findCause(Throwable failure, Class type) {
  while (failure != null) {
   if (type.isInstance(failure)) {
    return (E) failure;
   }
   failure = failure.getCause();
  }
  return null;
 }

}

通過(guò)AbstractFailureAnalyzer源碼我們可以看到，它在實(shí)現(xiàn)于FailureAnalyzer的接口方法內(nèi)進(jìn)行了特殊處理，根據(jù)getCauseType()方法獲取當(dāng)前類(lèi)定義的第一個(gè)泛型類(lèi)型，也就是我們需要分析的指定異常類(lèi)型。

獲取泛型異常類(lèi)型后根據(jù)方法findCause判斷Throwable是否與泛型異常類(lèi)型匹配，如果匹配直接返回給SpringBoot進(jìn)行注冊(cè)處理。

SpringBoot提供的分析實(shí)現(xiàn)

SpringBoot內(nèi)部通過(guò)實(shí)現(xiàn)AbstractFailureAnalyzer抽象類(lèi)定義了一系列的針對(duì)性異常類(lèi)型的啟動(dòng)分析，如下圖所示：

指定異常分析

SpringBoot內(nèi)部提供的啟動(dòng)異常分析都是指定具體的異常類(lèi)型實(shí)現(xiàn)的，最常見(jiàn)的一個(gè)錯(cuò)誤就是端口號(hào)被占用（PortInUseException），雖然SpringBoot內(nèi)部提供一個(gè)這個(gè)異常的啟動(dòng)分析，我們也是可以進(jìn)行替換這一異常分析的，我們只需要?jiǎng)?chuàng)建PortInUseException異常的AbstractFailureAnalyzer，并且實(shí)現(xiàn)類(lèi)注冊(cè)給SpringBoot即可，實(shí)現(xiàn)自定義如下所示：

/**
 * 端口號(hào)被占用{@link PortInUseException}異常啟動(dòng)分析
 *
 * @author 恒宇少年
 */
public class PortInUseFailureAnalyzer extends AbstractFailureAnalyzer {
 /**
  * logger instance
  */
 static Logger logger = LoggerFactory.getLogger(PortInUseFailureAnalyzer.class);

 @Override
 protected FailureAnalysis analyze(Throwable rootFailure, PortInUseException cause) {
  logger.error("端口被占用。", cause);
  return new FailureAnalysis("端口號(hào)：" + cause.getPort() + "被占用", "PortInUseException", rootFailure);
 }
}

注冊(cè)啟動(dòng)異常分析

在上面我們只是編寫(xiě)了指定異常啟動(dòng)分析，我們接下來(lái)需要讓它生效，這個(gè)生效方式比較特殊，類(lèi)似于自定義SpringBoot Starter AutoConfiguration的形式，我們需要在META-INF/spring.factories文件內(nèi)進(jìn)行定義，如下所示：

org.springframework.boot.diagnostics.FailureAnalyzer=\
 org.minbox.chapter.springboot.failure.analyzer.PortInUseFailureAnalyzer

那我們?yōu)槭裁葱枰褂眠@種方式定義呢？

項(xiàng)目啟動(dòng)遇到的異常順序不能確定，很可能在Spring IOC并未執(zhí)行初始化之前就出現(xiàn)了異常，我們不能通過(guò)@Component注解的形式使其生效，所以SpringBoot提供了通過(guò)spring.factories配置文件的方式定義。

啟動(dòng)異常分析繼承關(guān)系

自定義的運(yùn)行異常一般都是繼承自RuntimeException，如果我們定義一個(gè)RuntimeException的異常啟動(dòng)分析實(shí)例會(huì)是什么效果呢？

/**
 * 項(xiàng)目啟動(dòng)運(yùn)行時(shí)異常{@link RuntimeException}統(tǒng)一啟動(dòng)分析
 *
 * @author 恒宇少年
 */
public class ProjectBootUnifiedFailureAnalyzer extends AbstractFailureAnalyzer {
 /**
  * logger instance
  */
 static Logger logger = LoggerFactory.getLogger(ProjectBootUnifiedFailureAnalyzer.class);

 @Override
 protected FailureAnalysis analyze(Throwable rootFailure, RuntimeException cause) {
  logger.error("遇到運(yùn)行時(shí)異常", cause);
  return new FailureAnalysis(cause.getMessage(), "error", rootFailure);
 }
}

將該類(lèi)也一并注冊(cè)到spring.factories文件內(nèi)，如下所示：

org.springframework.boot.diagnostics.FailureAnalyzer=\
 org.minbox.chapter.springboot.failure.analyzer.PortInUseFailureAnalyzer,\
 org.minbox.chapter.springboot.failure.analyzer.ProjectBootUnifiedFailureAnalyzer

運(yùn)行項(xiàng)目并測(cè)試端口號(hào)被占用異常我們會(huì)發(fā)現(xiàn)，并沒(méi)有執(zhí)行ProjectBootUnifiedFailureAnalyzer內(nèi)的analyze方法，而是繼續(xù)執(zhí)行了PortInUseFailureAnalyzer類(lèi)內(nèi)的方法。

那我們將PortInUseFailureAnalyzer這個(gè)啟動(dòng)分析從spring.factories文件內(nèi)暫時(shí)刪除掉，再來(lái)運(yùn)行項(xiàng)目我們會(huì)發(fā)現(xiàn)這時(shí)卻是會(huì)執(zhí)行ProjectBootUnifiedFailureAnalyzer類(lèi)內(nèi)分析方法。

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“SpringBoot打印啟動(dòng)時(shí)異常堆棧信息的示例分析”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!