Coder_Boy_的博客

Gitlab在安装的时候，就默认包含了Gitlab CI的能力，但是该能力只是用于协调作业，并不能真的去执行作业，因此需要搭配Gitlab Runner来作为执行器实现具体的CICD工作。大致的意思是，build阶段启动一个作业，输出一段文本；关于Gitlab-ci的yaml更多配置，可以参考官方参考文档：https://docs.gitlab.com/ee/ci/yaml/此时，任意的提交行为、合并行为都会触发流水线的执行，但是也可以手动执行，我们此时选择项目中的CICD，流水线，并点击运行流水线。

这在使用大型企业级应用程序时非常重要。除了一般异常之外，我们可能还会有一些场景来识别某些特定的错误情况。异常顾问可以使用创建，我们可以创建具有有意义细节的单独异常。它将使得将来识别和调试错误变得更加容易。自定义响应对象可用于返回包含某些特定数据的对象，并满足 HTTP 状态代码、API 代码、消息等要求。我们可以使用构建器设计模式来创建具有自定义属性的自定义响应对象。

实现 ViewResolver、Ordered 接口，继承 WebApplicationObjectSupport 抽象类，基于 Bean 的名字获得 View 对象的 ViewResolver 实现类。文档已经讲述完了，对于 Spring MVC 中大部分的内容都有分析到，你会发现 Spring MVC 原来是这么回事， 其中涉及到 Spring 思想相关内容在努力阅读中，敬请期待~对于相同的视图名，返回的是相同的 View 对象，所以通过缓存，可以进一步提供性能。，来获取对应的 View 们。

组件，本地化（国际化）解析器，提供国际化支持。笔者实际上没有接触过该组件，因为目前的项目大多数都已经前后端分离了，这里只是浅显的介绍了该接口.获得 Bean 名称为 "localeResolver"，类型为 LocaleResolver 的 Bean ，将其设置为。如果未获得到，则获得默认配置的 LocaleResolver 实现类，调用。，实现 LocaleResolver 接口，通过检验 HTTP 请求的。组件，本地化（国际化）解析器，提供国际化支持。为空，且默认语言环境不为空，则返回默认对象。

获得 Bean 名称为 "viewNameTranslator"，类型为 RequestToViewNameTranslator 的 Bean ，将其设置为。如果未获得到，则获得默认配置的 RequestToViewNameTranslator 实现类，调用。组件进行了分析，视图名称转换器，用于解析出请求的默认视图名。组件，视图名称转换器，用于解析出请求的默认视图名。方法，从请求中获取默认的视图名，如果获取到了则设置到 ModelAndView 对象中。方法，获得视图名，并添加前后缀（默认都是空的）。

实现 HandlerExceptionResolver、Ordered 接口，HandlerExceptionResolver 抽象类，作为所有 HandlerExceptionResolver 实现类的。，继承 AbstractHandlerExceptionResolver 抽象类，默认 HandlerExceptionResolver 实现类，针对各种异常，设置错误响应码。的实现类没有特别多，不过也采用了组合模式，如果某个异常处理器进行处理了，也就是返回的 ModeAndView 不为。

我们只能从流中读取原始的字符串报文，或者往流中写入原始的字符串，而 Java 是面向对象编程的，字符串与 Java 对象之间的转换不可能交由开发者去实现。处理请求时，由合适的 HttpMessageConverter 消息转换器将请求报文绑定为方法中的形参对象，同一个对象就有可能出现多种不同的消息形式，比如 json 和 xml，同样，当响应请求时，方法的返回值也同样可能被返回为不同的消息形式，比如 json 和 xml。在处理 HTTP 请求的过程中，需要解析请求体，返回结果设置到响应体。

