- 博客(110)
- 收藏
- 关注
RSS订阅原创 Spring Boot自动配置原理解析
在常规的SSM项目中，通常需要用户自己去进行Spring、Spring MVC、Mybatis的整合，以及Tomcat的配置。的依赖，在中就已经完成了Spring、Spring MVC、Tomcat的整合，通常被称为自动配置。而完成自动配置的关键，在于启动类上的注解：是一个复合注解，其中包含了和Spring Boot的@SpringBootConfiguration：标记当前类是配置类，并且将当前类加入Spring 容器。
2025-03-29 17:58:19
1110
原创 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
870
原创 MyBatis源码分析の配置文件解析
本篇主要介绍MyBatis源码中的配置文件解析部分。MyBatis是对于传统JDBC的封装，屏蔽了传统JDBC与数据库进行交互，组装参数，获取查询结果并自己封装成对象的繁琐过程。原生MyBatis首先需要配置> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!> <!</> <
2025-03-15 21:07:26
618
原创 Spring MVC源码分析の请求处理流程
在Spring MVC中，请求处理的关键是的doDispatch方法：其中包含了@RequestBody,@ResponseBody等注解的解析，参数的适配，方法拦截器的执行，目标方法的执行，返回值处理，以及异常处理等逻辑。Spring MVC整体请求流程，本篇只简单地进行主要流程的分析，诸如如何解析参数，解析返回值，渲染视图等不在此列。客户端请求↓↓↓HandlerExecutionChain（包含Handler和拦截器）↓调用拦截器 preHandle()↓。
2025-03-12 22:17:45
775
原创 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
884
原创 Spring源码分析の事务（上）
本篇重点介绍原生Spring中的事务相关原理源码。包括注解，事务的挂起与恢复，提交与回滚，隔离级别。在原生的Spring中，如果想要使用事务，需要先在配置类中注册和DataSource的bean。同时需要加上注解。
2025-03-08 16:33:15
975
原创 Spring源码分析のAOP
在Spring中，AOP通常是通过动态代理实现的，通过运行时增强的机制，以实现在目标代码执行前后的统一的逻辑。而Spring将两大动态代理，封装成为了，在@Component同时在/*** 方法执行前后执行*//***/@OverrideSystem.out.println("方法执行前");System.out.println("方法执行后");/*** 抛出异常后执行*/在中添加切面，其中Advisor是Advice + Pointcut组合，等于切入点+切面。
2025-03-05 22:23:22
643
原创 Spring源码分析の配置类解析
在Spring的注解模式中，通常在构造时需要传入一个配置类，标注有扫描的类路径，以及注解。前篇中提到，解析配置类是在refresh方法的中，通过如图的三行关键代码，从容器中拿到后置处理器，并执行其中的方法完成的。ConfigurationClassPostProcessor 解析配置类获取当前中的所有 Bean 名称。遍历这些bean名称，找到标注了注解的类。按照@Order注解（如果有）的值对标注了注解的类进行排序。创建解析器，用于解析。循环解析配置类parse方法解析类。
2025-03-02 11:44:21
1123
原创 Spring源码分析のregister&refresh全过程（下）
本篇接上篇，继续介绍Spring的refresh方法的全流程。上篇已经介绍了到的流程，本篇从继续。
2025-03-02 10:19:48
1146
原创 Spring源码分析のregister&refresh全过程（上）
本篇通过，介绍Spring在启动的全流程。是的一个具体实现，支持配置类+注解模式。在构造调用父类的构造方法。register方法。refresh方法。本篇主要介绍register方法和refresh的部分源码。
2025-03-01 22:11:31
1121
原创 Spring源码分析の构造方法推断
在Spring中，如果某个bean只有一个无参的构造方法，那么就会根据该构造方法进行实例化：但是如果存在多个呢？以及手动使用@AutoWired注解，乃至更复杂的情况？这里就涉及到Spring对于构造方法的推断。构造方法的推断，是属于bean生命周期中的实例化阶段。
2025-02-27 21:57:43
966
原创 Spring源码分析の循环依赖
两个bean中互相持有对方作为自己的属性。类似于：两个bean中互相持有对方作为自己的属性，且在构造时就需要传入：类似于：在某个bean中注入自身：其中第二种构造方法的循环依赖一般情况下是无解的，除非加上@Lazy注解。本篇重点分析第一种循环依赖Spring是如何解决的。
2025-02-25 22:03:19
940
原创 Spring源码分析の依赖注入（doResolveDependency）
无论是@AutoWired的AutowiredMethodElement还是AutowiredFieldElement，或者是@Bean的autowiredbyName、autowiredbyType方法，最终都会去调用doResolveDependency方法，该方法是Spring依赖注入中的核心方法在解析@Value注解如果依赖项标注了@Value注解，Spring 会解析该注解中的值，并通过合适的类型转换器（）将其转化为目标类型。如果解析成功，直接返回该值作为依赖。
2025-02-23 17:54:53
892
原创 Spring源码分析の依赖注入（@AutoWired模式）
在Spring中，进行依赖注入最常见的方式是@AutoWired和@Resource。其中默认按类型（byType）查找，如果找到多个匹配的Bean，则按名称（byName）查找。而@Resource是先根据名称查找，如果（根据名称）查找不到，再根据类型进行查找。@AutoWired在源码中的体现，主要在于：在实例化后，依赖注入前预先寻找注入点在实例化后，初始化前，进行注入Spring 在实例化后，初始化前，扫描标记了该注解的属性或者方法，作为注入点缓存。
2025-02-22 19:33:41
1039
原创 Spring源码分析の依赖注入（byName&byType模式）
在Spring中，依赖注入（DI）可以通过xml和注解的方式实现。而注解模式也分为@AutoWired@Resource等以及或。本篇重点分析注解模式中的byName&byType。如果需要使用 @Bean(autowire = Autowire.BY_NAME) 或 @Bean(autowire = Autowire.BY_TYPE) 的模式，则需要确保对应的 bean 属性有 setter 方法。按类型匹配：Spring 会根据 setter 方法的入参类型匹配容器中的 bean 类型。
2025-02-22 16:49:00
684
原创 Spring源码分析のBean创建流程（下）
在doGetBean方法中，如果即将获取的bean不存在，无论是何种作用域的bean，最终都会调用createBean方法去创建bean。createBean方法是bean创建流程中的重要方法。将beanName转换为bean的class对象（通过jvm加载类得到class）处理当前 bean 配置了方法重写的情况通过反射将bean实例化，并且包装成BeanWrapper。如果定义了工厂方法，则通过工厂方法来创建 Bean。如果定义了 Supplier，则通过该提供者获取 Bean 实例。
2025-02-19 22:22:11
856
1
原创 Spring源码分析のBean扫描流程
原生的Spring在构造时，会调用refresh方法。其中就包含了扫描所有包含@Component及其子注解的类（注解模式）或解析xml配置文件（xml模式）将其注册为的逻辑。将传入参数的路径进行转换，转换为classpath的格式。获取路径下的所有资源文件（.class）。通过MetadataReader 解析.class的元数据信息。判断被扫描到的类上是否存在@Component及其子注解，并且有无需要排除某个类的情况。还需要判断类上是否加入了@Conditional注解。
2025-02-16 11:47:40
902
原创 线程池ThreadPoolExecutor源码分析（下）
如果存在一种情况，在创建核心线程的过程中，还没有创建到核心线程数量大小的线程，此时已经有核心线程完成了自己的任务，新的任务会。如果当前的核心线程数为10，因为阻塞队列已满，又创建了2个应急线程，在任务都被消费执行完成的情况下，中的state，只有可能是-1（构造中的初始值），0（解锁），1（加锁）三种状态。方法，表示要关闭线程池，不接受新任务，但是要把阻塞队列中剩余的任务执行完。答案是否定的，只要当前线程池中的线程数，小于核心线程，就会尝试创建线程。shutdownNow的返回值，是阻塞队列中剩余的任务。
2025-02-07 19:54:46
725
原创 线程池ThreadPoolExecutor源码分析（上）
线程池是一种基于资源复用思想的池化技术。由线程池统一地去创建，回收线程，避免频繁地手动创建，销毁线程，以减少开销。阿里开发手册强制规范10,200,30,i < 10;i++) {});注意：本篇中提到的线程池，是JUC包下的线程池，非Tomcat的实现，Tomcat的线程池做过二次开发，和JUC的实现细节有所区别。
2025-02-05 19:39:04
948
原创 LinkedBlockingQueue源码分析
LinkedBlockingQueue是一种单链表的阻塞队列，和前篇提到的ArrayBlockingQueue相比，它是。当然无界不是真正的没有大小限制，最大长度是int类型的最大值，因为很难达到，所以称为无界。 在LinkedBlockingQueue内部，有两把锁，是对ArrayBlockingQueue读写共用锁的改进，使得不同线程在LinkedBlockingQueue进行读-写操作不互斥。（可以一个线程存，另一个线程取）。 同时LinkedBlockingQueue的count属性，使用
2025-02-03 11:58:35
267
原创 ArrayBlockingQueue源码分析
阻塞队列，是针对一般而言的队列数据结构，增加了阻塞作为生产者方的线程，向队列中存放元素时，如果队列已满，则生产者陷入阻塞，并且唤醒消费者去进行消息的消费。作为消费者方的线程，从队列中获取元素时，如果队列已空，则消费者陷入阻塞，并且唤醒生产者去进行消息的生产。完美契合了生产者-消费者模型，并且阻塞队列作为第三方进行了两者间的解耦操作。继承体系：Collection是List和Set集合的顶级接口，定义了集合共有的行为Queue接口继承了Collection，在其中增加了作为队列的特有方法。
2025-02-02 22:05:40
651
原创 ReentrantReadWriteLock源码分析
（读写锁）是对于（可重入锁）的一种改进，在可重入锁的基础上，进行了读写分离。适用于读多写少的场景，对于读取和写入操作分别加锁。其中读取与读取操作同步，读取和写入，写入和写入操作互斥。并且支持写锁降级的机制。实现了ReadWriteLock接口，定义了读锁和写锁的模版方法，在ReentrantReadWriteLock分别进行实现（ReentrantReadWriteLock内部实现了两把锁）。sync属性，实现了AQS的规范。
2025-02-01 22:11:36
793
原创 ThreadLocal源码解析
是线程私有的，独立初始化的变量副本。存放在和线程进行绑定的中。的内部类Entry，是一个键值对的结构，key是对象，value是某个变量在某个时刻的副本。并且Entry继承了类，使其key（对象）成为弱引用，如果未正确使用remove方法，可能会导致内存泄漏问题。构造entry对象时，key使用父类的方法，被包装成弱引用。是的一个静态内部类：但是其初始化的操作，是绑定在每个线程中的，作为线程对象的属性，随着线程对象的加载而初始化。并且的内部，是一个entry键值对数组的形式。也有初始容量和扩容机制。
2025-01-30 21:17:16
1080
原创 彻底理解JVM常量池
这里的hello是从哪来的？找不到目标，就放一个在字符串常量池中，然后返回调用intern方法者的引用，此时的s1.intern指向的是堆中s1指向的a（s1.intern和s1指向同一个对象）intern()方法，优先去字符串常量池找目标，如果能找到就直接返回字符串常量池中字符串的引用，此时的s1.intern指向的是字符串常量池中的a的引用。在执行第二行代码时，位于堆空间的字符串常量池中，并没有hello字面量，会将hello的引用放入字符串常量池中，并且返回调用intern方法者的引用。
2025-01-25 17:24:48
1019
原创 彻底理解CMS&G1垃圾回收器、三色标记算法
但是它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，并且可能存在上一次垃圾回收没有执行完，垃圾回收又被触发的情况（因为是一边垃圾回收，用户线程还在执行，不停地产生新的对象），此时会触发full gc 进入STW，用单线程的垃圾回收器进行收集。法，即在引用置空之前，通过写屏障操作对其进行记录（只记录引用），在重新标记阶段，将记录中的引用全部标记为黑色，不被清理。很明显经过上面的过程，D实例已经被A所引用，但是由于A被标记成了黑色，在重新标记阶段是不会进行再次标记的。
2025-01-25 15:40:45
1086
原创 彻底理解JVM类加载机制
自定义类加载器，需要继承，并且重写其中的findClassloadClasstry{//defineClass将一个字节数组转为Class对象，这个字节数组是class文件读取后最终的字节数组。//初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoader//D盘创建test/com/tuling/jvm几级目录，将User类的复制类User1.class丢入该目录。
2025-01-16 21:55:41
968
原创 MySQL多版本并发（MVCC）机制
MVCC是为了解决多个事务并发执行时可能出现的数据一致性和冲突问题而产生的机制。如果用传统方式解决数据一致性和冲突问题，可以通过加锁，但是无论是乐观锁还是悲观锁，对于性能都有一定的损耗，尤其是在并发冲突较多的情况下。而MVCC对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥。MySQL的读已提交和可重复读隔离级别下都实现了MVCC机制。
2025-01-12 11:20:44
1094
原创 MySQL锁机制
MySQL的锁机制是数据库并发控制的重要组成部分，目的是防止多个事务对数据的并发访问乐观锁、悲观锁。表锁、页锁、行锁。读锁、写锁、意向锁。间隙锁、临键锁。锁的两个重要概念是粒度与冲突，锁的粒度指的是锁作用的范围，粒度越小，锁的冲突概率越低，系统的并发能力越强；但管理锁的开销也会增加。锁冲突是指两个或多个事务试图以不兼容的方式访问相同的数据。例如，一个事务试图加排他锁，而另一个事务已经持有该数据的共享锁。LOCK TABLES：手动锁定一个或多个表，可以加共享锁或排他锁。
2025-01-11 15:43:17
621
原创 MySQL事务
简单来说，事务是指对于一组操作的集合，这些操作要么全部执行，要么全部不执行，确保数据的一致性和完整性。事务的核心目标是保证在多个操作过程中，即使发生故障，数据也能保持一致的状态。事务并非是数据库特有的概念，操作系统中也有事务的概念，比如文件系统中的原子操作，要么执行完毕，要么不执行。以及在在分布式系统中，事务用于保证跨多个系统或服务的操作的一致性。脏读是指一个事务读取了另一个事务尚未提交的数据。如果另一个事务回滚了，这个“脏”数据就不再有效，但第一个事务已经读取了它，导致数据的不一致。幻读。
2025-01-11 14:33:32
961
原创 MySQL索引优化
这条语句，实际只有name会走索引，因为name是右侧模糊匹配，得到的结果是不确定的，name字段过滤完，得到的索引行里的age和position是无序的，无法很好的利用索引。而5.6引入索引下推后，上面的sql在获取到联合索引里匹配到名字是 ‘LiLei’ 开头的索引后，还会对age和position进行过滤，用过滤后剩下的索引对应的主键id再回表查整行数据。综上所述，对于order by的优化，尽量在索引列上完成排序，遵循索引建立（索引创建的顺序）时的最左前缀法则。命令，查看rows字段的值。
2025-01-05 17:48:15
1133
原创 MySQL性能优化explain关键字详解
当 from 子句中有子查询时，table列是 格式，表示当前查询依赖 id=N 的查询，于是先执行 id=N 的查询。因为一旦范围条件被处理，索引的扫描只能停止在范围条件的位置，因此后面的列（如 position）的条件必须通过其他方式处理，可能会导致索引的部分失效或者需要回表扫描。如果对索引列进行函数计算，例如截取，转换，也就是索引字段发生了改变，则在B+树的数据结构中就无法匹配，导致索引失效。即上面的sql语句，依照优先级，最先执行的一定是from后面的子句，因为前面的查询条件都是依赖此。
2025-01-05 14:38:17
1014
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人