1.蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析
2.Spring IoC源码深度剖析
3.一文详解RocketMQ-Spring的源码源码解析与实战
4.剖析slf4j原理并实现自己的日志框架
5.76 张图，剖析 Spring AOP 源码，剖析小白居然也能看懂，源码大神，剖析请收下我的源码膝盖！
6.定时调度- 01 quartz的剖析跟版网源码破解基础你真的了解吗
蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析
SOFAStack，蚂蚁金服自主研发的源码金融级云原生架构组件集，是剖析金融场景的最佳实践。本文由盲僧作者，源码来自OYO，剖析是源码《SOFAArk实现原理》系列的第二篇，系列代号暂未提及，剖析详情可查看系列共建列表。源码该系列关注SOFAArk，剖析一款由蚂蚁金服开源的源码轻量级类隔离框架，主要用于类隔离和应用合并部署。
SOFAArk的核心产品SOFAArk Biz的打包插件sofa-ark-maven-plugin，是理解Biz包结构的关键。自年起，SOFAArk在蚂蚁金服内部广泛应用，现已被多家企业采用，如网易云音乐、挖财、溢米教育等。本文将介绍插件的使用、打包产物以及与Spring Boot插件的对比，以帮助理解其工作原理。
SOFAArk的插件使用时，需删除或注释Spring Boot插件，然后引入sofa-ark-maven-plugin。打包后，会产生三个jar包：原生jar、Ark Biz包和Ark执行jar。其中，Ark包和Biz包的结构和Spring Boot的FATJAR有所差异，SOFAArk提供了容器和模块合并部署的能力。
通过对比Spring Boot的打包产物，SOFAArk的包结构更复杂，因为它包含容器和业务模块。SOFAArk的启动流程涉及Ark容器和插件，这使得它在合并部署上优于Spring Boot。插件原理分析部分，通过调试和流程图揭示了SOFAArk Maven插件的构建逻辑。
《剖析 | SOFAArk源码》系列致力于深入解析SOFAArk的各个部分，有兴趣的读者可通过公众号“金融级分布式架构”参与共建。SOFAArk的猪猪券源码phpGitHub地址是：github.com/sofastack/so...
Spring IoC源码深度剖析
Spring IoC容器初始化深度剖析
Spring IoC容器是Spring的核心组件，主要负责对象管理和依赖关系管理。容器体系丰富多样，如BeanFactory作为顶层容器，它定义了所有IoC容器的基本原则，而ApplicationContext及其子类如ClassPathXmlApplicationContext和AnnotationConfigApplicationContext则提供了额外功能。Spring IoC容器的初始化流程关键在AbstractApplicationContext的refresh方法中。 1.1 初始化关键点 通过创建特定类LagouBean并设置断点，我们发现Bean的创建在未设置延迟加载时，发生在容器初始化过程中。构造函数调用、InitializingBean的afterPropertiesSet方法以及BeanFactoryPostProcessor和BeanPostProcessor的初始化和调用，都在refresh方法的不同步骤中发生。 1.2 主体流程概览 Spring IoC容器初始化的主体流程主要集中在AbstractApplicationContext的refresh方法，涉及Bean对象创建、构造函数调用、初始化方法执行和处理器调用等步骤。 1.3 深度剖析 分析发现，延迟加载机制使得懒加载的bean在第一次调用getBean时才进行初始化。而对于非懒加载bean，它们在容器初始化阶段已经完成并缓存。Spring处理循环依赖的方法依赖于构造器调用的顺序规则，不支持原型bean的循环依赖，而对单例bean则通过setXxx或@Autowired方法提前暴露对象来避免循环依赖。一文详解RocketMQ-Spring的源码解析与实战
火箭MQ与Spring Boot整合详解：源码解析与实战 本文将带你深入理解在Spring Boot项目中如何运用rocketmq-spring SDK进行消息收发，同时剖析其设计逻辑。此SDK是开源项目Apache RocketMQ的Spring集成，旨在简化在Spring Boot中的消息传递操作。 首先，我们介绍rocketmq-spring-boot-starter的基本概念。它本质上是一个Spring Boot启动器，以“约定优于配置”的理念提供便捷的集成。通过在pom.xml中引入依赖并配置基本的配置文件，即可快速开始使用。 配置rocketmq-spring-boot-starter时，需要关注以下两点：引入相关依赖和配置文件设置。生产者和消费者部分，我们将分别详细讲解操作步骤。 对于生产者，仅需配置名字服务地址和生产者组，然后在需要发送消息的类中注入RocketMQTemplate，最后使用其提供的发送方法，如同步发送消息。模板类RocketMQTemplate封装了RocketMQ的API，简化了开发流程。 消费者部分，易语言im源码同样在配置文件中配置，然后实现RocketMQListener，以便处理接收到的消息。源码分析显示，RocketMQAutoConfiguration负责启动消费者，其中DefaultRocketMQListenerContainer封装了RocketMQ的消费逻辑，确保支持多种参数类型。 学习rocketmq-spring的最佳路径包括：首先通过示例代码掌握基本操作；其次理解模块结构和starter设计；接着深入理解自动配置文件和RocketMQ核心API的封装；最后，通过项目实践，扩展自己的知识，尝试自定义简单的Spring Boot启动器。 通过这篇文章，希望你不仅能掌握rocketmq-spring在Spring Boot中的应用，还能提升对Spring Boot启动器和RocketMQ源码的理解。继续保持学习热情，探索更多技术细节！剖析slf4j原理并实现自己的日志框架
本文深入探讨了SLF4J的基本原理，并展示了如何实现自己的日志框架。SLF4J作为日志系统的一个适配层，其主要作用是解决日志系统选择和配置的复杂性。通过引入SLF4J，开发人员只需关注日志的编写逻辑，而无需关心日志系统的具体实现。SLF4J并不提供日志的直接实现，而是提供了一套接口以及获取具体日志对象的方法。SLF4J的实现包括SLF4J-SIMPLE、Logback和Log4j等。Logback和Log4j通过特定的桥接层与SLF4J兼容。
本文详细分析了Logback的源码结构，展示了它如何基于门面模式实现日志接口，以及Log4j如何通过SLF4J-log4j桥接层与SLF4J进行交互。通过对比SLF4J-API与SLF4J-SIMPLE，本文进一步解释了SLF4J作为适配层的灵活性与重要性。在使用SLF4J时，多个实现可能会导致冲突，通过配置管理或更新依赖关系可以解决这类问题。
通过实例分析，本文揭示了SLF4J如何帮助开发者在项目中引入不同的日志实现，并确保在更换或维护日志系统时的简便性。SLF4J的实现过程包括定义门面对象、实现自己的LoggerFactory和Logger，最终通过StaticLoggerBinder获取具体的Logger实例。
实现自己的日志框架时，确保包名遵循SLF4J的查找规则至关重要。本文提出了实现日志框架的u148源码三大关键组件：定义包名、实现自定义的LoggerFactory和Logger。SLF4J的原理分析指出，其核心在于performInitialization()方法的执行，进而通过StaticLoggerBinder实现具体日志系统的获取。
对于不改变原有代码而引入自己的日志框架，本文建议通过切面编程实现，确保该类被Spring管理且非null。在SpringBoot2.x中，通常使用cglib进行代理实现。项目已开源，欢迎读者指出错误，地址：gitee.com/z_w/LogSys...
张图，剖析 Spring AOP 源码，小白居然也能看懂，大神，请收下我的膝盖！
本文将简要介绍AOP（面向切面编程）的基础知识与使用方法，并深入剖析Spring AOP源码。首先，我们需要理解AOP的基本概念。
1. **基础知识
**1.1 **什么是AOP？
**AOP全称为Aspect Oriented Programming，即面向切面编程。AOP的思想中，周边功能（如性能统计、日志记录、事务管理等）被定义为切面，核心功能与切面功能独立开发，然后将两者“编织”在一起，这就是AOP的核心。
AOP能够将与业务无关、却为业务模块共同调用的逻辑封装，减少系统重复代码，降低模块间的耦合度，有利于系统的可扩展性和可维护性。
1.2 **AOP基础概念
**解释较为官方，以下用“方言”解释：AOP包括五种通知分类。
1.3 **AOP简单示例
**创建`Louzai`类，添加`LouzaiAspect`切面，并在`applicationContext.xml`中配置。程序入口处添加`"睡觉"`方法并添加前置和后置通知。接下来，我们将探讨Spring内部如何实现这一过程。
1.4 **Spring AOP工作流程
**为了便于理解后面的源码，我们将整体介绍源码执行流程。整个Spring AOP源码分为三块，asp 简单登录源码结合示例进行讲解。
第一块是前置处理，创建`Louzai`Bean前，遍历所有切面信息并存储在缓存中。第二块是后置处理，创建`Louzai`Bean时，主要处理两件事。第三块是执行切面，通过“责任链+递归”执行切面。
2. **源码解读
**注意：Spring版本为5.2..RELEASE，否则代码可能不同！这里，我们将从原理部分开始，逐步深入源码。
2.1 **代码入口
**从`getBean()`函数开始，进入创建Bean的逻辑。
2.2 **前置处理
**主要任务是遍历切面信息并存储。
这是重点！请务必注意！获取切面信息流程结束，后续操作都从缓存`advisorsCache`获取。
2.2.1 **判断是否为切面
**执行逻辑为：判断是否包含切面信息。
2.2.2 **获取切面列表
**进入`getAdvice()`，生成切面信息。
2.3 **后置处理
**主要从缓存拿切面，与`Louzai`方法匹配，创建AOP代理对象。
进入`doCreateBean()`，执行后续逻辑。
2.3.1 **获取切面
**首先，查看如何获取`Louzai`的切面列表。
进入`buildAspectJAdvisors()`，方法用于存储切面信息至缓存`advisorsCache`。随后回到`findEligibleAdvisors()`，从缓存获取所有切面信息。
2.3.2 **创建代理对象
**有了`Louzai`的切面列表，开始创建AOP代理对象。
这是重点！请仔细阅读！这里有两种创建AOP代理对象方式，我们选择使用Cglib。
2.4 **切面执行
**通过“责任链+递归”执行切面与方法。
这部分逻辑非常复杂！接下来是“执行切面”最核心的逻辑，简述设计思路。
2.4.1 **第一次递归
**数组第一个对象执行`invoke()`，参数为`CglibMethodInvocation`。
执行完毕后，继续执行`CglibMethodInvocation`的`process()`。
2.4.2 **第二次递归
**数组第二个对象执行`invoke()`。
2.4.3 **第三次递归
**数组第三个对象执行`invoke()`。
执行完毕，退出递归，查看`invokeJoinpoint()`执行逻辑，即执行主方法。回到第三次递归入口，继续执行后续切面。
切面执行逻辑已演示，直接查看执行方法。
流程结束时，依次退出递归。
2.4.4 **设计思路
**这部分代码研究了大半天，因为这里不是纯粹的责任链模式。
纯粹的责任链模式中，对象内部有一个自身的`next`对象，执行当前对象方法后，启动`next`对象执行，直至最后一个`next`对象执行完毕，或中途因条件中断执行，责任链退出。
这里`CglibMethodInvocation`对象内部无`next`对象，通过`interceptorsAndDynamicMethodMatchers`数组控制执行顺序，依次执行数组中的对象，直至最后一个对象执行完毕，责任链退出。
这属于责任链，实现方式不同，后续会详细剖析。下面讨论类之间的关系。
主对象为`CglibMethodInvocation`，继承于`ReflectiveMethodInvocation`，`process()`的核心逻辑在`ReflectiveMethodInvocation`中。
`ReflectiveMethodInvocation`的`process()`控制整个责任链的执行。
`ReflectiveMethodInvocation`的`process()`方法中，包含一个长度为3的数组`interceptorsAndDynamicMethodMatchers`，存储了3个对象，分别为`ExposeInvocationInterceptor`、`MethodBeforeAdviceInterceptor`、`AfterReturningAdviceInterceptor`。
注意！这3个对象都继承了`MethodInterceptor`接口。
每次`invoke()`调用时，都会执行`CglibMethodInvocation`的`process()`。
是否有些困惑？别着急，我将再次帮你梳理。
对象与方法的关系：
可能有同学疑惑，`invoke()`的参数为`MethodInvocation`，没错！但`CglibMethodInvocation`也继承了`MethodInvocation`，可自行查看。
执行逻辑：
设计巧妙之处在于，纯粹的责任链模式中，`next`对象需要保证类型一致。但这里3个对象内部没有`next`成员，不能直接使用责任链模式。怎么办呢？就单独设计了`CglibMethodInvocation.process()`，通过无限递归`process()`实现责任链逻辑。
这就是我们为什么要研究源码，学习优秀的设计思路！
3. **总结
**本文首先介绍了AOP的基本概念与原理，通过示例展示了AOP的应用。之后深入剖析了Spring AOP源码，分为三部分。
本文是Spring源码解析的第三篇，感觉是难度较大的一篇。图解代码花费了6个小时，整个过程都沉浸在代码的解析中。
难度不在于抠图，而是“切面执行”的设计思路，即使流程能走通，将设计思想总结并清晰表达给读者，需要极大的耐心与理解能力。
今天的源码解析到此结束，有关Spring源码的学习，大家还想了解哪些内容，欢迎留言给楼仔。
定时调度- quartz的基础你真的了解吗
定时调度- quartz的基础理解
Quartz，作为Java领域知名的任务调度框架，因其易用和稳定性备受青睐。许多第三方应用，如Spring Boot、Elastic-Job和早期的xxl-job版本，都曾将它作为基础依赖。然而，最新版本的xxl-job已经采用时间轮实现，不再依赖quartz。 Quartz的核心组件包括Scheduler、JobDetail和Trigger，它们是调度任务的三驾马车。Scheduler作为门面，通过工厂模式提供给开发者，它负责整合和控制所有的调度操作，类似于Quartz的大管家。一个应用通常只有一个Scheduler实例，通过schedulerName区分，每个实例处理对应schedulerName的任务，集群则是通过多个实例共享同一名称来实现。 JobDetail负责存储任务配置信息，与Trigger（触发器）形成1:N关系，即一个Job可以关联多个Trigger，反之则不然。创建JobDetail时，需要指定任务类和身份ID（group和JobKey）。Trigger则定义任务的触发规则，包括身份ID、起止时间以及与Job的绑定。添加到调度器后，相关信息会被持久化到qrtz_job_details和qrtz_cron_triggers表中。 触发器的运作关键在于qrtz_triggers表，它记录了任务的运行状态和触发时间。quartz的调度机制大致如下：首先，根据配置计算下次触发时间并更新表；然后，调度器扫描表，将将要触发的任务放入内存队列；在触发前，更新时间并切换状态；执行任务后，重复上述流程。 虽然本文仅从用户角度浅析了quartz的基本运行机制，但深入理解还需结合源码和更多表结构。下文将通过源码剖析，逐步揭示quartz的内在工作原理。SpringCloud原理OpenFeign之FeignClient动态代理生成原理
在SpringCloud框架中，OpenFeign组件提供了基于Java接口的HTTP客户端实现。本文将深入剖析OpenFeign中的FeignClient动态代理生成原理，从@EnableFeignClinets注解的作用、Feign客户端接口动态代理的生成源码剖析以及Feign动态代理构造过程总结三方面进行详细阐述。
首先，我们来分析@EnableFeignClinets注解的作用。这个注解实际上是整个Feign组件的入口，通过@Import注解导入FeignClientsRegistrar类，该类实现了ImportBeanDefinitionRegistrar接口，当Spring Boot启动时，会调用该类的registerBeanDefinitions方法动态注入bean到Spring容器中。其中，registerFeignClients方法负责扫描带有@FeignClient注解的类，并生成对应的BeanDefinition。
在Feign客户端接口动态代理的生成源码剖析部分，我们主要关注FeignAutoConfiguration和FeignClientsConfiguration配置类。FeignAutoConfiguration是Feign在整个SpringCloud中的配置类，其中会注入一系列FeignClientSpecification对象，并将其封装到FeignContext中，最后将FeignContext注入到Spring容器中。FeignContext是进行配置隔离的关键组件，它内部维护了每个客户端对应的AnnotationConfigApplicationContext、配置类的封装以及父容器等信息。通过这种方法，每个客户端的配置能够在独立的ApplicationContext中进行解析，实现了配置的隔离。
接着，我们深入解析NamedContextFactory的作用，它用于进行配置隔离，确保Ribbon和Feign的配置能够被独立管理。通过构建独立的ApplicationContext，每个客户端的配置能够在自己的上下文中进行解析，避免了配置冲突。此外，我们还会剖析FeignClientsConfiguration，这是一个默认配置类，其中包含了生成Feign客户端动态代理所需的各种bean，如解析SpringMVC注解的能力、构建动态代理的类等。
在构建动态代理的过程中，整个流程涉及多个关键步骤：扫描并生成BeanDefinition、注入FeignClientFactoryBean、获取代理对象等。具体而言，当@EnableFeignClinets注解生效时，会扫描所有带有@FeignClient注解的接口并生成对应的BeanDefinition。随后，通过FeignClientFactoryBean重新生成一个bean定义，注册到Spring容器中。当需要获取代理对象时，通过FeignClientFactoryBean的getObject方法调用getTarget()，进一步获取到代理对象。整个过程涉及Feign.Builder的配置、组件的获取以及最终通过Feign.Builder构建动态代理对象。
综上所述，OpenFeign在SpringCloud框架中的实现，通过一系列的注解、配置类以及组件的协作，实现了基于Java接口的HTTP客户端的动态代理生成。从@EnableFeignClinets的注解作用到Feign客户端接口的动态代理生成，再到Feign动态代理的构造过程，整个流程设计精巧，有效提高了服务间的互操作性和可维护性。对于希望深入理解OpenFeign原理的开发者而言，本文提供的分析和总结将有助于更好地掌握这一技术。
最后，尽管本文已经详细阐述了OpenFeign的动态代理生成原理，但对于Feign与Ribbon的整合以及其他SpringCloud组件的原理，未来将会有更多深入分析的文章。通过本文的总结，希望能为读者提供一个清晰的视角，以便在实际项目中灵活运用OpenFeign实现高效、稳定的远程调用。
从源码剖析SpringBoot中Tomcat的默认最大连接数
虽然前端的Chrome浏览器对WebSocket连接有限制，但实际情况下这个限制并不常见。SpringBoot中Tomcat的默认最大连接数和线程数配置对请求处理能力有很大影响。在SpringBoot 1.5.9.RELEASE版本中，未配置时，Tomcat默认的最大连接数为，而最大线程数为。然而，随着版本更新，这些默认值在新版本（如2.2.3.BUILD-SNAPSHOT）中可能有所调整，具体配置需查看最新文档或源码。
在源码层面，可以通过ServerProperties类找到配置映射，然后在Tomcat类的customizeTomcat方法中，发现配置文件中的max-connections值会被赋值给endpoint的maxConnections属性，其默认值为。同样，maxThreads的默认值也在AbstractEndpoint类中设置，为。这些默认值在SpringBoot的最新版本中可能会有所变化，因此开发者在实际项目中需要根据需求进行调整。
