- 博客(138)
- 收藏
- 关注
RSS订阅原创 计算机网络学习笔记：TCP三报文握手、四报文挥手
本文详细介绍了TCP通信的建立与终止过程。在连接建立阶段，通过三报文握手确认双方的收发能力、协商参数并分配资源：客户发送SYN报文，服务端回复SYN+ACK，客户再回复ACK完成连接。在终止阶段采用四报文挥手释放连接：客户发送FIN报文，服务端回复ACK进入半关闭状态，服务端再发送FIN报文，客户回复ACK后等待2MSL时间确保连接完全关闭。文章还解释了三次握手和四次挥手的必要性，防止历史连接干扰和确保可靠终止。整个过程通过状态转换图和参数说明，清晰展示了TCP协议如何实现可靠连接管理。
2025-06-15 16:10:53
367
原创 计算机网络学习笔记：运输层概述&UDP、TCP对比
运输层位于网络层与应用层之间，为不同主机上的应用进程提供逻辑通信服务，核心功能包括进程间通信、复用分用、差错检测以及流量控制等。TCP和UDP是其两大协议，通过端口号标识进程，实现应用层与传输层的连接。 一次HTTP请求流程：用户输入域名后，DNS查询首先使用UDP协议（端口53）获取IP地址；之后HTTP请求通过TCP协议与服务器通信，完成请求响应交互。整个过程涉及运输层的复用分用机制，确保数据准确交付到目标应用进程。
2025-06-14 19:25:03
855
原创 BIO网络通信基础（TCP协议）
BIO（阻塞IO）案例展示了Java传统的阻塞式网络通信实现。服务端通过ServerSocket监听端口，在accept()和read()处会阻塞线程，直到客户端连接或发送数据；客户端主动连接后发送"Hello Server"并等待回显。时序图清晰呈现了"连接-发送-回显-断开"的交互流程。调试分析发现，阻塞发生在操作系统底层调用，JVM层面线程仍显示为RUNNABLE状态。最后提出多线程改进方案，通过线程池处理并发客户端请求，解决单线程服务端串行处理的性能瓶颈。该案
2025-06-13 21:16:24
763
原创 @Indexed原理与实战
摘要： @Indexed是Spring提供的用来加速启动速度的注解，配合spring-context-indexer依赖使用，会在编译时生成META-INF/spring.components索引文件。该文件存储了标注@Indexed的类及其注解信息。Spring在扫描组件时优先使用索引文件，减少类路径扫描的开销。@Component等注解本身已包含@Indexed，因此无需手动添加。源码分析表明，索引的生成和读取分别由CandidateComponentsIndexer和ClassPathScanning
2025-06-11 21:48:49
862
原创 @Configuration原理与实战
本文摘要： Spring框架中@Configuration与@Component注解在配置类使用上存在关键差异。实验表明，@Configuration标注类中调用@Bean方法会返回相同实例（单例），而@Component标注类每次调用将创建新实例。这种差异源于Spring对@Configuration类的特殊处理：通过CGLIB生成子类代理，在解析阶段标记配置类为"full"模式，并植入包含BeanMethodInterceptor的拦截器链。该拦截器会在方法调用时检查并维护Bean的
2025-06-10 22:02:40
971
原创 @Lazy原理与实战
Spring的@Lazy注解实现懒加载机制，可作用于类、方法、字段及参数。通过设置bean定义的lazyInit属性，在容器启动时延迟实例化，首次调用时才实际创建对象。解析阶段分为组件扫描和手动注册两种场景，最终由processCommonDefinitionAnnotations设置延迟属性。该机制通过生成代理对象实现延迟注入，既能提升启动性能，又能解决循环依赖问题（除构造器循环外），尤其在处理资源密集型Bean时效果显著。实际调用时通过TargetSource回调触发真实对象的创建与依赖解析。
2025-06-09 22:35:34
964
原创 @Import原理与实战
摘要： Spring框架的@Import注解提供了三种导入方式：1)直接导入普通类并注册为bean；2)通过ImportSelector实现类动态选择要导入的类；3)通过ImportBeanDefinitionRegistrar实现类自定义注册逻辑。解析过程由ConfigurationClassPostProcessor处理，在refresh阶段的invokeBeanFactoryPostProcessors中完成，分别针对不同类型采用递归解析策略。其中ImportSelector的处理可能延迟进行，而Im
2025-06-08 19:58:55
654
原创 彻底理解Spring三级缓存机制
Spring解决循环依赖问题的关键在于三级缓存机制，包括一级缓存存放完整单例对象、二级缓存存放早期实例化对象、三级缓存保存单例工厂。当存在AOP代理需求时，三级缓存确保相互引用的Bean能获得同一代理对象实例。若仅使用二级缓存，会导致某些Bean持有未经AOP处理的原始对象，而其他Bean持有代理对象，造成不一致。通过代理工厂模式示例证明，AOP会生成新代理对象而非修改原引用，因此早期注入的对象不会自动转为代理对象。三级缓存保证了循环依赖场景下所有Bean都能获得正确的代理实例。
2025-06-01 21:40:18
1032
原创 Listener method could not be invoked with the incoming message
在使用 RabbitMQ 进行消息传递时，生产者发送的消息无法被消费者正确反序列化，导致监听方法调用失败。问题根源在于未配置 RabbitMQ 使用 JSON 消息转换器，Spring Boot 默认使用了 SimpleMessageConverter，无法将 JSON 数据反序列化为目标对象。解决方案是在配置类中显式使用 Jackson2JsonMessageConverter，为 RabbitTemplate 和 SimpleRabbitListenerContainerFactory 设置该转换器，确
2025-05-18 17:40:32
650
原创 Seata AT模式数据库隔离级别与锁设计
一阶段：业务 SQL 正常执行并记录操作前镜像与后镜像（undo_log）二阶段提交：异步清除 undo_log，不影响业务性能二阶段回滚：根据 undo_log 恢复原始数据为了实现这些能力，Seata 需要同时在应用层和数据库层建立一套“软隔离+逻辑锁”的机制，以避免脏写和并发冲突。
2025-05-03 19:08:54
836
原创 Seata RM的事务提交与回滚源码解析
当TC接收到TM的提交/回滚请求后，在处理好自身相关的逻辑后，会向每一个分支事务RM发送请求，驱动RM执行实际的提交/回滚业务逻辑：微服务端处理对应请求，是在在全局事务的一阶段中，业务 SQL 已经通过本地事务提交完成，Spring 的事务已结束。实际操作：删除undo_log表中与本次事务相关的日志记录。实现机制：使用阻塞队列存储待处理的提交上下文（借助定时任务线程池（AsyncWorker）周期性调度任务；结合异步编排机制，确保即使提交队列满时也能自动重试。
2025-05-03 16:14:03
893
原创 Seata RM注册分支事务源码解析
微服务端执行具体业务逻辑的部分，通常被称为事务的参与者RM。需要与Seata服务端TC进行通信，上报并成为分支事务。在微服务架构中，事务参与者在执行本地数据库操作并将事务设置为非自动提交（构建前后镜像（Before/After Image）用于回滚。写入 Undo Log（用于将来回滚）。向发起注册分支事务的请求。如果分支注册成功，提交本地事务；否则回滚并上报一阶段失败。TC（事务协调者）尝试获取全局锁，即向lock_table表插入锁记录。注册分支事务元信息到。
2025-05-03 11:45:01
915
原创 Seata客户端代理增强核心源码解析
当调用到标注了注解的方法，最终会执行到的execute方法：这是一个标准的事务编程模型。是执行目标业务代码的逻辑，其中就包含了如何生成前置镜像、后置镜像、记录undolog、向TC注册分支事务的逻辑。Seata 通过对客户端数据源进行代理增强，实现了在 SQL 执行前后生成前置镜像（Before Image）和后置镜像（After Image），并构建 UndoLog，以支持分布式事务的自动回滚能力。
2025-05-02 17:09:42
1326
原创 Seata服务端同步提交事务核心源码解析
本篇介绍Seata服务端TC如何驱动RM提交事务。释放锁，删除lock_table的记录。将表中的状态改为2。遍历并驱动所有的分支事务提交（Phase Two 提交），每个分支由 TC 向对应的 RM 发起提交请求。根据各分支事务返回的状态进行处理：若分支返回，表示该分支已成功提交，TC 会调用方法：清理内存中的，并删除该分支在和lock_table中的记录。若分支返回，表示分支提交失败且不可重试，TC 会将全局事务状态设置为（属于结束状态），并清理内存中的全局事务会话。
2025-05-01 21:14:37
976
原创 Seata服务端开启事务核心源码解析
Seata服务端作为TC角色，用于接收客户端标注了也就是TM角色的开启事务，提交/回滚事务请求，维护全局和分支事务的状态，并驱动客户端的RM角色真正地去执行开启事务，提交/回滚事务操作。服务端与客户端交互的类，是在顶级接口中，定义了开启，提交/回滚事务的统一处理模板，接收客户端的请求：重写了各自的handle方法，加入了自己的处理逻辑，实际上也是委托子类去完成具体的逻辑的。
2025-05-01 17:11:49
740
原创 Seata客户端事务模型源码解析
的execute方法，是Seata客户端事务模型的体现：本篇主要介绍客户端开启事务，执行事务，提交/回滚与服务端的交互。Seata 客户端（微服务端）在事务处理上遵循与传统事务编程模型一致的理念，这与 Spring 的编程风格保持高度契合。不同之处在于：事务的开启、提交以及回滚并非本地直接完成，而是通过与 Seata 事务协调器（TC）进行通信，由服务端统一调度管理。在整个事务生命周期中，XID（全局事务ID） 是唯一标识符，作为贯穿始终的上下文信息，它驱动各个参与的微服务执行具体的分支事务逻辑。
2025-05-01 11:27:10
638
原创 Seata客户端@GlobalTransactional核心源码解析
Seata是阿里开源的分布式事务解决方案。在Spring传统的事务中，开启事务，执行事务，回滚/提交事务，统一由Spring进行管理，向数据库发起指令。而分布式事务中，分为了客户端（微服务端）和服务端（Seata）、注册中心（通常使用Nacos）这三个部分。Nacos提供了服务注册与发现，以及管理Seata配置的作用。无论是开启事务，执行事务，还是提交事务，都不是单个微服务内部自己决定的，而是统一向服务端发起请求，由服务端进行一系列的处理后，再向微服务端发起请求，驱动微服务端执行操作。
2025-04-30 21:31:51
1006
原创 Sentinel规则持久化push模式改造
Sentinel规则持久化有两种模式，一种是前篇中提到的本地存储的pull模式，主要涉及到了和。前者的目的是为了定时获取配置文件的改动，并且同步到微服务端的内存。后者的目的则是将sentinel控制台推送的配置文件，写入到本地磁盘文件或数据库/redis等中间件中。因为微服务端的内存，需要通过定时任务拉取本地的变更病同步，所以称之为拉模式如果用户直接对本地文件进行的修改，那么同步至少需要3s的时间间隔。控制台在推送配置文件时，带有ip和端口。
2025-04-26 15:56:34
1206
原创 Nacos配置中心客户端处理服务端配置信息源码解析
Nacos配置中心，对于页面上用户操作的配置信息，实际上是使用了推拉结合的模式。服务端将配置信息推送到客户端。客户端主动向服务端发起请求拉取配置信息。本篇介绍服务端将配置信息推送到客户端，客户端的处理方式在 Nacos 配置中心中，服务端在检测到配置内容发生变更后，会客户端推送变更通知。客户端收到推送通知，并不会直接处理变更配置内容，而是通过一系列异步机制完成完整的配置拉取与刷新流程。
2025-04-20 12:12:55
966
原创 Nacos配置中心服务端源码解析
Nacos除了可以实现服务的注册与发现，还具有统一进行配置管理</</</可以将项目中的配置文件，转移到配置中心：同时需要在项目的resource目录下，加入或spring:name: spring-cloud-nacos-config-demo #微服务名称# active: dev #加载开发环境的配置文件 mall-user-config-demo-dev.ymlcloud:nacos:config: #配置nacos配置中心地址。
2025-04-19 16:04:24
879
原创 Sentinel规则持久化pull模式核心源码解析
在Sentinel的控制台（服务端）设置了流控、系统等规则后，点击保存按钮，会调用服务端的接口。Sentinel默认会将规则在服务端的内存中保存一份，然后推送到客户端，默认情况下也是推送到客户端的内存中。因为是保存在内存中，所以应用重启后，上一次配置的规则就会消失，需要重新进行配置。</</</</将规则更新到本地文件或数据库中。同时监控线程定期读取本地文件或数据库中的配置信息，如果发生变化，就会更新最新的逻辑到内存中：图片来源：图灵学院在 Sentinel 的规则持久化Pull 模式。
2025-04-13 16:35:40
1044
原创 Sentinel核心算法解析の漏桶算法
在Sentinel中，流控效果有快速失败预热和排队等待。其中排队等待的实现，利用的是漏桶算法。Sentinel 的排队等待机制采用了漏桶算法来实现流量控制。控制请求处理的速率，而不是请求到达的速率。桶的容量是固定的，当短时间内大量请求突发到达时，如果超出系统处理能力，部分请求将被直接拒绝。而系统会以固定速率从“桶”中取出请求进行处理，从而达到匀速限流的目的。
2025-04-12 16:23:39
1089
原创 Sentinel核心算法解析の滑动窗口算法
在Sentinel中，流控效果有快速失败预热和排队等待。其中快速失败的统计，利用的就是滑动窗口算法。Sentinel 流控中的快速失败模式，基于其实现的一套滑动窗口算法，支持以 QPS（每秒请求数）或线程数作为控制指标。固定窗口算法与滑动窗口算法。其中，固定窗口实现简单，但存在精度较低和边界问题严重的缺陷。滑动窗口是对固定窗口的改进方案：将统计周期进一步细分为多个小窗口，并以固定的时间间隔向前滑动，从而大幅减轻边界问题。窗口越小，精度越高，边界问题越不明显，但也意味着更高的内存开销。
2025-04-12 14:36:29
761
原创 Sentinel核心源码分析（下）
在上篇中，主要记录了Sentinel与Spring Boot的整合，以及责任链的构建，执行的过程。。在校验不通过，或者触发熔断降级时，通常会抛出异常：抛出的是SystemSlot抛出的是FlowSlot抛出的是抛出的是这四个Sentinel自定义的异常，都有一个共同点，是的子类。抛出的异常，又会被责任链中的节点捕获，并执行一系列的逻辑，然后继续向上抛出。最后会被最外层的第一类是继承了的异常，通常由限流、熔断降级等规则触发，表示“资源访问被拒绝”；
2025-04-07 21:22:40
909
原创 Sentinel核心源码分析（上）
Sentinel作为Spring cloud alibaba中流控的组件，在微服务架构中也有广泛的应用。其核心源码主要体现在客户端。客户端在启动时，和Nacos类似，也会将自己的信息注册到服务端。而服务端的页面上配置各种规则时，实际上也是将信息发送到了客户端。我们最常使用的注解：底层也是基于AOP + 责任链模式实现的。**Sentinel的难点不在于处理流程，而在于限流的算法。**本篇仅介绍Sentinel责任链的核心流程。
2025-04-06 17:36:12
991
原创 Nacos注册中心AP模式核心源码分析（集群模式）
server:port: 9002spring:cloud:nacos:discovery:# 指定nacos server的地址# 指定集群名称metadata:当客户端启动完成后，集群中8847所在的服务端，首先获取到了客户端实例，随后88678857也同步获取到了客户端实例。客户端只向集群中的某一台机器进行了注册，集群中的其他节点是如何感知到的？如果客户端下线，或者健康状态发生改变，其他节点又是如何同步的？
2025-04-05 17:45:14
696
原创 Nacos注册中心AP模式核心源码分析（单机模式）
Nacos注册表架构：Nacos中注册表是一个重要的概念，也是Nacos存储服务实例的数据结构，源码中体现在的serviceMap属性中。例：public = {第一层 Map：Map<String, Map<String, Service>>键（String）：public → 代表命名空间（namespaceId）。值（Map<String, Service>） → 该命名空间下的所有服务。第二层 Map：Map<String, Service>
2025-04-04 17:09:04
690
原创 Spring Boot自动配置原理解析
在常规的SSM项目中，通常需要用户自己去进行Spring、Spring MVC、Mybatis的整合，以及Tomcat的配置。的依赖，在中就已经完成了Spring、Spring MVC、Tomcat的整合，通常被称为自动配置。而完成自动配置的关键，在于启动类上的注解：是一个复合注解，其中包含了和Spring Boot的@SpringBootConfiguration：标记当前类是配置类，并且将当前类加入Spring 容器。
2025-03-29 17:58:19
1199
原创 MyBatis源码分析のSql执行流程
/将xml构筑成configuration配置类//解析xml，注册成SqlSessionFactory在上面的案例中，真正执行sql的核心是**User user = session.selectOne(“com.example.mybatis.mapper.UserMapper.selectById”, 1);**这一行代码。准备阶段：体现是方法，首先创建事务对象（默认的是JDBC的事务），创建执行器，并通过装饰器模式，包装到中。还会进行插件逻辑的处理。如果有插件，就会创建。
2025-03-16 15:19:43
913
原创 MyBatis源码分析の配置文件解析
本篇主要介绍MyBatis源码中的配置文件解析部分。MyBatis是对于传统JDBC的封装，屏蔽了传统JDBC与数据库进行交互，组装参数，获取查询结果并自己封装成对象的繁琐过程。原生MyBatis首先需要配置> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!</> <
2025-03-15 21:07:26
656
原创 Spring MVC源码分析の请求处理流程
在Spring MVC中，请求处理的关键是的doDispatch方法：其中包含了@RequestBody,@ResponseBody等注解的解析，参数的适配，方法拦截器的执行，目标方法的执行，返回值处理，以及异常处理等逻辑。Spring MVC整体请求流程，本篇只简单地进行主要流程的分析，诸如如何解析参数，解析返回值，渲染视图等不在此列。客户端请求↓↓↓HandlerExecutionChain（包含Handler和拦截器）↓调用拦截器 preHandle()↓。
2025-03-12 22:17:45
832
原创 Spring MVC源码分析のinit流程
本篇介绍Spring MVC 的初始化流程，源码的体现是HttpServletBean的init方法。通常Spring MVC的项目，需要打成war包，部署在Tomcat服务器上，也就是Spring MVC通常需要配合Tomcat使用，当然也可以使用Jetty、Undertow 等。Spring MVC的源码，主要是分为两部分，第一部分是Tomcat启动时，Spring MVC上下文和容器的初始化。第二部分则是请求到达Tomcat，进行路径映射，转发到然后进行处理并且返回的流程。
2025-03-09 21:37:13
922
原创 Spring源码分析の事务（上）
本篇重点介绍原生Spring中的事务相关原理源码。包括注解，事务的挂起与恢复，提交与回滚，隔离级别。在原生的Spring中，如果想要使用事务，需要先在配置类中注册和DataSource的bean。同时需要加上注解。
2025-03-08 16:33:15
1001
原创 Spring源码分析のAOP
在Spring中，AOP通常是通过动态代理实现的，通过运行时增强的机制，以实现在目标代码执行前后的统一的逻辑。而Spring将两大动态代理，封装成为了，在@Component同时在/*** 方法执行前后执行*//***/@OverrideSystem.out.println("方法执行前");System.out.println("方法执行后");/*** 抛出异常后执行*/在中添加切面，其中Advisor是Advice + Pointcut组合，等于切入点+切面。
2025-03-05 22:23:22
679
原创 Spring源码分析の配置类解析
在Spring的注解模式中，通常在构造时需要传入一个配置类，标注有扫描的类路径，以及注解。前篇中提到，解析配置类是在refresh方法的中，通过如图的三行关键代码，从容器中拿到后置处理器，并执行其中的方法完成的。ConfigurationClassPostProcessor 解析配置类获取当前中的所有 Bean 名称。遍历这些bean名称，找到标注了注解的类。按照@Order注解（如果有）的值对标注了注解的类进行排序。创建解析器，用于解析。循环解析配置类parse方法解析类。
2025-03-02 11:44:21
1160
原创 Spring源码分析のregister&refresh全过程（下）
本篇接上篇，继续介绍Spring的refresh方法的全流程。上篇已经介绍了到的流程，本篇从继续。
2025-03-02 10:19:48
1173
原创 Spring源码分析のregister&refresh全过程（上）
本篇通过，介绍Spring在启动的全流程。是的一个具体实现，支持配置类+注解模式。在构造调用父类的构造方法。register方法。refresh方法。本篇主要介绍register方法和refresh的部分源码。
2025-03-01 22:11:31
1147
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人