学习日记-spring-day37-6.25

知识点

核心内容

重点

Spring框架中utl名称空间创建List

通过utl名称空间创建并管理集合对象，实现数据复用

utl list与普通list赋值的区别; 名称空间引入方法

无参构造器使用规则

当类中没有其他构造器时，默认无参构造器可不写；若有其他构造器则必须显式定义无参构造器

构造器覆盖机制; 显式定义的必要性

XML名称空间引入

使用alt+enter自动引入或手动添加xmlns:util声明

工具兼容性问题处理; schema location配置

集合属性注入

通过<util:list>定义共享集合，使用ref属性引用

数据复用实现方式; value与ref的使用场景

BookStore案例演示

包含bookList属性的类配置，展示集合注入的两种实现方式

XML配置语法对比; 运行时验证方法

知识点

核心内容

重点

级联属性赋值

通过Spring IOC容器直接对对象属性的属性赋值（如employee.department.name）

配置语法：<property name="department.name" value="JAVA开发部门"/>

对象关联配置

在配置主对象（如employee）时引用关联对象（如department）并级联赋值

底层原理：调用关联对象的setter方法

（如department.setName()）

XML配置示例

演示employee与department的级联配置，动态设置部门名称

易错点：需确保关联对象已实例化且属性可访问（如department需有无参构造器）

测试验证

通过输出employee对象验证级联赋值结果（如部门名称显示为JAVA开发部门）

关键代码：employee.getDepartment().getName()

知识点

核心内容

重点

静态工厂模式

通过工厂类返回指定对象，替代直接配置方式

工厂类与普通Bean配置的区别

静态代码块特性

类加载时执行且只执行一次，用于初始化

静态代码块与普通代码块执行时机差异

工厂方法配置

class属性需指定工厂类全路径，factory-method指定方法

容易混淆普通Bean配置的class属性用法

对象获取机制

通过constructor-arg指定工厂内具体对象key

多对象管理时key的匹配规则

单例验证

同一ID多次获取为同一对象（静态工厂特性）

与原型模式(prototype)的作用域区别

知识点

核心内容

重点

静态工厂与实例工厂的区别

静态工厂通过类直接调用静态方法获取对象，无需实例化工厂类；实例工厂需先创建工厂实例，再通过实例方法获取对象

静态工厂方法为static，实例工厂方法需依赖对象调用

实例工厂配置流程

1. 配置实例工厂Bean

2. 在目标Bean中通过factory-bean指定工厂实例

3. 通过factory-method指定方法

4. 用constructor-arg传递参数

必须显式配置工厂实例Bean

对象作用域对比

静态工厂返回的对象始终为同一实例（单例）；实例工厂根据工厂实例不同可能返回不同对象

实例工厂的对象作用域与工厂实例绑定

配置示例代码

xml <bean id="myInstanceFactory" class="com.factory.MyInstanceFactory"/> <bean id="monster02" factory-bean="myInstanceFactory" factory-method="getMonster"> <constructor-arg value="monster03"/> </bean>

factory-bean与factory-method需配对使用

关键验证逻辑

同一实例工厂多次调用返回相同对象；不同实例工厂返回不同对象（即使参数相同）

对象一致性取决于工厂实例而非配置ID

知识点

核心内容

重点

Factory Bean机制

通过实现FactoryBean接口创建工厂Bean，可定制对象创建逻辑

getObject()与getObjectType()方法必须重写

泛型指定

FactoryBean需指定泛型类型决定生产对象类型

泛型类型与实际返回对象类型必须匹配

单例控制

isSingleton()方法决定返回对象是否为单例

默认false（原型模式），需显式设置为true

对象获取流程

1. 配置class为FactoryBean全类名;

2. 通过property指定key值;

3. 容器调用getObject()返回目标对象

class属性配置的是工厂Bean而非目标Bean

Map结构存储

使用HashMap预存多个对象实例

key-value需与配置的property严格对应

配置示例

xml<bean id="myMonster05" class="com.MyFactoryBean"><property name="k" value="monster04"/>

