肆頭的博客

在Springboot里经常能看到各种以@Conditional开头的条件注解，比较常见的有@ConditionalOnClass、@ConditionalOnBean，这里看下他们的实现原理。Springboot加载bean可以简单概括为三个阶段：1、根据配置的扫描路径找到所有需要加载的类，并封装成BeanDefinition注册到Spring容器2、实例化所有注册到容器的BeanDefinition3、对已经实例化的bean进行依赖注入这是最主要的三步，在这过程中还穿插这很多的后置处理器，这些条

文章目录生成动态代理类InfrastructureAdvisorAutoProxyCreator注册过程动态代理类生成逻辑Advisor、Pointcut、Advice选择缓存载体我们这里以redis作为缓存载体为例，在Springboot里使用redis缓存时只需要需要简单几步配置就可以：1、引入spring-boot-starter-data-redis依赖和配置2、在Springboot启动类上加上@EnableCaching 注解3、根据实际的缓存场景，在需要缓存的方法上加上相应的注解（@C

文章目录注册事务切面逻辑根据切面逻辑生成代理类总结@Transactional注解的逻辑是通过动态代理来实现的，而生成这个动态代理类分成了两步：1、向spring容器注册事务相关的切面逻辑2、根据切面逻辑生成动态代理下面围绕这两点来看下Springboot里的实现原理注册事务切面逻辑切面逻辑里有三个概念：Pointcut：负责告诉spring容器哪个类需要增强Advise：具体的切面逻辑，这里就是根据异常进行commit或者回滚的相关逻辑Advisor：封装了Advise和Pointcut

文章目录Netty做了什么？源码分析Server端启动过程IO写流程IO读流程总结Netty做了什么？Netty是以NIO为基础的网络通信框架，对jdk提供的的NIO的API做了很多完善和抽象，如果没有Netty我们需要搞定下面这些事：如何设计这个框架，以保证可维护性和可扩展性如何定义线程模型：哪些线程处理accept事件、哪些线程读写io、哪些线程处理业务逻辑解决jdk自带的NIO的一些bug，比如空轮训bug怎么序列化、反序列化怎么处理TCP粘包怎么做超时检测、异常重连等而Nett

文章目录漏桶算法、令牌桶算法思路及使用场景RateLimiter实现原理SmoothBurstySmoothWarmingUp漏桶算法、令牌桶算法思路及使用场景在介绍RateLimiter之前我们先看下常说的漏桶算法和令牌桶算法，看下两种算法的思想和适用场景：漏桶算法：结合上面的图，漏桶算法就是将请求放入桶中，然后始终以一个固定的速率从桶中取出请求来处理，当桶中等待的请求数超过上限后（桶的容量固定），后续的请求就不再加入桶中，而是执行拒绝策略（比如降级）适用于需要以固定速率的场景，而在多数业务场

使用场景线程池ThreadPoolExecutor中经常使用SynchronousQueue作为阻塞队列，比如dubbo的provider的线程池默认会使用该队列，这里要先介绍下线程池ThreadPoolExecutor的逻辑，ThreadPoolExecutor的构造方法如下：public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize,

文章目录加载过程1、读取META-INF/spring.factories配置文件里需要自动装载类2、解析MybatisAutoConfiguration类里的注解信息，将需要管理的Bean注册到Spring容器2.1 注册SqlSessionFactory，并根据mapper配置文件解析出dao与具体jdbc操作、resultMap与实体类等的映射关系2.2 注册实现了CRUD操作的SqlSessionTemplate类2.3 注册AutoConfiguredMapperScannerRegistrar类