当然，默认还会添加其他的，例如 MappingJackson2HttpMessageConverter 为 JSON 消息格式的转换器，至于其他 HttpMessageConverter 实现类如何添加的，本文就不分析了，你知道就行。设置响应头 Accept-Ranges 为 "bytes"，如果数据不为空，且请求头中的 Range 不为空，且响应码为 200，则设置状态码为 206（断点续传，客户端已下载一部分数据），这里不做过多的讲述。所以这里需要一个处理器适配器，由它去执行处理器。

来进行处理，如果有某一个参数解析器支持解析该方法参数，则使用它从请求体中获取到该方法参数的值，注意这里有一定的先后顺序，因为是通过 LinkedList 保存所有的实现类，排在前面的实现类则优先处理。参数解析器从请求中获取到对应的方法参数值，因为你无法确认哪个参数值对应哪个参数，所以需要先通过它从请求中解析出参数值，一一对应，然后才能调用该方法。方法，解析参数值的后置处理，空方法，子类可以覆盖，子类 PathVariableMethodArgumentResolver 会重写该方法。

Spring 中的处理器的实现多变，比如用户的处理器可以实现 Controller 接口或者 HttpRequestHandler 接口，也可以用。处理器里面仅包含了方法的所有信息，如何解析参数、调用对应的方法、以及处理返回结果，它本身并不知道如何去处理，这里 Spring MVC 借助于。注意，这里获取到的 Method 对象可能是桥接方法，桥接方法：如果泛型对象，编译器则会自动生成一个桥接方法（java1.5向后兼容）HandlerAdapter 组件，处理器的适配器。返回值处理器等组件。

这里是通过一个一个的 HandlerAdapter 组件去判断是否支持该处理器，如果支持则直接返回这个 HandlerAdapter 组件，不会继续下去，所以获取处理器对应 HandlerAdapter 组件是有一定的先后顺序的，默认是HttpRequestHandlerAdapter -> SimpleControllerHandlerAdapter -> RequestMappingHandlerAdapter。我们主要先梳理好主流程，所以涉及的组件，还是先不详细解析。对象，然后设置其属性。

在父类 WebApplicationObjectSupport 的父类 ApplicationObjectSupport 中可以看到，因为实现了 ApplicationContextAware 接口，则在初始化该 Bean 的时候会调用。至此，HandlerMapping 组件就分析到这里了，相信你对 HandlerMapping 组件有了一个深入的了解，更加的清楚 Spring MVC 是如何处理器请求的。注解这样的方式所取代。例如，我们所熟知的 @RequestMapping 等注解的方式。

这样一来，当 Spring MVC 的 DispatcherServlet 处理请求的时候，获取到对应的 HandlerMethod 处理器，就可以通过反射执行对应的方法了。时代，我们需要编写许多的 Servlet 去处理请求，然后在 web.xml 中进行配置，而 Spring MVC 让你通过只要在类和方法上面添加。这样是不是简化了你的工作量，让你专注于业务开发。注解的方法，假设它所在的类为 UserController ，对应的方法名为 login ，则它对应的 Mapping 的名字就是。

废弃了 WebMvcConfigurerAdapter，所以需要通过 WebMvcConfigurer 接口来添加我们的拦截器，那么在 Spring Boot 2.0+ 中是如何将 WebMvcConfigurer 添加的拦截器设置到 AbstractHandlerMapping 对象中的呢？接下来开始简单的分析。拦截器的在项目中会经常使用到，应用场景比较多，例如权限校验、参数预处理等等，上面也提供了相应的。：记录已成功执行前置处理的拦截器位置，因为已完成处理只会执行前置处理成功的拦截器，且倒序执行。

这里是通过一个一个的 HandlerMapping 组件去进行处理，如果找到对应 HandlerExecutionChain 对象则直接返回，不会继续下去，所以初始化的 HandlerMapping 组件是有一定的先后顺序的，默认是BeanNameUrlHandlerMapping -> RequestMappingHandlerMapping。方法，从 Spring 的上下文中，扫描已注册的 MappedInterceptor 的拦截器们，添加到。等注解的方式所取代。等注解的方式所取代。

