Spring Boot详细打印启动时异常堆栈信息详析

前言

SpringBoot在项目启动时如果遇到异常并不能友好的打印出具体的堆栈错误信息,我们只能查看到简单的错误消息,以致于并不能及时解决发生的问题,针对这个问题SpringBoot提供了故障分析仪的概念(failure-analyzer),内部根据不同类型的异常提供了一些实现,我们如果想自定义该怎么去做?

FailureAnalyzer

SpringBoot提供了启动异常分析接口FailureAnalyzer,该接口位于org.springframework.boot.diagnosticspackage内。
内部仅提供一个分析的方法,源码如下所示:

@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);

}

该接口会把遇到的异常对象实例Throwable failure交付给实现类,实现类进行自定义处理。

AbstractFailureAnalyzer

AbstractFailureAnalyzer是FailureAnalyzer的基础实现抽象类,实现了FailureAnalyzer定义的analyze(Throwable failure)方法,并提供了一个指定异常类型的抽象方法analyze(Throwable rootFailure, T cause),源码如下所示:

public abstract class AbstractFailureAnalyzer<T extends Throwable> 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<? extends T> getCauseType() {
  return (Class<? extends T>) ResolvableType.forClass(AbstractFailureAnalyzer.class, getClass()).resolveGeneric();
 }

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

}

通过AbstractFailureAnalyzer源码我们可以看到,它在实现于FailureAnalyzer的接口方法内进行了特殊处理,根据getCauseType()方法获取当前类定义的第一个泛型类型,也就是我们需要分析的指定异常类型。

获取泛型异常类型后根据方法findCause判断Throwable是否与泛型异常类型匹配,如果匹配直接返回给SpringBoot进行注册处理。

SpringBoot提供的分析实现

SpringBoot内部通过实现AbstractFailureAnalyzer抽象类定义了一系列的针对性异常类型的启动分析,如下图所示:

指定异常分析

SpringBoot内部提供的启动异常分析都是指定具体的异常类型实现的,最常见的一个错误就是端口号被占用(PortInUseException),虽然SpringBoot内部提供一个这个异常的启动分析,我们也是可以进行替换这一异常分析的,我们只需要创建PortInUseException异常的AbstractFailureAnalyzer,并且实现类注册给SpringBoot即可,实现自定义如下所示:

/**
 * 端口号被占用{@link PortInUseException}异常启动分析
 *
 * @author 恒宇少年
 */
public class PortInUseFailureAnalyzer extends AbstractFailureAnalyzer<PortInUseException> {
  /**
   * logger instance
   */
  static Logger logger = LoggerFactory.getLogger(PortInUseFailureAnalyzer.class);

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

注册启动异常分析

在上面我们只是编写了指定异常启动分析,我们接下来需要让它生效,这个生效方式比较特殊,类似于自定义SpringBoot Starter AutoConfiguration的形式,我们需要在META-INF/spring.factories文件内进行定义,如下所示:

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

那我们为什么需要使用这种方式定义呢?

项目启动遇到的异常顺序不能确定,很可能在Spring IOC并未执行初始化之前就出现了异常,我们不能通过@Component注解的形式使其生效,所以SpringBoot提供了通过spring.factories配置文件的方式定义。

启动异常分析继承关系

自定义的运行异常一般都是继承自RuntimeException,如果我们定义一个RuntimeException的异常启动分析实例会是什么效果呢?

/**
 * 项目启动运行时异常{@link RuntimeException}统一启动分析
 *
 * @author 恒宇少年
 */
public class ProjectBootUnifiedFailureAnalyzer extends AbstractFailureAnalyzer<RuntimeException> {
  /**
   * logger instance
   */
  static Logger logger = LoggerFactory.getLogger(ProjectBootUnifiedFailureAnalyzer.class);

  @Override
  protected FailureAnalysis analyze(Throwable rootFailure, RuntimeException cause) {
    logger.error("遇到运行时异常", cause);
    return new FailureAnalysis(cause.getMessage(), "error", rootFailure);
  }
}

将该类也一并注册到spring.factories文件内,如下所示:

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

运行项目并测试端口号被占用异常我们会发现,并没有执行ProjectBootUnifiedFailureAnalyzer内的analyze方法,而是继续执行了PortInUseFailureAnalyzer类内的方法。

那我们将PortInUseFailureAnalyzer这个启动分析从spring.factories文件内暂时删除掉,再来运行项目我们会发现这时却是会执行ProjectBootUnifiedFailureAnalyzer类内分析方法。

总结

根据本章我们了解了SpringBoot提供的启动异常分析接口以及基本抽象实现类的运作原理,而且启动异常分析存在分析泛型异常类的上下级继承关系,异常子类的启动分析会覆盖掉异常父类的启动分析,如果你想包含全部异常的启动分析可以尝试使用Exception作为AbstractFailureAnalyzer的泛型参数。

以上就是我在处理客户端真实IP的方法,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对我们的支持。

(0)

相关推荐

