SpringBoot项目更换启动时控制台打印的banner

更换Banner1、在resources目录下新建banner.txt文件2、制作Banner之后制作Banner，这里我推荐几个网站：-http://patorjk.com/software/taag-http://www.network-science.de/ascii/-http://www.degraeve.com/img2txt.php把banner字符输入之后提交就可以得到想要的Banner了，下面是我的网站的启动效果：感兴趣的小伙伴赶快去尝试一下吧！

SpringBoot网站基于OAuth2添加第三方登录之GitHub登录

一、OAuth2简介OAuth是目前最流行的授权机制，用来授权第三方应用，获取用户数据。OAuth在全世界已经得到广泛应用，目前的版本是2.0版。简单说，OAuth就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。因此令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异：令牌是短期的，到期会自动失效，用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。令牌可以被数据所有者撤销，会立即失效。令牌有权限范围（scope）因为令牌有着和密码一样的功能，所以对于令牌也必须严格保密，泄漏令牌和泄漏密码的后果是一样的。这也就是为啥令牌的有效期很短的原因了。二、GitHub第三方登录的原理第三方登录实际就是OAuth授权认证。用户想要登录A网站，A网站让用户提供第三方网站的数据，证明自己的身份。获取第三方网站的身份数据，就需要OAuth授权。以使用GitHub为第三方登录为例：用户在网站点击使用GitHub登录，A网站跳转到GitHub（会带上回调URI和ClientID）GitHub要求用户登录，然后询问"A网站要求获得xx权限，你是否同意？"（对于同一个网站，同意一次之后，下次再登录就不在需要用户授权）用户同意，GitHub就会重定向回A网站，同时发回一个授权码。A网站使用授权码，向GitHub请求令牌。GitHub返回令牌.A网站使用令牌，向GitHub请求用户数据。使用GitHub做第三方登录认证的具体的流程可如下图所示：好了，原理大致了解到这里，接下来动手搭建一下GitHub第三方登录。三、GitHub第三方登录搭建示例1、创建应用①登录github后台（地址：https://github.com/settings/developers），创建应用你需要添加GitHub登录的应用。或者在GitHub的settings中点击Deveplopersettings②之后直接点击NewGitHubApp③之后填写你的App有关的信息即可在注册成功之后，GitHub会返回客户端ID（clientID）和客户端密钥（clientsecret），这就是应用的身份识别码，在授权的时候会用到。一个填写示例：2、几个重要的URL登录页面授权URL：https://github.com/login/oauth/authorize?client_id=%s&redirect_uri=%s&state=%s获得Token的URL：https://github.com/login/oauth/access_token?client_id=%s&client_secret=%s&code=%s&redirect_uri=%s&state=%s获得用户信息的URL：https://api.github.com/user?access_token=%s3、设计数据库设计一个数据表用于存放用户的认证记录，用于认证之后就将他的认证信息存放到这个表中，并和主用户表（User）绑定。之后Mapper（DAO）、Service层自己按照自己业务逻辑自行实现，准备好有关接口等待Controller的调用。4、放置GitHub登录按钮点击GitHub登录之后的授权页面：5、后台代码具体实现①首先在SpringBoot配置文件配置如下信息：②之后写一个配置类用于获取这些文件中的这些信息③为了提高系统的扩展性，比如以后还可以做个QQ登录、微信登录.....，因此这里提供一个接口用于认证服务GitHub认证授权实现类：④GitHub认证控制器（Controller）GitHub返回的用户信息中的id在GitHub上是一个唯一的Id，这个可以作为用户是否在使用GitHub在系统登录过的依据。好了，这里我们的Github授权登录功能就算完成了。哪里有不清楚的地方可以在评论区留言。

SpringBoot—WebMvcConfigurer详解

1.简介WebMvcConfigurer配置类其实是Spring内部的一种配置方式，采用JavaBean的形式来代替传统的xml配置文件形式进行针对框架个性化定制，可以自定义一些Handler，Interceptor，ViewResolver，MessageConverter。基于java-based方式的springmvc配置，需要创建一个配置类并实现WebMvcConfigurer接口；在SpringBoot1.5版本都是靠重写WebMvcConfigurerAdapter的方法来添加自定义拦截器，消息转换器等。SpringBoot2.0后，该类被标记为@Deprecated（弃用），官方推荐直接实现WebMvcConfigurer或者直接继承WebMvcConfigurationSupport，方式一实现WebMvcConfigurer接口（推荐），方式二继承WebMvcConfigurationSupport类2.WebMvcConfigurer接口常用方法：2.1addInterceptors：拦截器addInterceptor：需要一个实现HandlerInterceptor接口的拦截器实例addPathPatterns：用于设置拦截器的过滤路径规则；addPathPatterns("/**")对所有请求都拦截excludePathPatterns：用于设置不需要拦截的过滤规则拦截器主要用途：进行用户登录状态的拦截，日志的拦截等。下面是一个配置示例：2.2addViewControllers：页面跳转以前使用Servlet的时候，如果需要访问一个页面，必须要写Servlet类，然后再写一个方法跳转到页面，感觉好麻烦，后来有了SpringMVC我们就可以在xml配置文件中配置视图的直接映射view-controller命名空间：来避免这些方法。再后来有了SpringBoot，我们可以可以重写WebMvcConfigurer中的addViewControllers方法即可达到效果了：值的指出的是，在这里重写addViewControllers方法，并不会覆盖WebMvcAutoConfiguration（Springboot自动配置）中的addViewControllers（在此方法中，SpringBoot将“/”映射至index.html），这也就意味着自己的配置和SpringBoot的自动配置同时有效，这也是我们推荐添加自己的MVC配置的方式。2.3addResourceHandlers：静态资源比如，我们想自定义静态资源映射目录的话，只需重写addResourceHandlers方法即可。注：如果继承WebMvcConfigurationSupport类实现配置时必须要重写该方法，具体见其它文章addResoureHandler：指的是对外暴露的访问路径addResourceLocations：指的是内部文件放置的目录2.4configureDefaultServletHandling：默认静态资源处理器此时会注册一个默认的Handler：DefaultServletHttpRequestHandler，这个Handler也是用来处理静态文件的，它会尝试映射/。当DispatcherServelt映射/时（/和/是有区别的），并且没有找到合适的Handler来处理请求时，就会交给DefaultServletHttpRequestHandler来处理。注意：这里的静态资源是放置在web根目录下，而非WEB-INF下。可能这里的描述有点不好懂（我自己也这么觉得），所以简单举个例子，例如：在webroot目录下有一个图片：1.png我们知道Servelt规范中web根目录（webroot）下的文件可以直接访问的，但是由于DispatcherServlet配置了映射路径是：/，它几乎把所有的请求都拦截了，从而导致1.png访问不到，这时注册一个DefaultServletHttpRequestHandler就可以解决这个问题。其实可以理解为DispatcherServlet破坏了Servlet的一个特性（根目录下的文件可以直接访问），DefaultServletHttpRequestHandler是帮助回归这个特性的。2.5configureViewResolvers：视图解析器这个方法是用来配置视图解析器的，该方法的参数ViewResolverRegistry是一个注册器，用来注册你想自定义的视图解析器等。2.6addCorsMappings：跨域2.7configureMessageConverters：信息转换器参考【1】zhangpower1993.SpringBoot---WebMvcConfigurer详解.CSDN【2】小仙.SpringBoot——》WebMvcConfigurerAdapter详解.CSDN

SpringBoot从入门到精通—Spring Boot 错误处理机制

1、SpringBoot默认错误处理机制（现象）        当我们使用SpringBoot发生错误的时候，如果我们没有配置错误的处理规则，那么SpringBoot就会启用内部的默认错误处理办法。比如当发生404错误的时候，网页端的效果如下：而在别的客户端访问的时候如果出现了404错误，默认会给客户端发送一串错误消息的JSON数据客户端的测试使用到了一个工具：Postman,感兴趣的小伙伴可以去Postman官网下载后来测试。2、SpringBoot默认错误处理机制（原理）        看到这些现象我们不禁会有疑问，SpringBoot的底层是如何生成不同错误的默认错误页面的？还有他是如何区分浏览器和其他客户端的？带着疑问我们继续往下看。        我们参照源码来分析一下（SpringBoot2.1.7版本），具体在ErrorMvcAutoConfiguration这个错误处理自动配置类,下面是在这个类中注册的几个重要的组件的源码：2.1ErrorMvcAutoConfiguration源码片段可以看到，ErrorMvcAutoConfiguration这个错误处理类中配置了几个重要的组件：*DefaultErrorAttributs：见名知意，这是SpringBoot定义的默认错误属性，他就是和错误信息的填充有关。*BasicErrorController：他是SpringBoot中默认处理/error请求的Controller*ErrorPageCustomizer：系统出现错误以后来到error请求进行处理*DefaultErrorViewResolver：默认的出现错误后的视图解析器继续跟踪源码（1）DefaultErrorAttributs源码片段（2）BasicErrorController源码片段首选通过判断媒体的类型来选择不同的错误处理方法，核心就是下面两个方法在BasicErrorController类的源码我们看到它调用了父类AbstractErrorControlle的方法resolveErrorView来处理ModelAndView，具体的实现细节如下：AbstractErrorController源码片段（3）ErrorPageCustomizer源码片段（4）DefaultErrorViewResolver源码片段        大致分析源码后可以总结SpringBoot对错误的处理流程如下：如果系统出现4xx或者5xx之类的错误，ErrorPageCustomizer就会生效（定制错误的响应规则），就会发出/error请求，然后就会被BasicErrorController处理并返回ModelAndView（网页）或者JSON（客户端）。3、使用SpringBoot默认错误处理机制来处理我们程序中的异常        通过分析源码我们可以发现，如果要使用SpringBoot默认的错误处理机制，我们可以把我们定制的错误页面放在/templates/error目录下的，交给模板引擎来处理；或者不使用模板引擎那就放在static/error目录下。并且给这些错误页面命名为错误码.html或4xx.html、5xx.html。SpringBoot就可以自动帮我们映射到错误页面。例如，处理404错误：在/templates/error目录下放404.html        访问浏览器，在地址栏中随便输入一个地址让他发生404错误，结果来到了我们定制的404错误页面，而不是SpringBoot默认的那个难看的白板页面。4xx.html测试结果：4、定制自己的错误信息默认情况下，SpringBoot的错误页面中可以可得一下错误信息：timestamp：时间戳status：状态码error：错误提示exception：异常对象message：异常消息errors：JSR303数据校验的错误都在这里4.1第一种方式：使用SpringMVC的异常处理器这样无论是浏览器还是别的客户端，只要出错了就全部返回的JSON数据。4.2第二种方式：转发到/error请求进行自适应效果处理4.3第三种方式：编写一个MyErrorAttributes继承DefaultErrorAttributes并重写其getErrorAttributes方法        前两种虽然都可以解决错误，但是当我们自己定义一个错误属性（比如上面的code属性）就没办法带到页面，因此我们设置的信息也就无法被带到页面显示。我们可以编写一个MyErrorAttributes继承自DefaultErrorAttributes重写其getErrorAttributes方法将我们的错误数据添加进去。最终的效果：响应是自适应的，以后可以通过定制ErrorAttributes改变需要返回的内容。