继承 AbstractMultipartHttpServletRequest 抽象类，基于 Servlet 3.0 的 Multipart HttpServletRequest 实现类，包含了一个。本文对 Spring MVC 处理请求的过程中使用到的 MultipartResolver 组件进行了分析，如果请求的。对象，也就是我们常用到的 MultipartFile 对象，支持对文件的操作，内部其实都是调用。集合，如果是一个简单的表单字段，那么就是一个普通的参数，将参数名和值保存起来。

是如何处理请求已经有了一个整体的认识，不过在整个处理过程中涉及到的各个 Spring MVC 组件还没有进行分析，对于许多细节存在疑惑，那么接下来会对每一个 Spring MVC 组件进行分析。这一点值得我们学习。以上就是 Spring MVC 处理请求的全过程，上面的流程进行了一定的简化，主要涉及到最核心的组件，还有许多其他组件没有表现出来，不过这并不影响大家对主过程的理解。核心类，作为 Spring MVC 的核心类，承担调度器的角色，协调各个组件进行工作，处理请求，一起来揭开这神秘的面纱吧。

因为spring-mvc项目，是的子项目，所以需要拉取整个工程，包含 Spring 所有的子项目。

是的，前面所讲述的 Servlet 的规范，无论是 web.xml 中的配置，还是 Servlet3.0 中的 ServletContainerInitializer 和 SpringBoot 的加载流程都没有太大的关联。如果应用程序是以 war 包的方式放入 Tomcat 的 webapps 文件夹下面，那么在 Tomcat 启动时会加载 war 包，生成对应的一个文件夹，Tomcat 则会去对 webapps 文件夹下面的每一个文件夹（我们的应用程序）生成一个部署任务，去解析对应的。

前面一系列文章都是围绕 BeanFactory 进行分析的，BeanFactory 是 Spring 底层 IoC 容器的实现，完成了 IoC 容器的基本功能。在实际的应用场景中，BeanFactory 容器有点简单，它并不适用于生产环境，我们通常会选择 ApplicationContext。ApplicationContext 就是大名鼎鼎的 Spring 应用上下文，它不仅继承了 BeanFactory 体系，还提供更加高级的功能，更加适用于我们的正式应用环境。

面向资源（XML、Properties）面向注解定义的 Bean 是如何被解析成 BeanDefinition（Bean 的“前身”），并保存至 BeanDefinitionRegistry 注册中心里面，实际也是通过 ConcurrentHashMap 进行保存。Spring 底层 IoC 容器 DefaultListableBeanFactory，实现了 BeanFactory 和 BeanDefinitionRegistry 接口，这个时候它处于“就绪状态”，当我们显示或者隐式地调用。

我们知道Spring中Bean的配置来源很多（主要两种方式定义一个 Bean：面向资源（XML、Properties）面向注解），为了收集不同配置源，需要统一起来，所有有必要使用一个对象存储 也就是BeanDefinition，而在使用这些BeanDefinition之前，不同的BeanDefinition直接也会存在不同的依赖层级和引用关系。

Spring源码中使用到很多Holder类 ，列如，那么作用是什么呢？Holder类的作用我们执行一下看看：很明显，这两个方法都没能改变原始的a、b变量。上面这段代码执行时的内存单元变化大致是这样的：从这个图可以看出，执行change方法时，aa变量先是在另一个内存单元中复制了一份a变量的东西，接着在方法中一直改变的都是aa变量，因此很明显a变量从始至终都没有发生改变；

我们了解到@Component注解（及其派生注解）标注的 Class 类都会被解析成 BeanDefinition（Bean 的“前身”）然后实例化为早期Bean，再进行Bean的属性注入，最后会被初始化成完整Bean对象(如果需要代理则会创建Bean代理对象)。而@Bean注解不是@Component的派生注解，且用于标注方法，使用方法名作为BeanName，返回值作为Bean，那么Spring 中是如何解析@Bean注解的呢？

