凡夫编程

在Spring中，条件注解可根据特定的条件来决定是否创建或配置Bean，这些条件可以基于类、属性、环境等因素。通过使用条件注解，我们可以在Spring容器中更加灵活地管理和控制组件的创建和注入，帮助我们更加灵活地管理和控制Bean的创建和注入，提高代码的灵活性和可维护性。总之，使用很简单，功能很强大。如果你在项目里有类似下面这样的需求场景，选择使用相关的条件注解，绝对是是非常优雅的实现，没有之一。

在Spring boot项目中，凡是标记有@Component、@Controller、@Service、@Configuration、@Bean等注解的类，Spring boot都会在容器启动的时候，自动创建bean并纳入到Spring容器中进行管理，这样就可以使用@Autowired等注解，在需要使用bean的业务类中进行注入。

Logback和Log4j都是为Java应用程序提供的比较流行的开源日志框架，它们都由同一个开发者创建和维护，但在功能和性能上存在一些差异，Logback可以认为是log4j的改进版，在性能、配置应用上都要优于log4j，Logback主要由三个模块构成：logback-core，logback-classic和logback-access。其中，logback-core是其他两个模块的基础，提供了Logback的核心功能。logback-classic模块实现了简单日志门面SLF4J，而logback-a

Redis队列和MQ消息队列各有优势，Redis的最大特点就是快，所以基于Redis的消息队列相比MQ消息队列而言，更适合实时处理，但是基于Redis的消息队列更易受服务器内存限制；而RocketMQ消息队列作为专业的消息中间件产品，功能更完善，更适合应用于比较复杂的业务场景，可以实现离线消息发送、消息可靠投递以及消息的安全性，但MQ消息队列的读写性能略低于Redis队列。在技术选型时，除了上述的因素外，还有一个需要注意：大多数系统都会引入Redis作为基础的缓存中间件使用，如果要选用RocketMQ的话，

操作日志，是用户实际业务操作行为的记录，这些信息一般存储在数据库里，如什么时间哪个用户点了某个菜单、修改了哪个配置等这类业务操作行为，这些日志信息是给普通用户或系统管理员看到。通过对需求的分析，客户想要是一个业务操作日志管理的功能：1、记录用户的业务操作行为，记录的字段有：操作人、操作时间、操作功能、日志类型、操作内容描述、操作内容报文、操作前内容报文2、提供一个可视化的页面，可以查询用户的业务操作行为，对重要操作回溯；3、提供一定的管理功能，必要的时候可以对用户的误操作回滚；

敏感字段数据是加密存储在数据库的表中，如果需要对这些敏感字段进行模模糊查询，还用原来的通过sql的where从句的like来模糊查询的方式肯定是不行的，那么应该怎么实现呢？这篇文章就来解决这个问题。分词密文映射表，这种方法是对第二种思路的基础上进行延伸优化，也是主流的方法。新建一张分词密文映射表，在敏感字段数据新增、修改的后，对敏感字段进行分词组合，如“15503770537”的分词组合有“155”、“0377”、“0537”等，再对每个分词进行加密，建立起敏感字段的分词密文与目标数据行主键的关联关系；在处

在《Springboot项目如何设计接口中敏感字段的加密、解密》中，分享了Springboot项目里写入请求、读取请求的接口中敏感字段数据如何加密、解密，其实对于敏感数据的处理方式，除了在服务端进行数据加密、解密，在前端数据展示的时候，也要进行相应的“加密”处理，以防止用户的隐私信息被泄漏，这里的“加密”实际是数据脱敏。由于数据脱敏和数据加密的处理过程是完全不同的，所以我认为这是两个概念；当然，仁者见仁，智者见者，这是我的个人理解。单独起一篇文章，就来好好好盘一盘数据脱敏和数据加密的区别以及实现方式。

Springboot项目中，客户端通过接口向服务端读取或写入敏感数据时，常会有这样的业务需求：1、在客户端向服务器端发起写入请求，服务端需要对写入的敏感数据进行加密后存储；2、在客户端从服务器端向外读取数据的时候，需要对输出的敏感数据里德解密；显然这种场景，对于加密的方式的选择，对称加密是最好的选择；那么如何实现对写入请求、读取请求的敏感数据的加密、解密处理呢？解决方案如下：1、自定义两个切面注解，分别是加密切面注解、解密切面注解，作用于需要加密或解密的敏感数据处理的业务处理类的具体业务处理方法上；

mybatis的流式查询，有点冷门，实际用的场景比较少，但是在某些特殊场景下，却是十分有效的一个方法。很多人没有听说过，实际上是对mybatis没有太重视，对mybatis想法还停留一个dao接口对应着mapper里的一个sql，mybatis的关键是如何写好sql以及sql的优化上；其实mybatis远不止这些，通过这篇文章，和大家一块来见识一下流式查询，mybatis相对冷门的神秘面纱。文章的内容将从以下几个方面展开：1、什么是mybatis的流式查询；2、Cursor接口的主要方法；3、代码层面如何实

