mini-spring

mini-spring copied to clipboard

各位小伙伴，我是本项目的作者，想收集下问题和建议，欢迎畅所欲言。

104

如题。**如果提bug，请新建issue。**

DerekYRC

属性占位符替换时增加判断

2

当前属为`String`类型时，会尝试使用`resolvePlaceholder`来进行占位符替换，对于直接使用`value`来指定属性值的属性不会有任何作用：  但是这里没有添加判断，导致重复添加`PropertyValue`，虽然不会影响后面bean的创建，但是属性列表有重复项也是一种**冗余**，增加了一定的判断之后就不会出现冗余：  具体请看：#69

zzziCode

当前属为`String`类型时，会尝试使用`resolvePlaceholder`来进行占位符替换，对于直接使用`value`来指定属性值的属性不会有任何作用：  但是这里没有添加判断，导致重复添加`PropertyValue`，虽然不会影响后面bean的创建，但是属性列表有重复项也是一种**冗余**：  增加了一定的判断之后：  出现问题的代码在： https://github.com/DerekYRC/mini-spring/blob/ef07ca1105b4c57b70d63a50425a0de6d6b5814a/src/main/java/org/springframework/beans/factory/PropertyPlaceholderConfigurer.java#L78C5-L78C88

zzziCode

AbstractAutowireCapableBeanFactory#doCreateBean 调用 getSingleton不理解

4

原代码是 `if (beanDefinition.isSingleton()) { //如果有代理对象，此处获取代理对象 exposedObject = getSingleton(beanName); addSingleton(beanName, exposedObject); }` spring已经在 initializeBean后 bean 不是已经被替换为 代理对象了吗，如果这里再调用getSingleton 方法，就会再生成一个新的代理对象。这段逻辑不理解

jaxlove

有无静态页面方便阅读

1

例如：https://javaguide.cn/

youmu1

初始化与销毁方法中，只避免销毁方法执行两次而初始化方法没有相关的判断

1

DisposableBeanAdapter#destroy() 会通过判断避免 bean 继承自 DisposableBean ，且自定方法与 DisposableBean 方法同名导致销毁方法方法执行两次，代码如下 ```java @Override public void destroy() throws Exception { if (bean instanceof DisposableBean) { ((DisposableBean) bean).destroy(); } //避免同时继承自DisposableBean，且自定义方法与DisposableBean方法同名，销毁方法执行两次的情况 if (StrUtil.isNotEmpty(destroyMethodName) && !(bean instanceof...

Whale-lyi

bean容器中注册BeanDefinition后，使用bean时才会实例化

1

bean容器作为BeanDefinitionRegistry和SingletonBeanRegistry的实现类，具备两者的能力。**向bean容器中注册BeanDefinition后，使用bean时才会实例化。** 这句话个人感觉是不是不太准确呢 在Spring容器中，有两种主要的Bean作用域： Singleton（单例）作用域：对于单例作用域的Bean，它们在容器启动时（或懒加载情况下，在首次使用时）被实例化，并在容器的整个生命周期中只存在一个实例。这意味着无论何时从容器中请求这个Bean，都会获得同一个实例。单例Bean在容器启动时被初始化。 Prototype（原型）作用域：对于原型作用域的Bean，它们在每次被请求时都会创建一个新的实例。这意味着每次从容器中请求这个Bean时都会得到一个不同的实例。原型Bean在容器启动时并不会被初始化，而是在每次请求时才会创建新实例。

bluehr

关于循环依赖

6

我想问一下博主，如果当两个prototype类型的对象互相引用的话，循环依赖是不是还存在呢？我感觉您的代码只能解决单例的循环依赖

dajiao918

关于ConfigurableBeanFactory和ConfigurableListableBeanFactory

1

作者你好，我在查看代码的过程当中，发现ConfigurableBeanFactory和ConfigurableListableBeanFactory这两个接口当中都存在addBeanPostProcessor接口方法，但是ConfigurableBeanFactory和ConfigurableListableBeanFactory这两个接口存在继承关系，想请问作者这里是否存在冗余呢？能否去掉ConfigurableListableBeanFactory中的addBeanPostProcessor接口方法呢？  

Linweixinyo

有代理对象解决循环依赖这节内容有些不理解的内容

6

作者大大好，整个项目快看到尾声了，在这节内容上有些问题。 分支：circular-reference-with-proxy-bean 1. 解决有代理对象的循环依赖问题，因为上一节中，singletonObjects(一级缓存)和earlySingletonObjects(二级缓存)没办法解决有代理对象循环依赖的问题，所以这节中引入了singletonFactory(三级缓存)，在代码中的体现就是`AbstractAutowireCapableBeanFactory#doCreateBean()`方法，这个方法在75行的时候，通过bean复制一个finalBean对象，然后放入singletonFactories三级缓存中，接着在第104行通过`getSingleton(beanName)`这个方法就是会先从一级缓存找，然后接着二级缓存找，最后再三级缓存中找，对应到项目实际debug的过程中，实际上从三级缓存中去获取，就是调用了`singletonFactory.getObject()`该方法。也就是上面75行存入的三级对象的getObject方法，最终返回这个代理对象。这是我的理解。那这样的话问题就来了，就是在整个bean的生命周期，还有其他很多的操作步骤，比如BeanPostProcessor修改属性值，填充属性，以及初始化前后的处理，那么实际上对应的代码就是刚刚上面提到75行和104行中间的很多操作步骤。也就是说我们最终获取到的代理bean是根据一开始75行存入三级缓存中的finalBean。而在这个之后，代码中的很多步骤都是对原先bean去做的操作。那75-104行在bean生命周期内所做的操作岂不是对代理对象都不生效了？那代理对象的属性什么的设置是不是就都有问题了。 2. 另一个问题还是在doCreateBean()方法内，就是获取到代理对象后，105行的代码`addSingleton(beanName, exposedObject)`，这里紧接着将对象放入一级缓存中，并将二级三级缓存进行清空，结合104行的代码，整个过程看起来像是获取到代理对象后，先放入二级缓存中，然后将三级缓存中的清空，接着再放入一级缓存中，再将二级三级缓存清空。所以这里看起来好像放入二级缓存中什么也没操作，那不如直接放入一级缓存，因为放入二级缓存后什么都没操作就又取出来放入一级缓存中了，这里不是太理解。 这节内容debug过程中很多嵌套的，所以理解起来不是很容易，可能自己陷入了某个单独流程上，没办法从整体上去理解。再次感谢作者，学习到了很多东西

ccl125