Bean 是根据 BeanDefinition 配置元信息对象生成的。面向注解, 这些配置或者注解在整个Bean生命周期的作用和触发时机是什么呢。面向资源（XML、Properties）

个人总结：配置类注解 与 模式注解 在Spring中是核心注解 它们在Bean生命周期中的作用如下：注解（及其派生注解）标注的 Class 类都会被解析成 BeanDefinition（Bean 的“前身”），然后实例化为早期Bean，再进行Bean的属性注入，最后会被初始化成完整Bean对象(如果需要代理则会创建Bean代理对象)。对于XML配置的Bean，比注解配置的Bean，多了前期的几步：加载配置资源文件，解析资源文件 ，后面的流程一致都统一解析成 BeanDefinition。

（三级 Map），里面保存了正在初始化的 Bean 对应的 ObjectFactory 实现类，调用其 getObject() 方法返回正在初始化的 Bean 对象（仅实例化还没完全初始化好）Spring 只处理单例 Bean 的字段（或 Setter）注入出现循环依赖，对于构造器注入出现的循环依赖会直接抛出异常。（一级 Map）：里面保存了所有已经初始化好的单例 Bean，也就是会保存 Spring IoC 容器中所有单例的 Spring Bean。获取到的正在初始化的 Bean。

在 Bean 的实例化阶段获取到的就是一个 BeanWrapperImpl 对象，所以这里调用的就是当前 Bean 的。是 MutablePropertyValues 类型，则可能已经处理过了，否则，获取所有的属性值集合，放入。属性描述器，获取到对应的写方法，然后通过反射机制设置当前 Bean 的属性值。属性值已经转换了，则将这些属性值设置到当前 Bean 中（反射机制），如果属性值不为空，且不需要每次都处理，则设置为已转换。没有转换过，则获取所有的属性值集合，放入。设置转换后的值，避免上面的各种判断。

Naco核心流程

在容器云、微服务、DevOps等快速发展变化的时期，希望借助新技术、新思想提升我们的技术能力和业务能力。DevOps是什么？从概念上说，DevOps 是一种方法论，是一组过程、方法与系统的统称,用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。概念有了，怎么落地？很多公司在实施容器云时实现CI（Continuous Integration， 持续集成），或者CI/CD（Continuous Integration/Continuous Delivery or Deploymen

DevOps发展背景和重要阶段CI/CD是什么？CI(Continuous integration，中文意思是持续集成)是一种软件开发实战。持续集成强 调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们 可以确定新代码和原有代码能否正确地集成在一起。借用网络图片对CI加以理解。 CD(Continuous Delivery， 中文意思持续交付)是在持续集成的基础上，将集成后的代 码部署到更贴近真实运行环境(类生产环境)中。比如，我们完成单元测试后，可以

多线程并发编程 并发三大要素一、原子性原子，一个不可再被分割的颗粒。原子性，指的是一个或多个不能再被分割的操作。int i = 1; // 原子操作i++; // 非原子操作，从主内存读取 i 到线程工作内存，进行 +1，再把 i 写到主内存。虽然读取和写入都是原子操作，但合起来就不属于原子操作，我们又叫这种为“复合操作”。我们可以用synchronized 或 Lock 、原子变量类来把这个复合操作“变成”原子操作。案例演示：public class MultiThread

1、高并发产生的背景与价值更高效的使用CPU，提高CPU利用率。没有绝对定义说系统是高并发能力的强弱，只是相对的概念，指单位时间内处理的所能处理的请求数，只有相对比较时才能说谁的高并发能力高。2、衡量高并发能力的常用指标rt（响应时间） qps（每秒请求查询数） tps（每秒事务处理数）1. 响应时间(RT) ：响应时间是指系统对请求作出响应的时间2、（QPS，Queries-per-second）： 一般指每秒查询率。 每秒查询率业界参考原理：每天80%的访问集中在20%的时