今天给大家分享一下，如何使用springboot快速实现简单的定时调度任务？有两种方法：基于注解的声明式调度任务注册；另外一种是基于实现SchedulingConfigurer的编程式的调度任务注册。

现在智能手表、手环，相信很多人都使用过，其中有一个功能，就是会有各种的提醒，如喝水提醒、运动提醒、远眺提醒，本质上根据用户的设置，间隔一定时间执行一个调度任务，提醒用户做某件事情。这篇文章将以这样的场景为便，和大家分享一下如何使用SprIngboot对定时调度任务进行动态管理。

通过分析Springboot两种调度任务的实现方法的工作原理，有什么收获呢？第一，默认情况下，使用单线程的线程池来执行调度任务，性能上不会太高，适用场景有限；第二，即便显性的任务调度器配置了拥用较多线程的线程池，与现有其他业务同处一个工程，也会挤占其他业务的服务器资源；所以，在实际使用过程中，应根据实际场景和资源配置进行选择。

excel表格的导入与导出，可以说是业务系统里比较常见的功能了，早些时候相信很多人都是使用POI实现excel的导入与导出功能，后来出现了easyexcel，从我自己的使用感受来说，我更喜欢使用easyexcel，除了封装的比较好外，最重要的是对超级大excel导入有了更好的方案，与POI相比，速度更快，占用内存更少。

自定义格式转换的后导出可以参考上一篇《Springboot+Easyexcel:导入excl》中的日期、数字及其他自定义格式的转换部分，SalaryDateConverter#convertToExcelData()，导出时候的数据格式转换逻辑可以写在这里面；SalaryDateConverter#convertToJavaData()导入时候的数据格式转换的实现逻辑可以写在这里；SalaryDateConverter实现了com.alibaba.excel.converters.Converter接口；

我比较喜欢使用easyexcel的一个很重要的原因就是，easyexcel在poi的基础上，封装的比较友好。就比如，在导出的时候，很多情况下需要自定义表格的样式，easyexcel就提供了多种的实现方式。主要有三种：1、通过注解；2、编程式；3、自定义类型转换器。通过编程式来自定义导出表格的样式中，有一个非常关键类HorizontalCellStyleStrategy。1、通过HorizontalCellStyleStrategy可以配置好表头的样式和数据行的样式；

在后端的接口开发过程，实际上每一个接口都或多或少有不同规则的参数校验，有一些是基础校验，如非空校验、长度校验、大小校验、格式校验；也有一些校验是业务校验，如学号不能重重复、手机号不能重复注册等；对于业务校验，是需要和数据库交互才能知道校验结果；对于参数的基础校验，是有一些共有特征可以抽象出来，可以做成一个通用模板（java就是一种面向对象的编程语言，还记得天天快要说烂问烂的面向对象的三大特性吗？）。基于实际场景的需要，java API中定义了一些Bean校验的规范标准（JSR303:validation-a

在后端的接口开发过程，实际上每一个接口都或多或少有不同规则的参数校验，有一些是基础校验，如非空校验、长度校验、大小校验、格式校验；也有一些校验是业务校验，如学号不能重重复、手机号不能重复注册等；对于业务校验，是需要和数据库交互才能知道校验结果；对于参数的基础校验，是有一些共有特征可以抽象出来，可以做成一个通用模板（java就是一种面向对象的编程语言，还记得天天快要说烂问烂的面向对象的三大特性吗？）。基于实际场景的需要，java API中定义了一些Bean校验的规范标准（JSR303:validation-a

在实际使用Spring MVC开发java web项目的过程中，前端调用后端的接口时，通常是以json报文的格式传递到后台，spring会对抆参数进行解析最后映射到controller层方法中。而日期类型参数前端传递过来通常是yyyy-MM-dd或yyyy-MMdd HH:mm:ss格式的字符串，而接收参数的对象中往往是LocalDate、LocalDateTime、Date，映射的时候经常会出现异常报错，这篇文章用一个小例子来分享遇到这种情况是应该是如何解决？ java.time.Local

突然想起以前一个同事刚入项目的时候干过的一件有趣的事，入项分配给他的第一个开发任务，在项目里引入了几十个util工具类，据说是多年珍藏，有的还是自己写的，然后上灰度的时候发现各种的maven冲突，相信有很新手都干过类似的事吧。大部分的项目基本是ssh的框架，像一些断言、字符串、对象、集合、文件相关的工具类不可能还需要自己来封装，为什么呢？Spring家族生态这么茂盛，Spring内部的肯定少不了会用到断言、对象、集合、文件读取相关的操作方法，Spring都封装的这么好，这些小的内容大概率自己也会封装好。