  • Spring Boot全局异常处理解析

    本文为大家分享了Spring Boot全局异常处理,供大家参考,具体内容如下 1.后台处理异常 a.引入thymeleaf依赖 <!-- thymeleaf模板插件 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency>

  • springboot全局异常处理详解

    一.单个controller范围的异常处理 package com.xxx.secondboot.web; import org.springframework.web.bind.annotation.ExceptionHandler; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestMethod; import

  • SpringBoot如何优雅的处理全局异常

    前言 本篇文章主要介绍的是SpringBoot项目进行全局异常的处理. SpringBoot全局异常准备 说明:如果想直接获取工程那么可以直接跳到底部,通过链接下载工程代码. 开发准备 环境要求 JDK:1.8 SpringBoot:1.5.17.RELEASE 首先还是Maven的相关依赖: <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.

  • 详解Springboot自定义异常处理

    背景 Springboot 默认把异常的处理集中到一个ModelAndView中了,但项目的实际过程中,这样做,并不能满足我们的要求.具体的自定义异常的处理,参看以下 具体实现 如果仔细看完spring boot的异常处理详解,并且研究过源码后,我觉得具体的实现可以不用看了... 重写定义错误页面的url,默认只有一个/error @Bean public EmbeddedServletContainerCustomizer containerCustomizer(){ return new E

  • Spring Boot统一异常处理详解

    Spring Boot中默认带了error的映射,但是这个错误页面显示给用户并不是很友好. 统一异常处理 通过使用@ControllerAdvice定义统一异常处理的类,而不是在每个Controller中逐个定义. @ExceptionHandler用来定义函数针对的函数类型,最后将Exception对象和请求URL映射到URL中. @ControllerAdvice class ExceptionTranslator { public static final String DEFAULT_E

  • 浅谈Spring Boot 异常处理篇

    前言 先谈谈"异常处理"这件事.下面有 2 份伪代码,对比下: // ① 基于 if/else 判断 if(deletePage(page) == E_OK){ if(registry.deleteReference(page.name) == E_OK){ if(configKeys.deleteKey(page.name.makeKey()) == E_OK){ logger.log("page deleted"); }else{ logger.log(&quo

  • Spring boot项目中异常拦截设计和处理详解

    背景: 项目运行过程中会出现各种各样的问题,常见的有以下几种情况: 业务流程分析疏漏,对业务流程的反向操作.边界分析设计不充分 调用外部服务.调用外部系统出现的超时.错误.返回值与预期不符 外部资源连通性问题,db等服务器出现的网络抖动或宕机 无论是分析设计.开发.测试.线上都需要能够准确定位问题并制定解决方案. 目的: 规范化异常的处理过程,避免异常被吞和到处都在捕获异常的情况 准确的反馈异常信息,为定位问题提供依据 通用性异常全局处理,降低业务开发关注度 对异常情况进行预警,以便能够及时响应

  • SpringBoot初始教程之统一异常处理详解

    1.介绍 在日常开发中发生了异常,往往是需要通过一个统一的异常处理处理所有异常,来保证客户端能够收到友好的提示.SpringBoot在页面发生异常的时候会自动把请求转到/error,SpringBoot内置了一个BasicErrorController对异常进行统一的处理,当然也可以自定义这个路径 application.yaml server: port: 8080 error: path: /custom/error BasicErrorController提供两种返回错误一种是页面返回.当

  • Spring Boot详细打印启动时异常堆栈信息详析

    前言 SpringBoot在项目启动时如果遇到异常并不能友好的打印出具体的堆栈错误信息,我们只能查看到简单的错误消息,以致于并不能及时解决发生的问题,针对这个问题SpringBoot提供了故障分析仪的概念(failure-analyzer),内部根据不同类型的异常提供了一些实现,我们如果想自定义该怎么去做? FailureAnalyzer SpringBoot提供了启动异常分析接口FailureAnalyzer,该接口位于org.springframework.boot.diagnosticsp

  • SpringBoot打印启动时异常堆栈信息详解

    SpringBoot在项目启动时如果遇到异常并不能友好的打印出具体的堆栈错误信息,我们只能查看到简单的错误消息,以致于并不能及时解决发生的问题,针对这个问题SpringBoot提供了故障分析仪的概念(failure-analyzer),内部根据不同类型的异常提供了一些实现,我们如果想自定义该怎么去做? FailureAnalyzer SpringBoot提供了启动异常分析接口FailureAnalyzer,该接口位于org.springframework.boot.diagnosticspack

  • Spring Boot解决项目启动时初始化资源的方法

    前言 在我们实际工作中,总会遇到这样需求,在项目启动的时候需要做一些初始化的操作,比如初始化线程池,提前加载好加密证书等.今天就给大家介绍一个 Spring Boot 神器,专门帮助大家解决项目启动初始化资源操作. 这个神器就是 CommandLineRunner, CommandLineRunner 接口的 Component 会在所有 SpringBeans都初始化之后, SpringApplication.run()之前执行,非常适合在应用程序启动之初进行一些数据初始化的工作. 接下来我们

  • spring boot 命令行启动的方式

    在使用spring boot 构建应用启动时,我们在工作中都是通过命令行来启动应用,有时候会需要一些特定的参数以在应用启动时,做一些初始化的操作. spring boot 提供了 CommandLineRunner 和 ApplicationRunner 这两个接口供用户使用. 1. CommandLineRunner 1.1 声明: @FunctionalInterface public interface CommandLineRunner { /** * Callback used to

  • Spring Boot 详细分析Conditional自动化配置注解

    目录 1. Spring Boot Condition功能与作用 2. Conditional条件化系列注解介绍 3. Conditional条件化注解的实现原理 4. Conditional核心之matches匹配接口 5. Conditional核心之条件化注解具体实现 6. 总结 1. Spring Boot Condition功能与作用 @Conditional是基于条件的自动化配置注解, 由Spring 4框架推出的新特性. 在一个服务工程, 通常会存在多个配置环境, 比如常见的DEV

  • spring boot jar的启动原理解析

     1.前言 近来有空对公司的open api平台进行了些优化,然后在打出jar包的时候,突然想到以前都是对spring boot使用很熟练,但是从来都不知道spring boot打出的jar的启动原理,然后这回将jar解开了看了下,与想象中确实大不一样,以下就是对解压出来的jar的完整分析. 2.jar的结构 spring boot的应用程序就不贴出来了,一个较简单的demo打出的结构都是类似,另外我采用的spring boot的版本为1.4.1.RELEASE网上有另外一篇文章对spring

  • Spring Boot优雅地处理404异常问题

    背景 在使用SpringBoot的过程中,你肯定遇到过404错误.比如下面的代码: @RestController @RequestMapping(value = "/hello") public class HelloWorldController { @RequestMapping("/test") public Object getObject1(HttpServletRequest request){ Response response = new Resp

  • spring boot 不连接数据库启动的解决

    目录 spring boot 不连接数据库启动 原因在于 解决方法 SpringBoot项目取消数据库配置 1. 错误 2. 原因 3. 如何不配 spring boot 不连接数据库启动 用spring boot 搭建的项目,在配置文件不连接数据库启动项目会报错. 原因在于 spring boot默认会加载 org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration 类,DataSourceAutoConfig

  • spring boot整合mongo查询converter异常排查记录

    目录 前言 自定义转换器 javabean的方式配置MongoTemplate 后记: 前言 使用过spring boot的人都知道spring boot约定优于配置的理念给我们开发中集成相关技术框架提供了很多的便利,集成mongo也是相当的简单,但是通过约定的配置信息来集成mongo有些问题. 当你的字段包含Timestamp这种类型时,读取数据的时候会抛一个类型转换的异常,如 No converter found capable of converting from type [java.u

  • Spring Boot优化后启动速度快到飞起技巧示例

    目录 引言 启动时间分析 启动优化 减少业务初始化 延迟初始化 Spring Context Indexer 关闭JMX 关闭分层编译 另外的思路 JAR Index APPCDS Heap Archive AOT编译 下线时间优化 优雅下线 Eureka服务下线时间 结束 引言 微服务用到一时爽,没用好就呵呵啦,特别是对于服务拆分没有把控好业务边界.拆分粒度过大等问题,某些 Spring Boot 启动速度太慢了,可能你也会有这种体验,这里将探索一下关于 Spring Boot 启动速度优化的

随机推荐