西岭千秋雪的博客

源码分析の前言

Nacos注册表架构：Nacos中注册表是一个重要的概念，也是Nacos存储服务实例的数据结构，源码中体现在的serviceMap属性中。例：public = {第一层 Map：Map<String, Map<String, Service>>键（String）：public → 代表命名空间（namespaceId）。值（Map<String, Service>） → 该命名空间下的所有服务。第二层 Map：Map<String, Service>

在常规的SSM项目中，通常需要用户自己去进行Spring、Spring MVC、Mybatis的整合，以及Tomcat的配置。的依赖，在中就已经完成了Spring、Spring MVC、Tomcat的整合，通常被称为自动配置。而完成自动配置的关键，在于启动类上的注解：是一个复合注解，其中包含了和Spring Boot的@SpringBootConfiguration：标记当前类是配置类，并且将当前类加入Spring 容器。

/将xml构筑成configuration配置类//解析xml，注册成SqlSessionFactory在上面的案例中，真正执行sql的核心是**User user = session.selectOne(“com.example.mybatis.mapper.UserMapper.selectById”, 1);**这一行代码。准备阶段：体现是方法，首先创建事务对象（默认的是JDBC的事务），创建执行器，并通过装饰器模式，包装到中。还会进行插件逻辑的处理。如果有插件，就会创建。

本篇主要介绍MyBatis源码中的配置文件解析部分。MyBatis是对于传统JDBC的封装，屏蔽了传统JDBC与数据库进行交互，组装参数，获取查询结果并自己封装成对象的繁琐过程。原生MyBatis首先需要配置> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!</> <

在Spring MVC中，请求处理的关键是的doDispatch方法：其中包含了@RequestBody,@ResponseBody等注解的解析，参数的适配，方法拦截器的执行，目标方法的执行，返回值处理，以及异常处理等逻辑。Spring MVC整体请求流程，本篇只简单地进行主要流程的分析，诸如如何解析参数，解析返回值，渲染视图等不在此列。客户端请求↓↓↓HandlerExecutionChain（包含Handler和拦截器）↓调用拦截器 preHandle()↓。

本篇介绍Spring MVC 的初始化流程，源码的体现是HttpServletBean的init方法。通常Spring MVC的项目，需要打成war包，部署在Tomcat服务器上，也就是Spring MVC通常需要配合Tomcat使用，当然也可以使用Jetty、Undertow 等。Spring MVC的源码，主要是分为两部分，第一部分是Tomcat启动时，Spring MVC上下文和容器的初始化。第二部分则是请求到达Tomcat，进行路径映射，转发到然后进行处理并且返回的流程。

首先回顾一下上篇中的内容，Spring管理的事务，可以分为四个步骤：本篇笔记记录提交事务和回滚相关源码实现。

本篇重点介绍原生Spring中的事务相关原理源码。包括注解，事务的挂起与恢复，提交与回滚，隔离级别。在原生的Spring中，如果想要使用事务，需要先在配置类中注册和DataSource的bean。同时需要加上注解。

在Spring中，AOP通常是通过动态代理实现的，通过运行时增强的机制，以实现在目标代码执行前后的统一的逻辑。而Spring将两大动态代理，封装成为了，在@Component同时在/*** 方法执行前后执行*//***/@OverrideSystem.out.println("方法执行前");System.out.println("方法执行后");/*** 抛出异常后执行*/在中添加切面，其中Advisor是Advice + Pointcut组合，等于切入点+切面。

在Spring的注解模式中，通常在构造时需要传入一个配置类，标注有扫描的类路径，以及注解。前篇中提到，解析配置类是在refresh方法的中，通过如图的三行关键代码，从容器中拿到后置处理器，并执行其中的方法完成的。ConfigurationClassPostProcessor 解析配置类获取当前中的所有 Bean 名称。遍历这些bean名称，找到标注了注解的类。按照@Order注解（如果有）的值对标注了注解的类进行排序。创建解析器，用于解析。循环解析配置类parse方法解析类。

本篇接上篇，继续介绍Spring的refresh方法的全流程。上篇已经介绍了到的流程，本篇从继续。

本篇通过，介绍Spring在启动的全流程。是的一个具体实现，支持配置类+注解模式。在构造调用父类的构造方法。register方法。refresh方法。本篇主要介绍register方法和refresh的部分源码。

在Spring中，如果某个bean只有一个无参的构造方法，那么就会根据该构造方法进行实例化：但是如果存在多个呢？以及手动使用@AutoWired注解，乃至更复杂的情况？这里就涉及到Spring对于构造方法的推断。构造方法的推断，是属于bean生命周期中的实例化阶段。

两个bean中互相持有对方作为自己的属性。类似于：两个bean中互相持有对方作为自己的属性，且在构造时就需要传入：类似于：在某个bean中注入自身：其中第二种构造方法的循环依赖一般情况下是无解的，除非加上@Lazy注解。本篇重点分析第一种循环依赖Spring是如何解决的。

无论是@AutoWired的AutowiredMethodElement还是AutowiredFieldElement，或者是@Bean的autowiredbyName、autowiredbyType方法，最终都会去调用doResolveDependency方法，该方法是Spring依赖注入中的核心方法在解析@Value注解如果依赖项标注了@Value注解，Spring 会解析该注解中的值，并通过合适的类型转换器（）将其转化为目标类型。如果解析成功，直接返回该值作为依赖。

在Spring中，进行依赖注入最常见的方式是@AutoWired和@Resource。其中默认按类型（byType）查找，如果找到多个匹配的Bean，则按名称（byName）查找。而@Resource是先根据名称查找，如果（根据名称）查找不到，再根据类型进行查找。@AutoWired在源码中的体现，主要在于：在实例化后，依赖注入前预先寻找注入点在实例化后，初始化前，进行注入Spring 在实例化后，初始化前，扫描标记了该注解的属性或者方法，作为注入点缓存。

在Spring中，依赖注入（DI）可以通过xml和注解的方式实现。而注解模式也分为@AutoWired@Resource等以及或。本篇重点分析注解模式中的byName&byType。如果需要使用 @Bean(autowire = Autowire.BY_NAME) 或 @Bean(autowire = Autowire.BY_TYPE) 的模式，则需要确保对应的 bean 属性有 setter 方法。按类型匹配：Spring 会根据 setter 方法的入参类型匹配容器中的 bean 类型。

在doGetBean方法中，如果即将获取的bean不存在，无论是何种作用域的bean，最终都会调用createBean方法去创建bean。createBean方法是bean创建流程中的重要方法。将beanName转换为bean的class对象（通过jvm加载类得到class）处理当前 bean 配置了方法重写的情况通过反射将bean实例化，并且包装成BeanWrapper。如果定义了工厂方法，则通过工厂方法来创建 Bean。如果定义了 Supplier，则通过该提供者获取 Bean 实例。

原生Spring在refresh方法中，会在方法中直接创建所有非懒加载的单例Bean。

原生的Spring在构造时，会调用refresh方法。其中就包含了扫描所有包含@Component及其子注解的类（注解模式）或解析xml配置文件（xml模式）将其注册为的逻辑。将传入参数的路径进行转换，转换为classpath的格式。获取路径下的所有资源文件（.class）。通过MetadataReader 解析.class的元数据信息。判断被扫描到的类上是否存在@Component及其子注解，并且有无需要排除某个类的情况。还需要判断类上是否加入了@Conditional注解。

如果存在一种情况，在创建核心线程的过程中，还没有创建到核心线程数量大小的线程，此时已经有核心线程完成了自己的任务，新的任务会。如果当前的核心线程数为10，因为阻塞队列已满，又创建了2个应急线程，在任务都被消费执行完成的情况下，中的state，只有可能是-1（构造中的初始值），0（解锁），1（加锁）三种状态。方法，表示要关闭线程池，不接受新任务，但是要把阻塞队列中剩余的任务执行完。答案是否定的，只要当前线程池中的线程数，小于核心线程，就会尝试创建线程。shutdownNow的返回值，是阻塞队列中剩余的任务。

线程池是一种基于资源复用思想的池化技术。由线程池统一地去创建，回收线程，避免频繁地手动创建，销毁线程，以减少开销。阿里开发手册强制规范10,200,30,i < 10;i++) {});注意：本篇中提到的线程池，是JUC包下的线程池，非Tomcat的实现，Tomcat的线程池做过二次开发，和JUC的实现细节有所区别。

  LinkedBlockingQueue是一种单链表的阻塞队列，和前篇提到的ArrayBlockingQueue相比，它是。当然无界不是真正的没有大小限制，最大长度是int类型的最大值，因为很难达到，所以称为无界。  在LinkedBlockingQueue内部，有两把锁，是对ArrayBlockingQueue读写共用锁的改进，使得不同线程在LinkedBlockingQueue进行读-写操作不互斥。（可以一个线程存，另一个线程取）。  同时LinkedBlockingQueue的count属性，使用