在实际的业务开发中，除了经常有针对对象的判断或操作以外，经常也会遇到的就是字符串的判断和操作。比如判断字符串是否为空、是否以某个字符结尾、去除头部和尾部的空白字符、字符的查找和替换。在Spring的核心包中存在这样一个类org.springframework.util.StringUtils，它提供了常见的关于字符串的判断和操作的静态方法。

org.springframework.util.ObjectUtils类中有很多已经封装好的静态方法，平时用到的里面基本都有，下面是整体的UML类图，这里只是分享其中用互频率非常高的7种，有兴趣的小伙伴可以继续深入探索下去。

实际业务开发中，集合的判断和操作也是经常用到的，Spring也针对集合的判断和操作封装了一些方法，但是最令我惊讶的是，我在梳理这些内容的过程中发现了一些有趣的现象，我的第一反应是不敢相信，再想一想，没错，我是对的。所以强烈建议大家可以认真看完这篇文章，这一篇绝对有价值，因为有趣的是我我竟然发现了Spring的两个bug。

ReflectionUtils应该是Springboot内置工具类梳理的最后一篇了，可以很多人都没有听说过这个工具类。这个类封装的是一些与java反射相关的静态工具方法，可能很多人知道反射，却不怎么经常使用反射。其实反射是一个很用的技术点，我认为是可以和AOP比肩的，甚至有过之而不及。大家都知道AOP是面向切面编程，可以在定义的切面前、后执行一些操作，但是反射更厉害，它可以在程序运行时，对已装载的任意类的属性和方法进行操作，这就是java的反射机制。

Spring内置的工具类里，最喜欢用的就是文件读写这一部分，虽然原生的写法也没几句，但是就是懒，不想循环、判断什么的，直接调用现成的静态方法，多高效，哈哈，这就是懒人必备。

事件监听机制是一套很有用的机制，其原理就是观察者模式，而观察者模式又被称为发布-订阅模式，有人说23种设计模式平时很少用上，总是看了忘，我只能说你太不走心了。我的经验就是一定要带着问题去学习新东西，设计模式不仅是一套理论，更是长期的工程实践总结出来经验、解决方案。想要掌握好，必须要弄清每一个设计模式的本质是为了解决什么问题。 事件监听机制的本质是一套流程，这套流程描述的是某个位置发生了一些事，发生的这些事又触发了另外一些事。如果使用面向对象的思想对这套流程进行抽象，会抽象出来几个非常关键的类，

这是继《springboot事件监听机制一：实战应用》第二篇，知其然，当然还要知其所以然，深入的源码里面探寻一下这一有套机制的工作原理。spring生态很茂盛，这里不会站太高去分析这个问题，大扯spring的一些原理，而是以一个求知者的心态去探索spring监听机制的秘密，可能我分析得并不透彻，但我想如果能给看到这篇文章的你带去一些灵感或者触动也是好的。罗马不是一天就能建立起来的，想要弄懂它也非一天的事，多想多看总会明白的。另外看源码的时候，一定是带着问题去探寻，时刻把握好问题的核心，切忌被旁枝末节打扰而迷

优雅？看到这个词，我第一反应是什么是优雅？怎么写才算优雅？一千个读者有一千个哈姆雷特，每个人的经验、阅历不同，也许理解就不同。我对优雅的理解很简单，就是简洁有效、容易理解，别那么多套路。java中使用Sping的web项目通常会分为三层，分别是controller、service、dao，这似乎已成为了一个既定规则。很少有人去想为什么要这样分？可不可不以不这样分？java属于面向对象的高级编程语言，其实这种分法并不符合面向对象的理念，而实际这是按照一次B-S请求过程从外到内的调用过程划分的，然后根据面向接口

没有必要，因为SQL写正确了，大概率是不会有异常的；以电商项目为例来说，调用订单服务接口进行下单操作时，要先确认是否有库存，就会在订单服务接口内调用远程的库存服务接口，确认是否有库存，如果确认还有库存，继续调用订单服务的dao接口进行下单的业务逻辑，并调用库存服务的减库存接口，进行扣减库存。给编程工具里安装一个阿里编码规约插件，如果我没有记错好像是80行，但是这个也不绝对，标准是死的，个别可以根据实际情况灵活变通，不要动不动就搞个几百行、上千行的就行，如果给你一篇几千字的文章，就一个段落，你会怎么想？

如果仅仅会使用Springboot、SpringMVC完成一些增删改查，解决一些bug，那么实际上你并没有真的懂Spring、Springboot。Spring的核心是容器，Springboot更是封装了Spring，把复杂隐藏在内部，让其在使用上更简单，同时又预留了很多的扩展。所以我认为学会Springboot的简单使用只是一个开始，对业务开发更有参考和学习意义的是Springboot如何把复杂变得简单、预留的扩展接口又是如何使用的。