k属性对应工厂Bean的setK()方法

知识点

核心内容

重点

Spring IOC容器继承机制

通过parent属性实现bean配置信息重用，避免重复配置相同属性

parent属性引用方式 vs 直接复制配置

抽象bean配置

通过abstract="true"声明仅供继承的模板bean，类似Java抽象类

抽象bean不可实例化 vs 普通bean可实例化

属性继承验证

子bean自动继承父bean所有属性值（如monster11继承monster10）

继承后属性覆盖规则需注意

配置复用场景

适用于多bean共享相同基础属性的场景（如多个monster对象）

属性继承 vs 对象组合的选择

异常处理案例

尝试实例化抽象bean会抛出BeanIsAbstractException

抽象bean仅作为配置模板的设计意义

知识点

核心内容

重点

Spring IOC容器中Bean的默认创建顺序

默认按照XML/配置文件的书写顺序从上到下创建Bean对象

配置顺序决定初始化顺序，无依赖关系时严格按代码先后执行

depends-on属性强制改变创建顺序

通过depends-on="targetBeanId"显式声明依赖关系，优先初始化被依赖的Bean

即使被依赖的Bean配置在后方，仍会逆向触发初始化

依赖关系的实际应用场景

班级（Class）需先于学生（Student）创建，确保引用有效性

业务逻辑中存在强依赖时必须使用depends-on

验证方法（构造器输出日志）

在无参构造器中打印日志，通过控制台输出观察Bean初始化顺序

构造器执行顺序=Bean创建顺序，需注意日志干扰项

知识点

核心内容

重点

Spring IOC容器中bean的创建顺序

1. 默认按配置顺序创建bean;

2. 引用关系的处理是最后阶段完成;

3. 容器会将所有bean先实例化再处理依赖

配置顺序≠依赖解析顺序; 即使被引用的bean后配置也不会导致空引用

依赖注入的时序问题

1. 容器采用两阶段处理：

- 第一阶段：实例化所有bean; - 第二阶段：处理属性注入;

2. 通过BeanDefinitionMap维护依赖关系

初学者容易误解为"配置在前面的bean会先被完整初始化"

构造器与setter方法的执行时机

1. 构造器在bean实例化阶段执行;

2. setter方法在依赖注入阶段执行;

3. 实验验证： - 构造器输出先于setter方法

构造器注入与setter注入的时序差异

配置顺序灵活性

1. bean配置顺序可任意调整;

2. 不依赖depends-on也能正确处理循环依赖;

3. 底层通过三级缓存解决依赖循环

与传统的new对象方式有本质区别

IOC容器的整体性思维

1. 容器将所有bean定义作为整体处理;

2. 采用图论算法解析依赖关系;

3. 最终保证所有依赖关系正确建立

理解"容器即工厂"的设计哲学

知识点

核心内容

重点

Spring IOC容器的单例与多例

默认情况下，Spring IOC容器按单例模式创建bean对象，即整个容器中只有一个实例；通过scope="prototype"可配置为多例模式，每次getBean()返回新对象。

单例与多例的配置区别：singleton（默认）vs prototype；单例对象的生命周期与容器一致，多例对象每次独立创建。

单例模式的实际表现

单例模式下，多次调用getBean()返回同一对象（通过哈希值验证）。

需注意单例对象的线程安全问题及状态管理。

多例模式的实际表现

配置scope="prototype"后，每次getBean()触发构造器执行，返回新对象（哈希值不同）。

多例适用于需要隔离状态的场景，但需注意资源开销。

代码演示与验证

通过Cat类构造器输出验证单例/多例效果：单例模式仅输出一次构造信息，多例模式每次调用均输出。

易混淆点：属性相同≠对象相同（多例模式下属性值相同但对象不同）。

scope属性的语义

scope直译为“范围”，单例（singleton）即容器范围内唯一，多例（prototype）即每次获取均为原型的新实例。

需理解prototype的原型设计模式背景。

知识点

核心内容

重点

单例模式默认行为

