- 博客(6)
- 收藏
- 关注
RSS订阅原创 Springboot自动配置原理
既然是springboot，通过配置类注入更符合它的身份，那么自动配置最朴素的流程就是，当我们通过坐标添加相关组件依赖时同时会有已经写好的相关组件的用来迎合自动配置创建好的自动配置相关的配置类。springboot按照约定到指定目录下找到相关配置类的路径，将配置类注入到容器，相应的配置类中的配置也同时生效。其中有两个细节，一个是springboot如何找到相关配置类的路径，这肯定是某种约定好的，一个是拿到路径后如何将配置类注入，一般手动会选择扫描配置类相关的包路径。配置类路径（配置类的全限定名称）
2024-05-05 22:39:56
185
原创 如何解决创建对象时的循环依赖问题
循环依赖：当spring容器创建A类对象或创建B类对象时，以创建A类对象为例，实例化A时需要B类对象，那就需要创建B类对象，创建B类对象时又需要A类对象，但是创建A类对象又需要B类对象，导致两个对象创建时一直等待依赖双方的对象创建出来，僵持不下，导致类似死锁的局面。spring容器创建A对象，在进行初始化时需要属性赋值时（给外部属性赋B对象），停止继续初始化，转头去容器中找是否有B对象，没有，则创建B对象，当走到属性赋值时需要A对象，发现A类和B类有循环依赖关系报错。创建A对象时未解决与B的依赖关系。
2024-04-14 23:10:40
885
原创 为什么重写hashcode要一起重写equals方法
hash值很强大，hashcode方法一个重要的功能就是我传入同一个东西时，返回给我的hash值一定是一样的，如果不重写hashcode方法，默认使用object的hashcode方法，这一原始计算hash值的方法是通过不同对象存放的内存地址计算hash值的，那么两个内容上一致逻辑上判定成一样的东西，但由于存放地址不同会产生不同的hash值，于是原始的hashcode方法无法满足我们的需求，我们必须要重写，以满足我们的需求。哈希冲突由谁来解决呢？那为什么要重写hashcode的同时重写equals呢？
2024-02-19 11:38:18
227
1
原创 字符串不可变性以及StringBuilder和StringBuffer在字符串拼接中的作用和扩容机制
在jdk1.8及以前，字符串底层存储用的是一个字符（char）类型的数组，jdk1.9之后用的是整型中的字节型（byte）数组来存储字符串。因为字符串的不可变性，字符串的拼接最终都是产生一个新的字符串，在大量拼接操作过程中就会产生大量的新字符串（临时字符串），将会短时间占用大量空间，导致空间的浪费。StringBuffer与StringBuilder拼接过程基本一致，只是它们一个线程安全效率稍低，一个非线程安全效率比较而言稍高。StringBuilder：jdk1.5，非线程安全，稍慢。
2024-02-19 11:37:42
168
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人