SpringBoot从入门到精通—Spring Boot 对静态文件的默认映射规则

1、Webjars(官网：http://www.webjars.org/)webjars：以jar包的方式引入静态资源；SpringBoot中所有/webjars/**，都去classpath:/META-INF/resources/webjars/找资源。推荐使用Webjars的三大理由：将静态资源版本化，更利于升级和维护。剥离静态资源，提高编译速度和打包效率。实现资源共享，有利于统一前端开发。1.1使用Webjars引入公共的静态资源使用Webjars在POM文件中很方便的引入静态资源文件，比如JQuery、Vue.js.....例如引入jquery和BootStrap，这样引入后，我们可以像管理Java依赖一样管理静态文件依赖。引入之后我们可以尝试访问一下BootStrap里面的东西，在地址栏输入localhost/webjars/bootstrap/4.0.0/webjars-requirejs.js2、引入自己的静态资源文件使用Webjars是好，但是没办法引入我们自己编写的静态资源文件。别急！SpringBoot开发者早已想到这个问题了，SpringBoot规定可以放在以下几个地方放置静态文件：3、给网页标签栏设置小图标SpringBoot支持给网页标签栏设置图标的功能，方法十分简单只需要将图标命名为favicon.ico，然后放在静态资源文件夹根目录下，SpringBoot在启动的时候就会扫描到并设置到网页中。在classpath:/public/放一个我自己的图标启动来看看效果：很nice！我们的小图标被用上了。4、使用spring.resources.static-locations改变静态资源文件夹位置在SpringBoot的主配置文件中，我们可以使用spring.resources.static-locations来指定静态资源文件的位置，可以指定多个，多个路径之间用","（逗号）隔开。需要注意的是，我们这么指定后，那些默认的资源文件夹就会失效。在resources下新建webapps文件夹，把静态资源放在里面。启动来看看效果：

SpringBoot从入门到精通—SpringBoot异步任务、定时服务和邮件服务

1、SpringBoot—异步任务    异步调用是相对于同步调用而言的，同步调用是指程序按预定顺序一步步执行，每一步必须等到上一步执行完后才能执行，异步调用则无需等待上一步程序执行完即可执行。    实现异步处理任务的方式有很多，我们可以自己通过多线程来实现或者也可以使用SpringBoot提供的@EableAysnc和@Aysnc这两个注解来实现。1.1通过多线程来实现异步处理任务直接在需要异步任务处理的方法中开启新的线程来处理任务。执行结果如下：1.2使用SpringBoot提供的注解处理异步任务首先在需要异步任务处理的方法上加上@Async注解告诉SpringBoot这个方法需要异步处理然后在主配置类使用@EnableAsync注解开启异步注解功能执行结果如下，SpringBoot也是开启了一个新的线程task-1来处理这个任务的：2、SpringBoot—定时任务定时任务就是提前设置好时间点，然后每到这个时间点就会执行的任务。SpringBoot中可以通过@Scheduled和@EableScheduled这两个注解来实现定时任务。同样在需要定时任务对方法上标注@Scheduled注解，然后在主配置类上标注@EableScheduled注解开启定时注解功能执行结果：从上面这个例子中可以看到，对于定时任务使用主要就是对cron表达式的编写，cron允许的值可以有以下几种：字段允许值允许的特殊字符秒0-59,-*/分0-59,-*/小时0-23,-*/日1-31,-*/?LWC月1-12,-*/星期0-7或SUN-STA,-*/?LWC#解释：,：表示枚举，可以用它在一个一段上枚举多个值—：表示一个区间*：表示任意/：步长？：日/星期冲突匹配L：最后W：工作日C：和Calendar联系后计算后的值#:星期，例如4#2表示第二个星期四下面是几个用法示例：3、SpringBoot—邮件任务    SpringEmail抽象的核心是MailSender接口，MailSender的实现能够把Email发送给邮件服务器，由邮件服务器实现邮件发送的功能。    Spring自带了一个MailSender的实现JavaMailSenderImpl，它会使用JavaMailAPI来发送Email。Spring或SpringBoot应用在发送Email之前，我们必须要JavaMailSenderImpl装配为Spring应用上下文的一个bean。3.1首先引入邮件服务的starter3.2邮件配置3.3简单邮件服务—SimpleMessage使用简单邮件服务只能发送文本消息执行的结果，成功收到了邮件：3.4复杂邮件服务—MimeMessage使用复杂邮件服务可以发送文本消息、HTML语句、甚至支持上传附件执行结果：在GMail收到了邮件，并且设置HTML样式起作用了，附件也上传成功了。

SpringBoot从入门到精通—Spring Boot + Eureka 实现微服务负载均衡

1、什么是Eureka？        Eureka这个单词原本的意思就是“我发现了，我找到了”，他在Spring中的功能也和他的本意是一样的。Eureka是netflix的一个子模块，也是核心模块之一，Eureka是一个基于RESTful的服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来说是非常重要的，有了服务发现和注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务，而不需要修改服务调用的配置文件了，功能类似于dubbo的注册中心，比如zookeeper。        SpringCloud封装了Netflix公司开发的Eureka模块来实现服务注册时和发现。        Eureka采用了C/S设计架构。EurekaServer作为服务注册功能的服务器，它是服务注册时中心。而系统中的其他微服务，使用eureka的客户端连接到eurekaserver并维持心跳连接。这样系统的维护人员就可以通过eurekaserver来监控系统中各个微服务是否正常运行。SpringCloud的一些其他模块就可以通过eurekaserver来发现系统中的其他微服务，并执行相关的逻辑。        Eureka包含两个组件：EurekaServer和EurekaClient。        EurekaServer提供服务注册服务。各个节点启动后，会在EurekaServer中进行注册，这样Eurekaserver中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。        Eurekaclient是一个Java客户端，用于简化eurekaserver的交互，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后，将会向EurekaServer发送心跳。如果EurekaServer在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表把这个服务节点移除。Eureka的三大角色：1.Eurekaserver提供服务注册和发现2.ServiceProvider服务提供方将自身服务注册到Eureka，从而使服务消费方能够找到。3.ServiceConsumer服务消费方从Eureka获取注册服务列表，从而能够消费服务。总结起来就是说1.Eureka是Netflix开源的一个RESTful服务，主要用于服务的注册和发现。2.Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。3.Eureka客户端是一个Java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。4.Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。2、搭建一个基于SpringBoot+Eureka的微服务工程工程的搭建我使用IDEA，首先新建一个空工程【Emptyproject】,选择空工程点击【next】，之后我们需要在这个工程中建立三个子模块，分别是euraka-server注册中心，poervider服务提供者，customer消费者。新建一个空工程在新建项目的时候我们可以使用【SpringInitializr】，在新建eurake-server模块的时候选上EurekaServer，新建provider和customer模块的时候可以选上Web的satrter和EurakeDiscoveryClient的satrter建好后的项目结构：3、EurekaServer—注册中心的配置在EurekaServer的启动类上使用@EnableEurekaServer开启Eureka服务配置好后启动enureka-server，它将会在配置的端口8761启动，输入http://localhost:8761就可一个看到enureka-server的管理界面：4、ServiceProvider—服务提供方的配置在服务提供方的配置文件中配置如下信息：实现一个服务，TicketServiceEureka的底层还是基于HTTP协议的，在消费者端要调用服务提供方的服务时，实际是通过HTTP请求的方式来调用的，因此需要在服务提供方给对应的service提供对应的controller。TicketController如下：最后在服务提供方的启动类上使用@EnableEurekaClient来告诉Spring这是Eureka的Cilent端，这个服务要注册到注册中心上去。（也可以使用@EnableDiscoveryClient注解，这两个注解的作用是相同的，但是还是有差别的，具体的可以参考@EnableDiscoveryClient与@EnableEurekaClient区别）。配置完成后启动ServerProvider（注意在启动Client端的服务时EurekaServer要保持运行），启动后可以正常访问http://localhost:8080/ticket,并且在注册中心可以看到8080端口的PROVIDER实例已经注册了就算是成功了。我们可以开启多个服务提供方，方法是把当前的provider使用Maven命令(mvninstall)打包成可执行jar包，然后在把server.port改成另一个端口再使用Maven命令打包后运行...下面是我启动了两个provider，分别在8080和8081端口5、ServiceCustomer—服务消费方的配置在服务消费方的配置文件中配置如下内容：在服务消费方的启动类上使用@EnableDiscoveryClient注解告诉SpringBoot把这个服务注册到注册中心。并且注册RestTemplate到IoC容器中，可以使用他来远程调用服务提供方的服务。编写一个controller使用RestTemplate来调用服务提供方的注册在服务中心的服务。最后启动服务消费方看看效果吧！首先我们可以访问http://localhost:8761/，可以在注册中心看到消费方也在注册中心注册了：我们接着访问http://localhost:8020/buy?name=李四&num=6就可以看到下面的页面：微服务负载均衡的体现把另一个打包的可执行jar包在命令行使用java-jar命令运行，注意不要让端口冲突。让两个服务提供方同时运行，然后我们访问http://localhost:8020/buy?name=李四&num=6，不断改变num的值查看控制台的打印发现这两个端口的服务是轮流工作的，从而达到了一个负载均衡的作用。

SpringBoot从入门到精通—自定义starter

SpringBoot中提供了各种starter，starter可以理解为一个可拔插式的插件，当我们要使用的时候只用导入需要的starter即可。例如：你想使用jdbc插件，那么可以使用spring-boot-starter-jdbc；如果想使用mongodb，可以使用spring-boot-starter-data-mongodb。但是当我们需要的场景没有的时候我们可以来定制starter。首先在IDEA中创建一个maven工程，在其中创建两个Model，一个是hello-spring-boot-starter,另一个是hello-spring-boot-starter-configurer，目结构如下：要特别注意artifactId的命名规则：Spring官方starter通常命名为spring-boot-starter-{name},如spring-boot-starter-webSpring官方建议非官方Starter命名应遵循{name}-spring-boot-starter的格式,如mybatis-spring-boot-starter。一般我们不会直接在starter中写配置，starter一般只一个空项目，然后主要的配置写在这个starter对应的autoconfigurer中，让starer依赖configurer就可以了。1、在starter中引入对应的configurer依赖starter一般是一个空模块，真正的实现放在configurer中，让starter依赖configurer，以后需要使用这个模块的时候只用引入starter就可以引入它所依赖的configurer。2、在hello-spring-boot-starter-configurer模块中写我们需要的配置2.1XxxPrperoties2.2核心业务类2.3自动配置类XxxAutoConfigurer2.4spring.factories然后需要在hello-spring-boot-starter-configurer的src/main/resources文件夹下新建META-INF文件夹然后新建spring.factories文件,配置这个类让他可以自动启动。2.5打包mvncleaninstall使用Maven命令mvncleaninstall或直接使用IDEA提供的Maven插件执行install命令把我们的这个starter安装到本地Maven仓库。注意：如果提示没有找到pom文件的错误，那就使用命令行找到对应的项目执行Maven命令测试一下之后我们再新建一个普通的SpringBoot项目，引入我们自定义的starter引入后的效果：写一个controller来测试一下我们的starter是否有效可以在主配置文件中配置UserProperties中的属性（不配置将会使用默认值）启动运行看看效果：

SpringBoot从入门到经通过—Spring —Cache

1、JSR-107规范1.1JSP-107是什么？        要回答这个问题，首先要知道JSR是什么，JSR是JavaSpecificationRequests的缩写，Java规范请求，故名思议就是Java规范，大家一同遵守这个规范的话，会让大家‘沟通’起来更加轻松。规范是很重要的，举个例子大家都知道红灯停，路灯行吧，如果每个城市的信号灯代表不一样，那就麻烦了，B城市红灯行，绿灯停，C城市甚至出现紫灯行，闪灯行，想想都知道，如果我们保证不出问题，必须知道每个城市的信号等代表的意义。我们一直使用的JDBC就一个访问数据库的一个规范的例子。而JSR-107呢就是关于如何使用缓存的规范。1.2JSR-107核心APIJavaCaching定义了5个核心接口，分别是CachingProvider,CacheManager,Cache,Entry和Expiry。CachingProvider用于定义创建、配置、获取、管理和控制Cachemanager。CacheManager用于定义了建立，配置，得到，管理和控制有着唯一名字的Cache，一个CacheManager被包含在单一的CachingProvider。CacheCache是一个Map类型的数据结构，用来存储基于键的数据，很多方面都像java.util.Map数据类型。一个Cache存在在单一的CacheManager。EntryEntry是一个存在于Cache的key-value键值对Expiry每一个存储在Cache中的条目有一个定义的有效期。一旦超过这个时间，条目为过期的状态。一旦过期，条目将不可访问、更新和删除。缓存有效期可以通过ExpiryPolicy来设置。这些接口之间的关系可以用下图表示：2、Spring缓存抽象Spring3.1从开始定义了org.springframework.cache.Cache和org.springframework.cache.CacheManager接口来统一不同的缓存技术，并使用JCache(JSR-107)注解简化我们的开发。Cache接口为缓存的组件规范定义，包含缓存的各种操作集合Cache接口下Spring提供了各种xxxCache的实现，如RedisCache、EncheCache、ConcurrentMapCache......每次调用需要缓存功能的方法是，Spring会检查指定的参数的是定目标方法时候已经被调用过，如果有就直接从缓存中获取方法调用后对结果，如果没有就调用方法去数据库查询并缓存结果后返回给用户，下次回直接从缓存中获取。重要的缓存注解注解功能Cache缓存接口，定义缓存操作。CacheManager缓存管理器。管理和中缓存组件@Cacheable主要用于方法，能够根据方法的请求参数对其进行缓存@CachePut方法被调用，并且在调用后结果被缓存，主要用于更新操作@CacheEvict清除缓存@Caching配置复杂对缓存策略@CacheConfig同一配置本类的缓存注解额属性@EnableCaching开启基于注解的缓存serialize缓存数据的value序列haul策略@Cacheable/@CachePut/@CacheEvict主要的参数参数解释value/cacheNames缓存的名字。必须指定至少一个，可以配置多个例如：@Cacheable(value={"cache1","cache2"})key缓存的key。可以为空，如果指定要使用SpEL。默认将方法的所有参数组合起来作为key。例如：@Cacheable(value="cache1",key="#id")keyGenerator定义自动生成主键的策略，使用的时候key和keyGenerator二选一condition作缓存的条件。可以为空，使用SpEL表达式指定，返回true表示作缓存，否者不缓存。例如：@Cacheable(vlaue="cache",condition="#id>0")unless也是作缓存的条件。当条件为true时，就不缓存（和condition的效果是反的）。例如：@Cacheable(value="cache",unless="#idsync(@Cacheable)是否使用异步支持，这是Spring4.3以后才支持的,默认值false，不开启异步模式例如：@Cacheable(value="cache",sync=true)//开启异步模式allEntries(@CacheEvict)是否清空所有缓存内容。默认为false,如果指定为true，则方法调用后将立即清空所有缓存。beforeInvocation(@CacheEvict)是否在方法执行前清空缓存。默认为false，如果指定为true,则方法还没有执行的时候就清空缓存。默认情况下如果方法抛出异常，就没有办法清空缓存了。SpEL上下文数据，Spring提供了一些供我们使用的SpEL表达式，名称位置描述用法示例methodName(方法名)root对象当前被调用的方法名#root.methodnamemethod(方法)root对象当前被调用的方法#root.method.nametarget(当前对象)root对象当前被调用的目标对象实例#root.targettargetClass(目标类)root对象当前被调用的目标对象的类#root.targetClassargs(参数列表)root对象当前被调用的方法的参数列表#root.args[0]caches(缓存列表)root对象当前方法调用使用的缓存列表#root.caches[0].nameArgumentName(参数名)执行上下文当前被调用的方法的参数，如findArtisan(Artisanartisan),可以通过#artsian.id获得参数#artsian.idresult(方法返回值)执行上下文方法执行后的返回值（仅当方法执行后的判断有效，如unlesscacheEvict的beforeInvocation=false）#result3、Spring缓存的配置和使用3.1@Cacheable@Cacheable注解会先查询是否已经有缓存，有会使用缓存，没有则会执行方法并缓存。在CacheAspectSupport这个类的findCachedItem上打上断点，观察发下我们配置的key是有效：3.2自定义主键生成策略在方法中可以这么使用：同样，通过打断点发现我们配置的主键生成也起作用了：其他参数的用法可以参考下面的程序：3.3@CachePut@CachePut注解的作用主要用于对方法配置，能够根据方法的请求参数对其结果进行缓存，和@Cacheable不同的是，它每次都会触发真实方法的调用。简单来说就是用户更新缓存数据。但需要注意的是该注解的value和key必须与要更新的缓存相同，也就是与@Cacheable相同。@CachePut的其他参数的用法和一样@Cacheable参数的用法一样。这里不再赘述。3.4@CacheEvict@CachEvict的作用主要用于方法的配置，能够根据一定的条件对缓存进行清空。3.5@Caching有时候我们可能组合多个Cache注解使用，此时就需要@Caching组合多个注解标签了。3.6@CachingConfig当我们需要缓存的地方越来越多，你可以使用@CacheConfig(cacheNames={"cacheName"})注解来统一指定value/cacheNames的值，这时可省略value/cacheNames，如果你在你的方法依旧写上了value/cacheNames，那么依然以方法的@CacheConfig配置的值为准。使用方法如下：@CacheConfig可以配置单的属性如下：

Spring从入门到精通—自动配置Spring MVC的原理

1、SpringMVC自动配置SpringBoot对SpringMVC自动配置的详细可以参考管方文档。SpringBoot为SpringMVC提供的AutoConfiguration适用于大多数应用场景，SpringBoot对SpringMVC做了以下默认的自动配置：引入ContentNegotiatingViewResolver和BeanNameViewResolver。对静态资源的支持，包括对WebJars的支持自动注册Converter，GenericConverter，Formatter。对HttpMessageConverters的支持。自动注册MessageCodeResolver。对静态资源的支持对自定义Favicon的支持自动使用ConfigurableWebBindingInitializerbean。SpringBoot默认情况下是自动配置好SpringMVC的，可以直接使用，但是SpringBoot也支持我们修改SpringBoot对SpringMVC的配置。如果保留SpringBootMVC特性，我们只需添加其他的MVC配置（拦截器，格式化处理器，视图控制器等）。我们可以添加自己的WebMvcConfigurerAdapter类型的@Configuration类（配置类），而不需要注解@EnableWebMvc。如果希望使用自定义的RequestMappingHandlerMapping，RequestMappingHandlerAdapter，或ExceptionHandlerExceptionResolver，我们可以声明一个WebMvcRegistrationsAdapter实例提供这些组件。但是如果想全面控制SpringMVC，我们可以添加自己的@Configuration类，并使用@EnableWebMvc注解。这样SpringBoot就不会对MVC进行配置了。然后我们就可以像刚开始使用SpringMVC那样对他进行配置。2、SpringMVC自动配置原理细节SpringBoot对SpringMVC的自动配置主要是通过WebMvcAutoConfiguration这个类实现的，接下来我们就结合这个类来简单分析一下自动配置的细节。2.1ContentNegotiatingViewResolver和BeanNameViewResolver这两个一听名字就知道是和视图解析器有关，也确实是这样的，他们自动配置了ViewReslover，然后由ViewReslover得到View对象，View对象调用他的render方法渲染页面等等。其中BeanNameViewResolver就是SpringMVC中的一个视图解析器，他可以通过视图名来获得视图解析器，而ContentNegotiatingViewResolver的作用就是组合所有的视图解析器，下面他们的源码：问题：ContentNegotiatingViewResolver是如何组合所有视图解析器的因此，我们可以实现自己的视图解析器，然后ContentNegotiatingViewResolver把它注册到容器中。定制自己的视图解析器，我们可以在启动类中实现ViewResolver接口，编写我们自己的视图解析器，然使用@Bean标签配置给IOC容器。3、Converter，GenericConverter，Formatter这些功能在SpringBoot中也有默认的自动配置，这里我们要了解的是如何扩展配置Converter和Formatter。源码：我们也可以定制自己的转换器4、HttpMessageConvertersSpringMVC使用HttpMessageConverter接口转换HTTP请求和响应，合适的默认配置可以开箱即用，例如对象自动转换为JSON（使用Jackson库）或XML（如果JacksonXML扩展可用，否则使用JAXB），字符串默认使用UTF-8编码。可以使用SpringBoot的HttpMessageConverters类添加或自定义转换类：5、扩展SpringBoot对SpringMVC的配置想要扩展SpringBoot的MVC功能，我们要WebMvcConfigurer接口，但是这样太麻烦了，因此SpringBoot提供了一个适配器类WebMvcConfigurerAdapter，它里面全部是一些空方法，我们可以继承WebMvcConfigurerAdapter类，然后我们只需要按照我们的需要重写里面的方法就好了。6、全面接管SpringBoot对SpringMVC的自动配置官网中的一句话：IfyouwanttotakecompletecontrolofSpringMVC,youcanaddyourown@Configurationannotatedwith@EnableWebMvc.意思就是我们可以配置类上加上EnableWebMvc来全面接管SpringMVC，这样一来SpringBoot就不会对SpringMVC进行配置了，一切都需要我们来配置。

SpringBoot从入门到精通—MyBatis的配置和使用（注解+XML配置）

关于MyBatis，大部分人都很熟悉。MyBatis是一款优秀的持久层框架，它支持定制化SQL、存储过程以及高级映射。这篇文章主要介绍了SpringBoot集成MyBatis的两种方式（注解和XML文件配置）,需要的朋友可以参考下.1、使用XML配置MyBatis1.1在pom.xml文件中引入MyBatis的依赖1.2编写MyBatis的主配置文件Mybatis-config.xml在src/main/resources目录下新建mybatis文件夹，然后新建Mybatis-config.xml文件并配置如下：1.3编写Mapper接口以及对应的Mapper映射文件在src/main/java下新建mapper包，然后新建ArticleMapper接口如下：在src/main.resoures下新建mapper文件夹，然后在mapper文件夹中新建对应的Mapper映射文件ArticleMapper.xml如下：然后在application.yml文件中配置mybatis这两个文件的位置：编写一个controller，简单测试一下看看我们配置的MyBatis能不能用。这里为了简单就没有写对应的service。测试结果：2、使用注解配置MyBatisMyBatis提供了以下几个CRUD基本注解：*@Select*@Update*@Insert*@Delete增删改查占据了绝大部分的业务操作，掌握这些基础注解的使用还是很有必要的，例如下面这段代码无需XML即可完成数据查询：MyBatis提供的映射注解：@Results用于填写结果集的多个字段的映射关系.@Result用于填写结果集的单个字段的映射关系.@ResultMap根据ID关联XML里面.在启动类上使用@MapperScan扫描mapper包下的所有的Mapper接口，这样做的好处是可以省去在每个Mapper接口上写@Mapper注解。还可以写一个配置类彻底取代MyBatis的所有XML文件。MyBatisConfig.java编写一个controller，看看实际的效果：测试结果：

SpringBoot从入门到精通—SpringBoot启动流程剖析

       上图为SpringBoot启动结构图，我们发现启动流程主要分为三个部分，第一部分进行SpringApplication的初始化模块，配置一些基本的环境变量、资源、构造器、监听器，第二部分实现了应用具体的启动方案，包括启动流程的监听模块、加载配置环境模块、及核心的创建上下文环境模块，第三部分是自动化配置模块，该模块作为springboot自动配置核心，在后面的分析中会详细讨论。在下面的启动程序中我们会串联起结构中的主要功能。1、基于源码简单剖析SpringBoot的启动流程Springboot的启动过程：SpringBoot应用启动后首先执行SpringBoot启动类的main方法中的publicstaticConfigurableApplicationContextrun(Class<?>primarySource,String...args)这个run方法，他又调用了重载方法的publicstaticConfigurableApplicationContextrun(Class<?>[]primarySources,String[]args)，在这个run方法中调用了真正的run方法。他们的调用关系如下图：在调用正真干活的run方法之前，SpringAppication先进行了初始化：最终真正干活的run方法该方法中有几个关键的步骤：（1）创建了应用监听器SpringApplicationRunListeners并开始监听（2）加载SpringBoot配置环境ConfigurableEnvironment，如果是通过web容器发布，会加载StandardEnvironment，其最终也是继承了ConfigurableEnvironment，类图如下：（3）将从配置文件中加载进来的配置环境（Enviroment）加入到监听器中（4）创建应用配置上下文对象ConfigurableApplicationContext，我们可以到其具体的实现中看看：（5）回到run方法继续往下走，prepareContext()方法将listeners、environment、applicationArguments、banner等组件与上下文对象关联（6）调用refreshContext()方法是SpringBoot启动中最重要的一步，包括spring.factories的加载，bean的实例化等核心工作。这一步完成后SpringBoot的启动工作基本就完成了。下面是最终真正干活的refresh()方法的截图：方法首先获取显式获取并设置了应用上下文(applicationContextClass)，如果不存在，再根据不同的Web环境选择实例化不同的上下文对象，默认选择AnnotationConfigApplicationContext注解上下文（通过扫描所有注解类来加载bean），最后通过BeanUtils实例化上下文对象，并返回。配置结束后，Springboot做了一些基本的收尾工作，返回了应用环境上下文。回顾整体流程，Springboot的启动，主要创建了配置环境(environment)、事件监听(listeners)、应用上下文(applicationContext)，并基于以上条件，在容器中开始实例化我们需要的Bean，至此，通过SpringBoot启动的程序已经构造完成。启动过程中的一些细节代码说明:（1）在run方法一开始执行他就new了一个StopWatch，这个类有啥用呢？开启单步调试，最终发现这个类的功能就是统计一下SpringBoot启动所用的时间并在最会在启动完成打印出来。（2）在启动中有一个Banner，他的用处就是打印一下SpringBoot的logo

SpringBoot从入门到精通—嵌入式Servlet容器的配置、切换

声明：以下的所有方法、原理、源码全部是建立在SpringBoot2.1.7版本。1、修改SpringBoot对嵌入式Server容器的默认配置SpringBoot默认使用Tomcat作为嵌入式的Servlet容器。实际应用中我们需要对他进行专门的定制。定制的方式不外乎两种：在配置文件中配置或在配置类中注册组件的方式配置1.1直接在application.properties/application.xml文件中配置和server有关的属性配置方式是server.属性名=值，下面是ServerProperties类中定义的绝大多数可以配置的属性配置示例：1.2向IoC容器中添加servlet容器工厂定制器WebServerFactoryCustomizer运行结果：如果使用的是SpringBoot1.x版本可以参考下面的方法来使用配置1.3向IoC容器中添加可配置的servlet容器工厂ConfigurableServletWebServerFactory运行自然是没有什么问题，在地址栏输入http://localhost:8089/springboot/也来到了目标页面：1.4在SpringBoot中注册Servlet三大组件【Servlet、Filter、Listener以前注册这些组件都是在web.xml中配置，由于SpringBoot默认是以jar包的方式启动嵌入式的Servlet容器来启动SpringBoot的web应用，没有web.xml文件。注册三大组件用以下方式：①、借助ServletRegistrationBean注册自定义Servlet组件；自定义【MyServlet】：定义【ServletRegistrationBean】并放入容器中：②、借助FilterRegistrationBean注册自定义Filter组件；(自定义的MyFilter忽略)③、借助ServletListenerRegistrationBean注册自定义Listener组件；(自定义的MyListener忽略)2、嵌入式Servlet容器切换2.1三大容器比较容器优点缺点默认tomcat功能齐全庞大，荣泽truejetty轻量功能不全falseundertow异步，高效不支持jspfalse2.2容器切换TomcatSpringBoot引入web模块默认就是使用嵌入式的Tomcat作为Servlet容器。`Jettyundertow3、嵌入式Servlet容器自动配置原理主要看三个类：*ServletWebServerFactoryConfiguration*ServletWebServerFactoryAutoConfiguration*ServletWebServerFactoryCustomizer3.1ServletWebServerFactoryConfiguration有三个：EmbeddedUndertow，EmbeddedJetty，EmbeddedTomcat@Conditionalxxx标注的类；条件满足才向容器中添加组件。ServletWebServerFactory：嵌入式Servlet工厂。作用：创建嵌入式Servlet容器在判断@ConditionalOnClass({Servlet.class,Tomcat.class,UpgradeProtocol.class})是否导入依赖，满足条件后returnnewTomcatServletWebServerFactory();添加对应的Servlet容器工厂；通过工厂的唯一方法getWebServer获取对应的Servlet容器TomcatServer.TomcatServletWebServerFactoryTomcatWebServer3.2ServletWebServerFactoryAutoConfiguration修改定制Servlet容器的方法:   1、配置文件中添加配置。   2、ServerProperties绑定/修改定制组件WebServerFactoryCustomizer他们的本质是一样的：在ServletWebServerFactoryAutoConfiguration配置类中@EnableConfigurationProperties({ServerProperties.class})。导入了BeanPostProcessorsRegistrar，在这个类的方法中添加了组件WebServerFactoryCustomizerBeanPostProcessor(定制器后置处理器)。也就是说一旦容器中添加任何组件都会启动定制后置处理器，进行Servlet的赋值。后置处理器起作用的过程：3.3ServletWebServerFactoryCustomizer在这个配置类中使用customize(ConfigurableServletWebServerFactoryfactory)这个方法完成了Tomcat的各项配置的修改和定制总结配置修改定制原理：以tomcat为例总结配置修改定制原理：以tomcat为例1、SpringBoot根据根据导入依赖的情况，给容器中添加相应的ServletWebServerFactory（比如tomcat就会添加TomcatServletWebServerFactory）2、如果使用的是通过application.propertoes修改配置，那么server相关的配置修改是与ServerProperties类绑定的，所以相关的修改会直接通过Serverproperties的方法实现【相关的配置类：ServletWebServerFactoryCustomizer】3、如果使用的是修改定制器WebServerFactoryCustomizer的方法来配置server，那么定制器会创建ConfigurableWebServerFactory对象，这样一来就会触发WebServerFactoryCustomizerBeanPostProcessor后置处理器，判断是否为WebServerFactory类型；满足条件后，就会获取容器中的所有定制器（customizer.cutomize(bean)），为Servlet容器修改和定制配置【相关的配置类ServletWebServerFactoryAutoConfiguration，导入了定制处理器】

SpringBoot从入门到精通—整合Druid数据源

java实现的数据库连接池有很多，比如c3p0,dbcp等，还有号称速度最快的HikariCP，并且springboot2.0.2版本默认使用的就是HikariCP。为什么选用Druid呢？-性能够好，比c3p0,dbcp强一些-经过考验，毕竟是阿里开源出来的项目-最关键的是带一个强大的数据库监控这些特性的加持下足以支撑起我使用Druid的理由。1、Druid能监控那些数据数据源SQL监控，对执行的MySQL语句进行记录，并记录执行时间、事务次数等SQL防火墙，对SQL进行预编译，并统计该条SQL的数据指标Web应用，对发布的服务进行监控，统计访问次数，并发数等全局信息URI监控，对访问的URI进行统计，记录次数，并发数，执行jdbc数等Session监控，对用户请求后保存在服务器端的session进行记录，识别出每个用户访问了多少次数据库等Spring监控，（按需配置）利用aop对各个内容接口的执行时间、jdbc数进行记录2、如何配置使用Druid想达到的目标效果，监控sql，监控sql防火墙，监控url，监控session，监控spring其中监控sql、监控url、基础信息，几乎不怎么需要配置，集成好druid，配置好监控页面，就可以显示。需要我们配置的大概分为3部分，基础连接池配置，基础监控配置，定制化监控配置2.1引入Druid的依赖2.2连接池基础配置主要配置用户名，密码，数据库驱动、数据库连接.....以及和连接池有关的配置2.3导入Druid数据源的其他属性上面的配置文件中和数据库连接池有关的配置属性在SpringBoot是没有的，因此我们需要告诉SpringBoot，让他在启动的时候去找加载这些属性，因此我们需要写一个配置类。没有写配置类之前的效果：写一个配置类写配置类后的效果，配置类起作用了：2.4配置Durid监控主要就是配置一个后台管理的Servlet—StarViewServlet和Web监控过滤器—WebStatFilter。具体有哪些初始化参数可以设置，可以参考这两个类以及他们的父类，都是以常量的方式出现的，配置的时候配置他们的值就可以了。写一个controller启动看看效果：启动后在浏览器地址栏输入localhost:8080/query，执行一次请求启动后在浏览器地址栏输入localhost:8080/druid，可以看到Druid后台管理的登录界面输入刚刚设置的用户名个密码，来到后台管理页面，点击SQL监控就可以看到刚才执行的SQL被记录了。其实主打开箱即用的SpringBoot，对于上面Druid监控的配置其实我们还可以直接在SpringBoot的配置文件中配置，下面是关于Druid监控的配置示例：

SpringBoot从入门到精通—Thymeleaf模板引擎快速上手

1、引言        在做WEB开发的时候，我们不可避免的要在前端页面之间进行跳转，中间进行数据的查询等等操作。我们在使用SpringBoot之前包括我在内其实大部分都是用的是JSP页面，可以说使用的已经很熟悉。但是我们在使用SpringBoot开发框架以后我们会发现一个致命的问题，就是SpringBoot对Jsp的支持可以说是惨不忍睹，因此官方推荐我们使用Thymeleaf模板引擎来解决问题。目前而言，当然模板引擎有很多，比如Velocity、Freemarker、等等，但是我这一直感觉thymeleaf相对于其他的来说好用的还是不少的。在这里我们就来了解一下thymeleaf这个模板引擎的用法！2、什么是模板引擎？        模板引擎是为了使用户界面与业务数据（内容）分离而产生的，它可以生成特定格式的文档。用于网站的模板引擎（比如Thymeleaf模板引擎）就是将模板文件和数据通过模板引擎生成一个HTML文本。        简单说，通过使用模板引擎，可以将后端的数据填充到前端写好的页面模板中，作用类似JSP。和Thymeleaf类似的模板引擎还有Velocity、FreeMarker，它们完全可以替代JSP。3、SpringBoot中使用Thymeleaf模板引擎SpringBoot中提供了对模板引擎的支持，并且SpringBoot也建议我们使用模板引擎，常用的Thymeleaf使用的方法很简单，首先在pom.xml文件中引入thymeleaf的starter3.1引入Thymeleaf模板引擎的POM依赖        一般SpringBoot引入的都是依赖文件的最新的版本，如果发现不是最新的依赖版本或者你想更改依赖的版本，可以在<properties>标签中修改，比如修改thymeleaf的版本为3.0.10版本3.2使用Thymeleaf        引入Thymeleaf的依赖后，我们就可以使用了。在学习SpringBoot时无论是啥新东西，我们都可以打开XxxxAutoConfigration和XxxxProperties，从中我们可以基本了解SpringBoot对这个东西的默认配置。好了我们来看看Thymeleaf的配置类当然，我们也可以在SpringBoot的主配置文件中进行thymeleaf相关配置：#thymeleaf有关设置spring.thymeleaf.prefix=classpath:/templatesspring.thymeleaf.suffix=.htmlspring.thymeleaf.mode=HTML5spring.thymeleaf.encoding=UTF-8spring.thymeleaf.servlet.content-type=text/html#关闭模板缓存，避免更新无效spring.thymeleaf.cache=false（1）在控制层写一个跳转到hello.html页面的处理器方法（2）在html页面中导入thymeleaf名称空间，名称空间的导入不是必须的，但是导入后可以有提示，提示还是挺好用的。（3）.然后在页面只用Thymeleaf语法获取服务器响应的数据测试结果：4、Thymeleaf模板引擎的基本语法4.1Thymeleaf常用属性下面列举一些Thymeleaf常用的属性，全部的属性还请参考Thymeleaf官方手册。Thymeleaf的属性都有一个优先级，优先级从1~8，数字越低优先级越高就会被先执行。（以下用order表示优先级大小）1、th:text：设置当前元素的文本内容，相同功能的还用th:utext,两者的区别是前者会转义特殊字符，后者不会。order=72、th:value：设置当前元素的value值，类似修改指定属性的还有th:src，th:herf,优先级order=63、th:each：遍历循环元素，和th:value或th:value一起使用。order=24、th:if：条件判断，类似的还有th:unless,th:switch,th:case。order=35、th:insert：代码块引入，类似的还有th:replaceth:include，三者的区别较大，若使用不恰当会破坏html结构，常用于公共代码块提取的场景。优先级最高：order=16、th:fragment：定义代码块，方便被th:insert引用。优先级最低：order=87、th:object：声明变量，一般和*{}一起配合使用，达到偷懒的效果。优先级一般：order=48、th:attr：修改任意属性，实际开发中用的较少，因为有丰富的其他th属性帮忙，类似的还有th:attrappend，th:attrprepend。优先级一般：order=5除了这些Thymeleaf定义的一些属性外，在HTML中所有的结点属性都可以使用th:属性名=值的方式来动态设定值，具体使用方法参考下面的例子。4.2Thymeleaf标准表达式语法${.....}变量表达式（VariableExpressions）#{.....}消息表达式（MessageExpressions）@{.....}链接表达式（LinkURLExpressions）~{.....}代码块表达式（FragmentExpressions）*{.....}选择变量表达式（SelectionVariableExpressions）1、${}变量表达式Thymeleaf的变量表达式使用的其实是OGNL表达式，变量表达式的功能非常丰富。(1)可以获取对象的属性、调用方法等(OGNL可以做的事他都可以做)(2)可以使用内置对象。官方手册上给的可以使用的内置对象如下:(3)可以使用一些内置的工具对象(方法)2、*{}选择表达式对于变量我们还可以使用*{}来处理，它和${}在功能上是一样的。但是有一个重要的区别：*{}评估所选对象上的表达式而不是整个上下文。也就是说，只要没有选定的对象，${}和*{}语法就会完全相同。下面是官网给的一个例子，可以说明这个问题：3、#{}消息表达式：主要用于处理资源国际化的。4、@{}链接表达式Thymeleaf中专门用于定义超链接的表达式。配合Thymeleaf中的th:href属性一起使用链接表达式@{}基本用法：链接表达式@{}高级用法：动态拼接URL请求路径：比如要拼接一个如下的动态路径：127.0.0.1/article/index/{id}?articleType=xxx&page=xxx，其中id是项目中每篇文章的id，articleType是文章的类型，page是控制分页的参数，现在要在页面提供这么一个连接来实现分页。实现结果：5、~{}代码块表达式Thymeleaf中专门用于引用片段的表达式。经常配合th:insert和th:replace属性使用，例如：合理的使用代码块表达式可以极大的减少我们项目中的冗余代码，尤其是页面中的冗余代码。我们可以把几个页面中公共使用的代码抽象成一个片段,然后在页面需要的位置引入代码块即可，而且更厉害的是Thymeleaf可以把页面的的head部分或者是JS脚本部分抽取出来统一管理，这样当我们项目发生改变的时候只用改一处就可以了。

SpringBoot从入门到精通—自动配置原理（深入源码）

1、引言不论在工作中，亦或是求职面试，SpringBoot已经成为我们必知必会的技能项。除了某些老旧的政府项目或金融项目持有观望态度外，如今的各行各业都在飞速的拥抱这个已经不是很新的Spring启动框架。当然，作为SpringBoot的精髓，自动配置原理的工作过程往往只有在“面试”的时候才能用得上，但是如果在工作中你能够深入的理解SpringBoot的自动配置原理，将无往不利。SpringBoot的出现，得益于“约定优于配置”的理念，没有繁琐的配置、难以集成的内容（大多数流行第三方技术都被集成），这是基于Spring4.x提供的按条件配置Bean的能力。2、SpringBoot自动配置原理2.1配置文件到底能写什么？怎么写？我们一接触SpringBoot的时候就了解到：SpringBoot有一个全局配置文件application.properties或application.yml。我们的各种属性都可以在这个文件中进行配置，最常配置的比如：server.port、logging.level.*、数据库配置、Redis配置等等，然而我们实际用到的往往只是很少的一部分，而且可以配置的属性都可以在官方文档中查找到。2.2自动配置原理？（1）@SpringBootApplication每个SpringBoot应用都有一个启动类，所有的SpringBoot项目必须从启动类启动（一般情况下SpringBoot启动类类名就是项目名+Application），启动类上必须使用@SpringBootApplication注解标注而且主程序类必须位于项目基包的根目录。这个注解是SpringBoot的核心注解，标有这个注解的应用就是基于SpringBoot的应用，我们的自动配置原理和这个注解还有着千丝万缕的联系！我们可以点看进去看看。@SpringBootApplication注解是一个复合注解，这里有三个重要注解：@SpringBootConfiguration：这也是一个复合注解，底层使用的是Spring的基础注解**@Configuration**，它的作用就是让SpringBoot引用支持JavaConfig的配置方式进行配置@EnableAutoConfiguration：开启自动配置，后面着重说明它的原理。@ComponentScan：开启包扫描，也是Spring的基础注解。默认扫描的是当前类下的包。这就是要把启动类放置到基包根目录下的原因，这样启动类就可以在启动的时候把包下的@Controller/@Service/@Component/@Repository等注解类加载到IOC容器中（2）@SpringBootConfiguration注解：@SpringBootConfiguratuon注解的作用是用来告诉SpringBoot这是一个SpringBoot的配置类,从他的源码可以看出它是@Configuration注解的派生注解，对于这个注解我们应该不会陌生，这个类是Spring的核心注解之一。因此可以知道的是这两个注解的功能大致是一样的，只不过一个是专门用于SpringBoot的配置类，另一个则在Spinrg体系中是通用的。（3）@EnableAutoConfiguration注解我们点进去看一下，发现有两个比较重要的注解：@AutoConfigurationPackage：自动配置包@Import：给IOC容器导入组件（3.1）@AutoConfigurationPackage注解这个注解的作用即使自动配置包，查看源码我们可以发现，依靠的还是**@Import**注解，它使用@Import注解导入再点进去查看，我们发现重要的就是以下的代码：在默认的情况下就是将主配置类(@SpringBootApplication)的所在包及其子包里边的组件扫描到Spring容器中。看完这句话，会不会觉得，这不就是@ComponentScan注解的功能吗？这俩不就重复了吗？我开始也有这个疑问，直到我看到文档的这句话：itwillbeusedwhenscanningforcode@Entityclasses.ItisgenerallyrecommendedthatyouplaceEnableAutoConfiguration(ifyou'renotusing@SpringBootApplication)inarootpackagesothatallsub-packagesandclassescanbesearched.比如说，你用了SpringDataJPA，可能会在实体类上写@Entity注解。这个@Entity注解由@AutoConfigurationPackage扫描并加载，而我们平时开发用的@Controller/@Service/@Component/@Repository这些注解是由ComponentScan来扫描并加载的。因此这二者扫描的对象是不一样的。（3.2）@Import注解SpringBoot自动配置功能就是由Import注解后面那个类AutoConfigurationImportSelector实现的（1.5版本以前使用EnableAutoConfigurationImportSelector类，1.5以后这个类废弃了使用的是AutoConfigurationImportSelector类）。这个类会调用SpringFactoriesLoader.loadFactoryNames()方法来扫描定义在MEAT-INF/spring.factories文件中的jar包AutoConfigurationImportSelector实现了ImportSelector接口，这个接口中只有一个方法selectImports()，它的作用是控制哪些类自动的实例加入到容器中，在SpringBoot2.1.7版本中得源码如下：在selectImports()方法的源码中使用了getAutoConfigurationEntry（)这个方法，其中configurations存放的数据就是加入容器的自动配置类的完整包路径，继续追踪源码，进入getAutoConfigurationEntry（)源码：从getCandidateConfigurations()方法的实现中，我们发现他调用SpringFactoriesLoader.loadFactoryNames反返回了List集合，返回的东西是啥呢？我们直接追踪源码：通过DEBUG可以看到，返回对List中全部是一些类的全限定名。如果继续往下追踪发现他最终在loadFactories方法中使用本类的一个私有静态方法loadSpringFactories加载了META-INF/spring.factories这个配置文件。查看spring-boot-autoconfigure包下META-INF/spring.factories：看到的非常多的xxxxAutoConfiguration类，这些类都是容器中的一个组件，加入到容器中，用他们做自动配置。2.2SpringBoot自动配置原理总结@SpringBootApplication等同于下面三个注解：@SpringBootConfiguration@EnableAutoConfiguration@ComponentScan其中@EnableAutoConfiguration是关键(启用自动配置)，内部实际上就去加载META-INF/spring.factories文件的信息，然后筛选出以EnableAutoConfiguration为key的数据，加载到IOC容器中，实现自动配置功能！官网参考文档：https://docs.spring.io/spring-boot/docs/2.2.0.BUILD-SNAPSHOT/reference/html/using-spring-boot.html#using-boot-structuring-your-code3、@Conditional派生注解SpringBoot在启动的时候为我们加载了这么多组件，我们不可能全部用得上，那如果用不上的还注册进容器，岂不是耗费资源。其实底层使用了条件装配@Conditional，在我们需要的情况下才会注册对应的组件。比如，SpringBoot中对AOP的自动配置如下所示：AOP的自动配置中使用了非常多的条件注解：@ConditionalOnClass({EnableAspectJAutoProxy.class,Aspect.class,Advice.class,AnnotatedElement.class})表示当类路径上存在EnableAspectJAutoProxy、Aspect、Advice、AnnotatedElement时才会自动配置@ConditionalOnProperty(prefix="spring.aop",name={"auto"},havingValue="true",matchIfMissing=true)表示当配置文件中存在配置项spring.aop.auto=true时会自动配置，不过这里默认值就是true，所以默认会配置@ConditionalOnProperty(prefix="spring.aop",name={"proxy-target-class"},havingValue="true/false",matchIfMissing=true/false)表示当配置文件中存在配置项spring.aop.proxy-target-class并且当它的值为true的时候会使用CGLib代理，否则默认会使用JDK动态代理在SporingBoot源码中下方这些Condition注解比较常见：Conditional扩展注解作用（判断是否满足当前指定条件）@ConditionalOnJava系统的java版本是否符合要求@ConditionalOnBean容器中存在指定Bean；@ConditionalOnMissingBean容器中不存在指定Bean；@ConditionalOnExpression满足SpEL表达式指定@ConditionalOnClass类路径上有指定的类@ConditionalOnMissingClass系统中没有指定的类@ConditionalOnSingleCandidate容器中只有一个指定的Bean，或者这个Bean是首选Bean@ConditionalOnProperty系统中指定的属性是否有指定的值@ConditionalOnResource类路径下是否存在指定资源文件@ConditionalOnWebApplication当前是web环境@ConditionalOnNotWebApplication当前不是web环境@ConditionalOnJndiJNDI存在指定项Q：如何知道哪些自动配置类生效了，哪些配置类没有生效？A：我们可以通过在主配置文件中配置debug=true属性；来让控制台打印自动配置报告，这样我们就可以很方便的知道哪些自动配置类生效。如下：

SpringBoot从入门到精通—配置文件详解

1、SpringBoot配置文件    SpringBoot支持两种形式的配置文件，分别是.properties、和.yml，而且配置文件的名字是固定不可变的：*application.properties*application.yml    配置文件的作用是修改SpringBoot自动配置的默认值。相对于properties文件而言，yml文件更年轻，也有很多的坑。下面我们就来一一学习一下。    注意：当application.properties文件和application.yml同时存在的时候，application.properties会优先加载，application.yml则后加载，而且在applicatin.properties中已经加载的属性如果在application.yml中再次出现会被忽略，如果是application.yml中的独有的属性则会加载。2、YAML/YML文件简介2.1什么是YAML/YML文件    YAML是"YAMLAin'taMarkupLanguage"（YAML不是一种置标语言）的递回缩写。YAML是一个可读性高，用来表达资料序列的编程语言。YAML是一种直观的能够被电脑识别的的数据数据序列化格式，容易被人类阅读，容易和脚本语言交互的，可以被支持YAML库的不同的编程语言程序导入，比如：C/C++,Ruby,Python,Java,Perl,C#,PHP等。YAML以数据为中心，比json、xml等更适合做配置文件。2.2YAML/YML的基本语法基本语法：key:value，key:和value中间要有一个空格,而且key:value的形式可以写无限层。还有一下规则：1.大小写敏感2.使用缩进表示层级关系3.缩进时不允许使用Tab键，只允许使用空格。4.缩进的空格数目不重要，只要相同层级的元素左侧对齐即可5.只有一种注释方式，使用#2.3YAML/YML支持的数据结构YML支持3中类型的数据结构类型1.字面量2.对象（属性和值），Map（键值对）3.数组（List、Set）1、字面量具体包括：字符串、布尔值、整数、浮点数、Null、时间、日期字面量可以直接使用，但是特别注意字符串的字面量在写的时候是不需要引号的（无论单引号还是双引号）。单/双引号在yml语法中有特殊的含义：​*“”：双引号；会转义字符串里面的特殊字符；特殊字符会作为本身想表示的意思​name:“zhangsan\nlisi”：输出；zhangsan换行lisi*​”：单引号；不会转义特殊字符，特殊字符最终只是一个普通的字符串数据name:‘zhangsan\nlisi’：输出；zhangsan\nlisi2.对象（属性和值），Map（键值对）基本的语法还是key：value，以一个例子来说明：对应的行内写法：3.数组（List、Set）用-值表示数组中的一个元素行内写法举个栗子：配置一个Person的信息我们可以导入配置文件处理器，编写配置的时候就有提示了在application.yml配置文件中配置preson信息：在SpringBoot测试类中测试IOC是否可以拿到在配置文件中配置的信息测试结果：3、properties文件简介    properties文件大家经常用，这里就简单介绍一下。其语法结构形如：key=value。注意中文乱码问题，需要转码成ASCII。在IDEA中可以设置自动转换把uft-8格式自动转成ASCII，设置方式是：依次点击【File】=>【OtherSettings】=>【settigsfornewprojects】，搜索FileEncodings，然后做如下配置：上面Person信息的properties配置如下：4、配置文件值注入4.1@Value获取值和@ConfigurationProperties获取值比较    SpringBoot通过ConfigurationProperties注解从配置文件中获取属性。从上面的例子可以看出ConfigurationProperties注解可以通过设置prefix指定需要批量导入的数据。支持获取字面值，集合，Map，对象等复杂数据。ConfigurationProperties注解还有其他特么呢？它和Spring的Value注解又有什么区别呢？带着这些问题，我们继续往下看。比较@ConfigurationProperties@Value功能批量注入配置文件中的属性一个个指定松散绑定（松散语法）支持不支持SpEL不支持支持JSR303数据校验支持不支持复杂类型封装支持不支持**何时使用@Value何时使用@ConfigrationProperties？**如果说，我们只是在某个业务逻辑中需要获取一下配置文件中的某项值，使用@Value。如果说，我们专门编写了一个javaBean来和配置文件进行映射，我们就直接使用@ConfigurationProperties。4.1配置文件注入值数据校验使用@Vaildatad可以给配置的属性数据校验功能。可以用在类、方法、参数上。可以加的验证注解如下：下面举个例子：4.2@PropertySource&@ImportResource&@Bean@PropertySource：加载指定的配置文件；person.properties@ImportResource：导入Spring的配置文件，让配置文件里面的内容生效；在src/main/resources下新建一个Spring配置文件applicationContext.xml在SpringBoot的主程序类中使用@ImportResource引入配置这个配置文件然后在测试类中自动注入ApplicationContext来拿这个组件测试结果：虽然这种方式可以用，但是一般我们不这么用，而且SpringBoot也不推荐这么使用，SpringBoot推荐使用全注解的方式来添加配置文件。*1、配置类**@Configuration**------>Spring配置文件2、使用**@Bean**给容器中添加组件接下类，我们在com.xust.iot基包下新建配置类ApplicationConfig.java运行后得到的效果一样：5、配置文件占位符在application.properties和application.yml文件可以使用${random}来设置随机值5.1常用随机设值如下在application.yml文件中写如下配置：在测试类中打印person的信息，结果如下：6、SpringBootprofile    Spring支持对不同环境，提供不同配置，可以通过激活、指定参数等方式快速的切换环境。环境profile可以是开发环境（develop）、测试环境（fuy）、生产环境（production）等6.1配置多个profile在主配置文件编写的时候，文件名可以是application-{profile_name}.properties/yml,比如下面分别编写的application-develop.properties和application-production.propertiesapplication-develop.propertiesapplication-production.properties目录结构：在主配置文件application.properties中，使用spring.profiles.active=[profile]来激活不同的环境，如下激活develop环境：启动SpringBoot观察Tomcat启动的端口激活生产环境：spring.profiles.active=production可以看到，配置的不同环境被激活后都起作用了。这在以后的开发中无疑是个十分强大而且方便的功能。6.2YML配置多个profile然而使用properties文件配置不同环境还是太麻烦了，YML对多profile的支持更加简单粗暴，直接通过连续的三个-就可以划分出不同的文件，配置示例：注意：SpringBoot启动的时候会优先加载.properties的文件，然后才来加载.yml文件，如果要想使applicaton.yml中配置的信息可以使用，那么.properties中不能有和.yml相同的配置。6.3激活指定profile的不同方式1、在主配置文件中指定spring.profiles.active=dev，上面的配置方式就是这种。​2、命令行：可以在IDEA中配置--spring.profiles.active=develop来启动开发环境，操作如下：也可以在命令行中使用java-jarspring_boot_config-0.0.1-SNAPSHOT.jar--spring.profiles.active=develop来启动开发环境3、虚拟机参数：可以在IDEA中做如下配置：-Dspring.profiles.active=dev，示例如下：7、配置文件的加载位置springboot启动会扫描以下位置的application.properties或者application.yml文件作为Springboot的默认配置文件–file:./config/–file:./–classpath:/config/–classpath:/这些位置的配置文件加载的优先级由高到底，而且高优先级的配置如果在低优先即中出现，那么低优先优先级中重复配置不会生效。但是低优先级中独有的配置还是会生效。也就是说SpringBoot会从这四个位置全部加载主配置文件；并且会互补配置；==我们还可以通过spring.config.location来改变默认的配置文件位置==比如：项目打包好以后，我们可以使用命令行参数的形式，启动项目的时候来指定配置文件的新位置；指定配置文件和默认加载的这些配置文件共同起作用形成互补配置；首先在硬盘的另一个地方(我这里在E://)创建application.properties。添加如下配置：然后可以在命令行输入java-jarspring_boot_config-0.0.1-SNAPSHOT.jar--spring.config.location=E://application.properties####8、外部配置加载顺序**==SpringBoot也可以从以下位置加载配置，加载顺序的优先级从高到低；高优先级的配置会覆盖低优先级的配置，所有的配置会形成互补配置==**。**1.命令行参数**所有的配置都可以在命令行上进行指定java-jarspring_boot_config-0.0.1-SNAPSHOT.jar--server.port=8087--server.context-path=/abc多个配置用空格分开；`--配置项=值`2.来自java:comp/env的JNDI属性3.Java系统属性（System.getProperties()）4.操作系统环境变量5.RandomValuePropertySource配置的random.*属性值==**由jar包外向jar包内进行寻找；**====**优先加载带profile的配置文件**==**6.jar包外部的application-{profile}.properties或application.yml(带spring.profile)配置文件****7.jar包内部的application-{profile}.properties或application.yml(带spring.profile)配置文件**==**再来加载不带profile的配置文件**==**8.jar包外部的application.properties或application.yml(不带spring.profile)配置文件****9.jar包内部的application.properties或application.yml(不带spring.profile)配置文件**10.@Configuration注解类上的@PropertySource11.通过SpringApplication.setDefaultProperties指定的默认属性所有支持的配置加载来源[参考官方文档](https://docs.spring.io/spring-boot/docs/1.5.9.RELEASE/reference/htmlsingle/#boot-features-external-config)。

SpringBoot与日志

一、日志框架分类目前，日志框架有很多，例如：JUL（java.util.logging）、JCL（ApacheJakartaCommonsLogging）、Log4j、Log4j2、LogBack、SLF4J、jboss-logging等等。日志门面日志实现JCL（ApacheJakartaCommonsLogging）SLF4J(SimpleLoggingFacadeforJava)jboss-loggingLog4jJUL(java.util.logging)Log4j2Logback    日志门面就是日志的抽象层，里面只是定义了日志的规范，日志实现就是来具体实现日志门面的。日志门面中这里重点来介绍一下SLF4J。1、SLF4J    slf4j是对所有日志框架制定的一种规范、标准、接口，并不是一个框架的具体的实现。因为接口并不能独立使用，需要和具体的日志框架实现配合使用（如log4j、logback）。那么问题来了，我们有了日志的实现，为什么还需要日志门面（日志抽象层）？    我们都知道使用一个接口实际上使用的是这个接口的实现类，那好了，我只要在程序中使用接口中的API来操作日志，然后导入实现了这个日志接口的日志实现类，程序就可以正常的记录日志；下次我们导入了另一套基于这个接口实现的日志实现类，不用改我们在程序中写的任何日志代码程序还是可以正常的记录日志。原理很简单，日志实现类实现了日志接口的规范。因此这个问题的回答总结为一句话：使用日志框架接口更便于更换为其他的日志框架。    log4j、logback、log4j2都有SLF4J的具体实现，他们既可以单独使用，也可以结合SLF4J框架使用。相关的Maven依赖写法：2、Log4J    log4j是apache实现的一个开源日志组件。通过使用log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIXSyslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。然而log4j已经很多年没有更新过了，小项目可以使用，大项目还是算了吧。相关的Maven依赖写法：3、Logback    logback同样是由log4j的作者设计完成的，拥有更好的特性，是用来取代log4j的一个日志框架，是slf4j的原生实现，所以logback与slf4j的结合最好。    Logback，一个“可靠、通用、快速而又灵活的Java日志框架”。logback当前分成三个模块：logback-core，logback-classic和logback-access。logback-core是其它两个模块的基础模块。logback-classic是log4j的一个改良版本。此外logback-classic完整实现SLF4JAPI使你可以很方便地更换成其它日志系统如log4j或JDKLogging。logback-access访问模块与Servlet容器集成提供通过Http来访问日志的功能。因此在log4j和logback之间选择的话，我们应该选择更强大的logback。理由如下：1.logback比log4j要快大约10倍，而且消耗更少的内存。2.logback-classic模块直接实现了SLF4J的接口，所以我们迁移到logback几乎是零开销的。3.logback不仅支持xml格式的配置文件，还支持groovy格式的配置文件。相比之下，Groovy风格的配置文件更加直观，简洁。4.logback-classic能够检测到配置文件的更新，并且自动重新加载配置文件。5.logback能够优雅的从I/O异常中恢复，从而我们不用重新启动应用程序来恢复logger。6.logback能够根据配置文件中设置的上限值，自动删除旧的日志文件。7.logback能够自动压缩日志文件。8.logback能够在配置文件中加入条件判断（if-then-else)。可以避免不同的开发环境（dev、test、uat…）的配置文件的重复。9.logback带来更多的filter。10.logback的stacktrace中会包含详细的包信息。11.logback-access和Jetty、Tomcat集成提供了功能强大的HTTP-access日志。相关的Maven依赖写法：4、log4j2引用官网的一句话ApacheLog4j2isanupgradetoLog4jthatprovidessignificantimprovementsoveritspredecessor,Log4j1.x,andprovidesmanyoftheimprovementsavailableinLogbackwhilefixingsomeinherentproblemsinLogback’sarchitecture.翻译过来就是说：ApacheLog4j2是对Log4j的升级，它比其前身Log4j1.x提供了重大改进，并提供了Logback中可用的许多改进，同时修复了Logback架构中的一些固有问题。Log4j2的特性：1.插件式结构。Log4j2支持插件式结构。我们可以根据自己的需要自行扩展Log4j2.我们可以实现自己的appender、logger、filter。2.配置文件优化。在配置文件中可以引用属性，还可以直接替代或传递到组件。而且支持json格式的配置文件。不像其他的日志框架，它在重新配置的时候不会丢失之前的日志文件。3.Java5的并发性。Log4j2利用Java5中的并发特性支持，尽可能地执行最低层次的加锁。解决了在log4j1.x中存留的死锁的问题。4.异步logger。Log4j2是基于LMAXDisruptor库的。在多线程的场景下，和已有的日志框架相比，异步的logger拥有10倍左右的效率提升。相关的Maven依赖写法：二、日志框架的使用1、SLF4J2、什么时候使用SLF4J比较合适呢？    如果你开发的是类库或者嵌入式组件，那么就应该考虑采用SLF4J，因为不可能影响最终用户选择哪种日志系统。在另一方面，如果是一个简单或者独立的应用，确定只有一种日志系统，那么就没有使用SLF4J的必要。3、如何在系统中使用SLF4J?(官网:https://www.slf4j.org/manual.html)下面是官网给的一个使用实例，以后如果要是用SLF4J,那就不要直接调用实现类的API，而是应该调用SLF4J里面的API，当然只是使用日志实现类另当别论！4、Log4J    log4j是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、数据库等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。    Log4j有7种不同的log级别，按照等级从低到高依次为：TRACE、DEBUG、INFO、WARN、ERROR、FATAL、OFF。如果配置为OFF级别，表示关闭log。Log4j支持两种格式的配置文件：properties和xml。包含三个主要的组件：Logger、appender、Layout。一个简单的log4j配置文件在SpringBoot中使用log4j    首先创建一个SpringBoot工程，在创建SpringBoot工程时，我们引入了spring-boot-starter，其中包含了spring-boot-starter-logging，由于SpringBoot默认的日志框架是Logback，所以我们在引入log4j之前，需要先排除该包的依赖，再引入log4j的依赖。配置log4j-spring.properties    配置文件的编写方法上面介绍的没有啥区别，但是配置文件的名字可以是log4j-spring.properties也可以是log4j.properties，但是SpringBoot官方推荐的命名方式是第一种方式。配置文件的内容参考上面。在SpringBoot主配置文件中指定日志文件的配置5、Logbacklogblack的加载顺序SLF4J+Logback是SpringBoot默认的日志策略，logback支持xml和groovy形式的配置文件，而且还支持编程式地配置，它加载配置文件的顺序：在classpath中寻找logback-test.xml文件如果找不到logback-test.xml，则在classpath中寻找logback.groovy文件如果找不到logback.groovy，则在classpath中寻找logback.xml文件如果上述的文件都找不到，则logback会使用JDK的SPI机制查找META-INF/services/ch.qos.logback.classic.spi.Configurator中的logback配置实现类，这个实现类必须实现Configuration接口，使用它的实现来进行配置如果上述操作都不成功，logback就会使用它自带的BasicConfigurator来配置，并将日志输出到console在SpringBoot中使用LogBack(官网：https://logback.qos.ch/documentation.html)前面说过，logback是SpringBoot默认的日志系统，假如对日志没有特殊要求，可以完全零配置使用SLF4J（SimpleLoggingFacadeForJava）的logback来输出日志。    上面这段程序，不经过任何配置，默认的日志系统是完全可以正常运行的。但是SpringBoot也支持我们修改默认配置，修改的方式有两种，一种是在src/main/resources下新建logback-spring.xml文件（logback.xml也可以，但官方推荐前面的写法）；第二种是直接在SpringBoot主配置文件中配置，下面是简单的配置示例：logbac-spring.xmlapplication.properties6、扩展使用springProperty    在logback-spring.xml中可以使用SpringBoot扩展的，使用它可以把在application.properties中定义的属性值映射为logback环境中的一个属性，从而可以在logback的上下文使用。举个例子：    下面的配置中定义了属性appName对应于SpringBoot的Environment中的app.name（由source属性指定），当未指定时默认使用defaultValue属性指定的TEST；属性name对应于SpringBoot的Environment中的logging.path，未指定时使用/logs/${appName}.log，其中的${appName}又对应于变量appName的值。定义好的变量可以在logback的配置文件中以${varName}的形式进行引用。三、多个不同的日志框架共用SLF4J    经常在实际的开发环境中，我们会使用到不同的框架，而且不同的框架默认的日志系统不同，那么如何在SpringBoot中设置一下，让这些不同框架的默认日志系统可以借助于SpringBoot的默认日志系统来工作？这是可以办到的,具体的步骤如下：1、在pom.xml文件中导入依赖的时候排除所使用框架对默认日志系统的依赖2、用SLF4J提供的中间包替换原有日志框架下图有详细的配置方法：

SpringBoot从入门到精通—SpringBoot快速入门

1、入门环境准备在本地安装3.3版本以上的Maven，以及JDK1.7以上的java环境，然后在IDEA【settings】=>【File|Settings|Build,Execution,Deployment】=>【Maven】，设置如下内容：2、使用Maven构建SpringBoot工程    第一个程序我们先创建一个Maven工程。创建好Maven项目后，首先导入SpringBoot的依赖包，他的依赖可以在SpringBoot的官网找到。注意：    1.spring-boot-starter-parent的父项目是spring-boot-dependencies（SpringBoot的版本仲裁中心），他的作用是用来管理SpringBoot应用里面的所有依赖版本    2.spring-boot-starter-web：spring-boot-starter我们称作spring-boot场景启动器，SpringBoot将所有的功能场景都抽取出来，做成一个个的starters（启动器），只需要在项目里面引入这些starter，相关场景的所有依赖都会导入进来（要用什么功能就导入什么场景的启动器）。spring-boot-starter-web的作用是帮我们导入了web模块正常运行所依赖的组件；完成上面的操作后，在src/main/java下新建一个主程序类Application.java类注意！    1、主程序类必须位于项目基包的根目录（具体原因下面会说），而且要使用@SpringBootApplication来告诉SpringBoot这是一个主程序类（配置类），这么标注后SpringBoot就会从这个类的main方法启动并加载配置。    2、@SpringBootApplication是基于SpringBoot基本注解的一个复合注解，源码片段如下：        2.1、@SpringBootConfiguration：标注在某个类上，表示这是一个SpringBoot的配置类；底层实际还是使用的是Spring的底层注解@Configuration        2.2、@ComponnetScan：标注在类上，就是我们熟悉的包扫描        2.3、@EnableAutoConfiguration：开启自动配置功能；以前我们需要配置的文件，在类上写上这个注解，SpringBoot帮我们自动配置。自动配置是SpringBoot的一大特性，关于它的原理可以参看我的另一篇文章SpringBoot从入门到精通—自动配置原理（深入源码）然后在src/main/java包下新建controller包，在这个包下新建HelloWordController.java这样一个简单的SpringBoot程序就写好了，在主程序类中点击运行按钮启动它。下面是运行后的结果：关于运行结果的说明：启动后我们访问http://localhost:8080，回车后就会出现WhitelableErrorPage提示，这是SpringBoot默认的错误页面，由于我们没有指定初始页面，出错很正常，之后在地址栏中请求hello，就可以看到我们写的Helloword,helloSpringBoot!1.2SpringBoot使用可执行jar文件部署应用    基于SpringBoot开发项目，不仅开发起来十分容易，而且由于他内置了Tomcat、Jetty等应用服务器，因此使得我们的部署也不再需要外部的应用服务器了，我们可以把SpringBoot使用Maven打包成jar文件后直接执行起来就可以了。    把SpringBoot打包成jar文件需要spring-boot-maven-plugin这个插件（在上面有依赖文件中已经导入）。在POM文件中导入后，我们在IDEA有侧边栏点击【Maven】=>【项目名】=>【Lifecycle】=>【package】，双击package就会运行插件就可以我们的应用打包成一个可运行的jar包（或者在IDEA自带的控制台中在当前项目的根目录下使用命令mvncleanpackage）。打包后我们在target目录下可以找到他，然后复制在里一个目录中在命令行中cd到这个目录，执行java-jarjar包名这个命令可以执行打包后的应用。下面是执行后命令行的打印：2、使用SpringInitializer快速创建SpringBoot项目【推荐】除了使用Maven构建一个SpringBoot项目之外，我们还可以使用Spring官方提供的SpringInitializer来快速构建一个SpringBoot项目。在IDEA依次点击【New】=>【Project】然后选择【SpringInitializr】使用SpringInitializr构建的SpringBoot项目中主程序类已经生成好了，我们只需要我们实现业务逻辑resources文件夹中目录结构static：保存所有的静态资源，如：jscssimages；templates：保存所有的模板页面，SpringBoot默认jar包使用嵌入式的Tomcat，默认不支持JSP页面，可以使用模板引擎（freemarker、thymeleaf）；application.properties：SpringBoot的配置文件；可以修改一些默认设置。这个文件也支持YAML格式的文件，用YAML格式配置的文件结构更加简洁，清晰。