默认在启动容器时创建单例对象，根本原因并非因为是单例，而是lazy-init默认值为false

单例≠必然提前创建，需结合lazy-init属性判断

prototype多例机制

配置scope=prototype后，对象在getBean时才会创建，每次调用生成新实例

多例对象不存入单例池，创建时机与单例模式本质差异

懒加载配置

单例模式下设置lazy-init=true会延迟创建，首次getBean时才初始化

懒加载仅影响创建时机，不影响单例性质（后续调用仍取同一实例）

prototype与懒加载关系

多例模式下lazy-init属性无效（无论true/false均在getBean时创建）

需特别注意多例模式天然具有"懒加载"特性

单例模式设计权衡

默认非懒加载单例以空间换时间，提前创建可能未使用的对象但提升获取效率

特殊场景（如事务管理）才需要配置懒加载

知识点

核心内容

重点

Bean生命周期

构造器→set方法→init方法→使用→destroy方法

执行顺序和配置方式是关键

构造器执行时机

JVM创建对象后首先执行构造器

构造器调用时对象已在堆内存存在

属性注入机制

通过set方法完成属性赋值

必须提供set方法才能注入

init方法配置

在bean标签通过init-method指定

方法名可自定义，需在配置中声明

destroy方法触发

容器关闭时自动调用

必须显式关闭容器才会触发

接口编程实践

ConfigurableApplicationContext提供close方法

接口引用与实现类方法的访问问题

生命周期图示

构造→注入→初始化→使用→销毁

set方法执行后才调用init方法

方法执行控制权

init/destroy方法由Spring容器控制时机

程序员只负责编写逻辑和配置声明

知识点

核心内容

重点

bin生命周期

初始化方法和销毁方法的调用时机与作用

初始化方法在容器启动时调用，销毁方法在容器关闭时调用

bin后置处理器

在初始化方法前后调用的特殊对象，可对bin进行修改处理

postProcessBeforeInitialization和postProcessAfterInitialization的区别

后置处理器实现

需实现BeanPostProcessor接口并重写两个关键方法

方法参数中object bean和beanName的含义与用途

后置处理器调用时机

在bin的init方法前后分别调用对应方法

与setter方法执行顺序的关系

AOP概念引入

后置处理器是理解AOP(面向切面编程)的基础

后置处理器与切面编程的关联性

实践验证方法

通过输出日志验证后置处理器的调用流程

如何观察bin对象在处理器中的状态变化

知识点

核心内容

重点

后置处理器配置

演示如何通过新建容器配置文件配置后置处理器，避免日志过多干扰

后置处理器必须实现特定接口才能生效

后置处理器触发时机

在初始化方法之前(postProcessBeforeInitialization)和之后(postProcessAfterInitialization)触发

注意后置处理器未配置时不会触发任何方法

对象生命周期

完整展示对象创建流程：构造器→set方法→初始化方法→使用→销毁方法

初始化与销毁方法的配置方式

容器隔离性

不同配置文件(beans/beans02.xml)创建的容器相互独立

后置处理器只对所在容器的对象生效

后置处理器作用范围

配置后会自动作用于容器内所有对象

注意处理器方法中接收的对象是同一个实例(通过哈希值验证)

调试技巧

通过新建干净配置文件简化调试，使用toString输出对象状态

关键点：处理器方法执行时对象已完成属性注入但未初始化

知识点

核心内容

重点

后置处理器执行机制

底层通过AOP机制实现，依赖反射+动态代理

方法触发原理（切面编织）与普通方法调用的区别

后置处理器作用范围

对IOC容器中所有对象生效（如house、monster等）

作用对象是否包含懒加载实例（仅非懒加载生效）

应用场景

统一处理日志、权限校验、安全验证、事务管理

与单一对象处理的代码差异（切面编程范式）

动态修改案例

通过instanceof判断类型，强制将house对象名称改为“上海豪宅”

运行期修改与配置期修改的优先级冲突

底层实现预告

后续将手动实现反射+代理+容器+注解机制

AOP与IOC容器的耦合关系