阻塞队列，是针对一般而言的队列数据结构，增加了阻塞作为生产者方的线程，向队列中存放元素时，如果队列已满，则生产者陷入阻塞，并且唤醒消费者去进行消息的消费。作为消费者方的线程，从队列中获取元素时，如果队列已空，则消费者陷入阻塞，并且唤醒生产者去进行消息的生产。完美契合了生产者-消费者模型，并且阻塞队列作为第三方进行了两者间的解耦操作。继承体系：Collection是List和Set集合的顶级接口，定义了集合共有的行为Queue接口继承了Collection，在其中增加了作为队列的特有方法。

（读写锁）是对于（可重入锁）的一种改进，在可重入锁的基础上，进行了读写分离。适用于读多写少的场景，对于读取和写入操作分别加锁。其中读取与读取操作同步，读取和写入，写入和写入操作互斥。并且支持写锁降级的机制。实现了ReadWriteLock接口，定义了读锁和写锁的模版方法，在ReentrantReadWriteLock分别进行实现（ReentrantReadWriteLock内部实现了两把锁）。sync属性，实现了AQS的规范。

本篇从源码的角度，对JDK动态代理的实现，工作原理做简要分析。

本篇主要记录ConcurrentHashMap（笔记中简称CHM）的查询，删除，以及扩容方法的关键源码分析。

本篇是JDK1.8的ConcurrentHashMap源码个人学习笔记，ConcurrentHashMap（笔记中简称CHM）是一种线程安全的HashMap，1.8中废弃了segment数组，而是对单个桶进行线程安全控制，并且引入了分段计数，多线程扩容的思想，限于篇幅，上篇重点记录增加元素以及分段计数的源码实现。HashMap是线程不安全的，尤其是在1.7中的插入元素使用的头插法，会导致多线程下扩容死链的问题，使CPU直接100%。如果要保证线程安全，可以使用HashTable和CHM。

本篇是JDK1.8的HashMap源码个人学习笔记，从属性&内部类，构造方法，增删查方法的角度，对HashMap进行简要分析，其中红黑树部分会在下一篇笔记中记录。

集合类中，modCount字段设计的目的就是为了标记修改的次数，从而保证快速失败的机制。子类可以自由选择是否使用这个字段。官方也是不推荐一边遍历集合，一边删除元素的操作。如果一定要，可以使用迭代器避免并发修改异常。

从启动以及EventLoop组件，accpet和read事件，浅释Netty源码

ArrayList源码浅析。