前言 有时候我们需要在应用启动时执行一些代码片段，这些片段可能是仅仅是为了记录 log，也可能是在启动时检查与安装证书 ，诸如上述业务要求我们可能会经常碰到 Spring Boot 提供了至少 5 种方式用于在应用启动时执行代码。我们应该如何选择？本文将会逐步解释与分析这几种不同方式 CommandLineRunner CommandLineRunner 是一个接口，通过实现它，我们可以在 Spring 应用成功启动之后 执行一些代码片段 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 @Slf4j @Component @Order(2) public cl

前言 在编写项目代码时，我们要求更灵活的配置，更好的模块化整合。在 Spring Boot 项目中，为满足以上要求，我们将大量的参数配置在 application.properties 或 application.yml 文件中，通过 @ConfigurationProperties 注解，我们可以方便的获取这些参数值 使用 @ConfigurationProperties 配置模块 假设我们正在搭建一个发送邮件的模块。在本地测试，我们不想该模块真的发送邮件，所以我们需要一个参数来「开关」 disable 这个功能。另外，我们希望为这些邮件配置一个默认的主题，这样，当我们查看邮件收件箱，通过

通过如下前序两篇文章: 1. Spring Bean 生命周期之缘起 2. Spring Bean 生命周期之缘尽 我们了解了 Spring Bean 的生命周期核心内容，bean 是如何被初始化变为 Ready for Use 的状态，当资源被回收时又是如何被 destroy 的，但 Spring Bean Life Cycle图并未被全部点亮，这篇文章将点亮剩余内容，同时说说你常见的 XxxxAware 接口 为什么要说 Spring Bean 生命周期又说 Aware 呢？下来点亮剩下内容你也许就明白了： 1. 在 Spring Bean Ready for Us

上一篇文章 Spring Bean 生命周期之缘起 说明了我是谁？ 和 我从哪里来? 的两大哲学问题，今天我们要讨论一下终极哲学我要到哪里去？ 初始化 Spring Bean 有三种方式： 1. @PostConstruct 2. InitializingBean.afterPropertiesSet() 3. init-method 销毁 Spring Bean 同样有三种方式： 1. @PreDestroy 2. DisposableBean.destroy() 3. destroy-method 正所谓，天对地，雨对风； @PostConstruct 对 @Pre

Spring bean 的生命周期很容易理解。实例化 bean 时，可能需要执行一些初始化以使其进入可用 （Ready for Use）状态。类似地，当不再需要 bean 并将其从容器中移除时，可能需要进行一些清理，这就是它的生命周期 上一篇文章 面试还不知道BeanFactory和ApplicationContext的区别？ 中说明了接口 Beanfactory 和 Applicationcontext 可以通过 T getBean(String name, Class requiredType) 方法从 Spring 容器中获取bean，区别是，前者是懒加载形式，后者是预加载的形式

阅读全文

前言 接口 BeanFactory 和 ApplicationContext 都是用来从容器中获取 Spring beans 的，但是，他们二者有很大不同 我看到过很多问 BeanFactory 和 ApplicationContext 不同点的问题，考虑到这，我应该使用前者还是后者从 Spring 容器中获取 beans 呢？请向下看 什么是 Spring Bean 这是一个非常简单而又很复杂的问题，通常来说，Spring beans 就是被 Spring 容器所管理的 Java 对象，来看一个简单的例子 1 2 3 4 5 6 7 8 9 10 package com.zolta

前言 在剖析完 「Spring Boot 统一数据格式是怎么实现的？ 」文章之后，一直觉得有必要说明一下 Spring’s Data Binding Mechanism 「Spring 数据绑定机制」。 默认情况下，Spring 只知道如何转换简单数据类型。比如我们提交的 int、String 或 boolean类型的请求数据，它会自动绑定到与之对应的 Java 类型。但在实际项目中，远远不够，因为我们可能需要绑定更复杂的对象类型。 我们需要了解 Spring 数据绑定机制，这样我们就可以更灵活的做全局配置或自定义配置，进而让我们的 RESTful API 更简洁，可读性也更好。本文依旧先

Java Web 人员经常要设计 RESTful API（如何设计好的RESTful API），通过 json 数据进行交互。那么前端传入的 json 数据如何被解析成 Java 对象作为 API入参，API 返回结果又如何将 Java 对象解析成 json 格式数据返回给前端，其实在整个数据流转过程中，HttpMessageConverter 起到了重要作用；另外在转换的过程我们可以加入哪些定制化内容？ HttpMessageConverter 介绍 org.springframework.http.converter.HttpMessageConverter 是一个策略接口，接口说明如下

写在前面 我们每次构建一个 Spring 应用程序时，我们都不希望从头开始实现具有「横切关注点」的内容；相反，我们希望一次性实现这些功能，并根据需要将它们包含到任何我们要构建的应用程序中 横切关注点 横切关注点: 指的是一些具有横越多个模块的行为 (来自维基百科的介绍) 说白了就是多个项目或模块都可以用到的内容，比如一个 SDK 在Spring Boot中，用于表示提供这种横切关注点的模块的术语是 starter，通过依赖 starter 可以轻松使用其包含的一些功能特性，无论你的工作中是否会构建自己的 starter，你都要具有构建 「starter」的思想，本文将结合 Spring

话说异常 「欲渡黄河冰塞川，将登太行雪满天」，无论生活还是计算机世界难免发生异常，上一篇文章RESTful API 返回统一JSON数据格式 说明了统一返回的处理，这是请求一切正常的情形；这篇文章将说明如何统一处理异常，以及其背后的实现原理，老套路，先实现，后说明原理，有了上一篇文章的铺底，相信，理解这篇文章就驾轻就熟了 实现 新建业务异常 新建 BusinessException.class 类表示业务异常，注意这是一个 Runtime 异常 1 2 3 4 5 6 7 8 9 @Data @AllArgsConstructor public final class Busine