主要细节问题：什么时候触发扩容？扩容阈值是多少？扩容时的线程安全怎么做的？其他线程怎么感知到扩容状态，从而一起进行扩容？多个线程一起扩容时，怎么拆分任务，是不是任务粒度越小越好？ConcurrentHashMap.get(key)方法是没有加锁的，怎么保证在这个扩容过程中，其他线程的get(key)方法能获取到正确的值，不出现线程安全问题？魔鬼在细节里，一起看下源码，然后回答下上面的细节问题，先看下触发扩容的代码，在往map中put新数据后会调用这个addCount(long x, int

文章目录1、consumer端发送请求1.1 获取Spring容器内的代理类，调用代理类对应的方法1.2 将请求的接口的元数据信息封装成Invocation并调用invoker链1.2.1 通过注册中心对象获取符合路由策略的服务提供方列表1.2.2 获取配置的负载均衡策略，默认是随机1.2.3 根据负载均衡策略选取一个服务提供者进行调用1.2.3.1 组装Request对象，设置request的id1.2.3.2 调用NettyClient发送Request，返回异步结果Future1.3 获取Future

文章目录前言1、实例化ServiceBean类，填充各种配置信息，为服务暴露做准备2、监听Spring容器事件，触发DubboBootstrap的start方法3、构造invoker链，生成代理类4、开启Socket服务并发布到注册中心4.1、开启Socket Server，并构建处理channel的ChannelHandler链4.2、将provider信息发布到注册中心前言这里debug的代码用的是github上dubbo项目的dubbo-demo里的dubbo-demo-xml下的代码。上一章讲

前言这里debug的代码用的是github上dubbo项目的dubbo-demo里的dubbo-demo-xml下的代码。由于这一篇都是dubbo框架内部实现，所以建议先看下dubbo官网上的一篇讲dubbo的设计原则的文章，有助于理解代码，接着上一篇，这一篇分析consumer对应的org.apache.dubbo.config.spring.ReferenceConfig.class的getObject方法,这里先贴出dubbo官网上的架构图，然后我们在看代码时，比对架构图一起分析：下面是架构图

前言这里debug的代码用的是github上dubbo项目的dubbo-demo里的dubbo-demo-xml下的代码。spring的xml文件里自定义标签的解析是基于spring.handlers文件指定的解析类来解析的，dubbo标签是在dubbo-config-spring的jar包下的META-INF/spring.handlers文件里。这里先看下一个consumer端的配置文件内容：<beans // xmlns:xsi是xsi标签命名空间 xmlns

前言在分析问题前，先看下Tomcat的架构图，有助于后面看代码：这里可以看出一个Tomcat就是一个Server，一个Server下会有多个Service，Service只负责封装多个Connector和一个Container（Service本身不是容器，可以看做只是用来包装Connector和Container的壳，不负责具体功能），而Container（也叫engine）下又有多个Host，每个Host下对应多个Context，Context下才是我们的Servlet，Tomcat为了使整个架构灵

前言  Tomcat容器最主要作用就是监听网络请求，并将请求封装成request和response对象最终交给Servlet去执行，而我们spring项目中用来供servlet调用的业务代码的入口一般就是Spring管理的Controller。而Springboot整合tomcat的话，就需要提供一个Servlet的标准实现，并将这个Servlet注册到Tomcat容器里，并且在Servlet处理请求时，能调用Spring所管理的Controller进而使用Spring容器的所有资源。所以这里最主要的几个

文章目录获取需要自动装载的组件加载组件简单一句话就是扫描META-INF/spring.factories下org.springframework.boot.autoconfigure.EnableAutoConfiguration的配置项，然后自动装载这些类这里分两步讲下整个过程：1、获取需要自动装载的组件2、加载组件获取需要自动装载的组件在启动类上会有@SpringBootApplication注解，该注解上有@EnableAutoConfiguration注解，这个注解import了Au

加载和实例化bean分以下几个重要步骤：1、根据package扫描出需要被管理的类2、将这些类封装成BeanDefinition并注册到BeanFactory容器3、实例化所有扫描到的BeanDefinition，其中包括解决循环依赖、延迟加载问题下面这张图根据Springboot启动调用链的顺序，画了这三个关键步骤被触发的时间点：1、springboot怎么根据package扫描出需要被管理的类？springboot是通过启动类上的@ComponentScan注解所指定的包路径来进行扫描的，

从《Springboot 启动流程一》到《Springboot 启动流程七》 讲完了在使用java -jar命令启动 maven打的springboot jar包的主流程，这里按顺序对主流程的关键步骤做个总结：一、从jar包里的META-INF里的MANIFEST.MF文件里配置的Main-class总方法作为总入口，自定义一个类加载器LaunchedURLClassLoader，并且指定这个类加载器负责的路径为：BOOT-INF/classes/和BOOT-INF/lib/下的所有资源，然后找到MANI

用于源码分析的代码：Github接着上一篇继续debug。上一篇已经将源码4.3的逻辑分析完了，这一篇从源码4.5处继续：public ConfigurableApplicationContext run(String... args) { //StopWatch就是一个监控程序启动时间的类，start方法表示开始计时，stop方法表示计时结束 //用于日志输出启动时间 StopWatch stopWatch = new StopWatch(); stopWatch.start(

用于源码分析的代码：Github接着上一篇继续debug。上一篇已经将源码4.3的逻辑分析完了，这一篇从源码4.4处继续：public ConfigurableApplicationContext run(String... args) { //StopWatch就是一个监控程序启动时间的类，start方法表示开始计时，stop方法表示计时结束 //用于日志输出启动时间 StopWatch stopWatch = new StopWatch(); stopWatch.start(

用于源码分析的代码：Github接着上一篇继续debug，这次看run方法里的源码，每次看的源码不贪多，慢慢嚼。上一篇已经将源码3.0的逻辑分析完了，这一篇就源码4.0处继续：public ConfigurableApplicationContext run(String... args) { //StopWatch就是一个监控程序启动时间的类，start方法表示开始计时，stop方法表示计时结束 //用于日志输出启动时间 StopWatch stopWatch = new Stop