验证结果表明，自定义的BeanFactoryPostProcessor接口的实现类（MyBeanFactoryPostProcessor），可以在容器读取到Bean的BeanDefinition数据之后，bean未实例化前，读取BeanDefiniion数据，并且根据需要进行修改，那么自定义的BeanFactoryPostProcessor接口的实现类（MyBeanFactoryPostProcessor）的工作原理是什么呢？BeanFactoryPostProcessor接口的实现类是什么时候实例化的？

通过这篇文章来大家分享一下，另外一个Springboot的扩展点BeanDefinitionRegistryPostProcessor，一般称这类扩展点为容器级后置处理器，另外一类是Bean级的后置处理器；容器级的后置处理器会在Spring容器初始化后、刷新前这个时间执行一次，Bean级的重置处理器，则是在每一个Bean实例化前后都会执行。

在程序中我们可以自定义注解并标到相应的类上，当个类注册到Spring容器中，并实例化完成后，希望触发自定义注解对应的一些其他操作的时候，就可以通过BeanPostProcessor来实现。

前面介绍了Springboot的扩展点之BeanPostProcessor，再来介绍另一个扩展点InstantiationAwareBeanPostProcessor就容易多了。因为InstantiationAwareBeanPostProcessor也属于Bean级的后置处理器，还继于BeanPostProcessor，因此InstantiationAwareBeanPostProcessor除了可以实现BeanPostProcessor的扩展外，又额外增加了三个扩展点，这篇文章也是围绕这三个扩展点展示，

这是Springboot扩展点系列的第5篇了，主要介绍一下SmartInstantiationAwareBeanPostProcessor扩展点的功能特性、和实现方式。SmartInstantiationAwareBeanPostProcessor与其他扩展点最明显的不同，就是在实际的业务开发场景中应用到的机会并不多，主要是在Spring内部应用，但是为什么还要了解呢？遇到能力强的人要学他三分，遇到优秀的应用模式，同样也应该学他三分，这便是我依然要花一些时间把他分享给大家的原因。

这篇文章主要来分享Springboot的扩展点之ApplicationContextAwareProcessor，而ApplicationContextAwareProcessor本身并不是扩展点，而是BeanPostProcessor扩展接口的具体实现，关于BeanPostProcessor扩展接口的功能特性、实现方式和工作原理可以移步Springboot扩展点之BeanPostProcessor，但是还是要当作Springboot的扩展点来分析，是因为其内部有6个扩展点可供实现，分别是Environme

@postContruct全限定类名是javax.annotation.PostConstruct，可以看出来其本身不是Spring定义的注解，但是Spring提供了具体的实现，所以这篇文章主要分析的是@PostConstruct在Spring项目开发中的功能特性、实现方式和基本工作原理。

InitializingBean这个扩展点，其实在Springboot扩展点之BeanPostProcessor中已经简单有所涉及，而这篇文章的将重点分析其功能特性、实现方式和工作原理。功能特性：1、Spring中提供了InitializingBean接口，帮助用户实现一些自定义的初始化操作；在bean实例化、属性注入后的提供了一个扩展方法afterPropertiesSet()；2、其实现方式很简单，需要bean实现InitializingBean接口并且重写afterPropertiesSet()，且b

这篇文章会重点分析一下SmartInitializingSingleton扩展点的功能 特性、实现方式 、工作原理。SmartInitializingSingleton扩展点内只有一个扩展方法，且执行时机在Spring Bean的生命周期里比较靠后，很重要，但是也很简单。功能特性：1、SmartInitializingSingleton主要用于在Spring容器启动完成时进行扩展操作，即afterSingletonsInstantiated()；2、实现SmartInitializingSing

大家都知道Springboot简化了Spring的开发，因此从某种意义来说，Spring的扩展点也是Springboot的扩展点，而这篇文章主角是CommandLineRunner和ApplicationRunner，而这两个是Springboot中新增的扩展点，之所以将这两个扩展点放在一起，是因为它两个功能特性高度相似，不同的只是名字、扩展方法形参数类型、执行先后的一些小的不同，那么下面就直接进入正题吧。功能特性:1、CommandLineRunner和ApplicationRunner都有一个扩展方法r

FactoryBean是一个有意思，且非常重要的扩展点，之所以说是有意思，是因为它老是被拿来与另一个名字比较类似的BeanFactory来比较，特别是在面试当中，动不动就问你：你了解Beanfactory和FactoryBean的区别吗？其实两个是完全不同的接口，如果非要说出有什么明显区别，大概就是名字吧。为什么又说非常重要呢？那是因为在创建一些比较复杂的bean的时候，常规的方式不能使用，就可以考虑使用FactoryBean，特别其他框架技术与Spring集成的时候，如mybatis与Spring的集成，