小编

2026年04月28日 19:06

Spring 的 IoCDI 原理（一）：不止是“反射”

时间： 2026年4月8日 13:17:01

开篇引入

IoC（Inversion of Control，控制反转）和 DI（Dependency Injection，依赖注入）是 Spring 框架最核心、最基础的两个概念，也是 Java 后端开发必须掌握的高频知识点。

很多初学者遇到的问题很典型：会用 @Autowired，但讲不出原理；知道 Spring 管对象，但说不清控制权怎么“转”的；面试问到 IoC 和 DI 的区别，支支吾吾答不到点子上。

本文讲解范围：IoC 的核心思想、DI 的实现机制、二者的关系与区别，以及底层依赖的反射原理。

本文结构：痛点引入 → 核心概念讲解 → 关系梳理 → 代码示例 → 底层原理 → 面试考点 → 总结。

痛点切入：为什么需要 IoC？

先看一段传统开发中“造一辆车”的代码：

public class Main {
    public static void main(String[] args) {
        Car car = new Car(21);
        car.run();
    }
}

public class Car {
    private Framework framework;
    public Car(Integer size) {
        this.framework = new Framework(size);
    }
    public void run() { System.out.println("car run..."); }
}

public class Framework {
    private Bottom bottom;
    public Framework(Integer size) {
        this.bottom = new Bottom(size);
    }
}

public class Bottom {
    private Tire tire;
    public Bottom(Integer size) {
        this.tire = new Tire(size);
    }
}

public class Tire {
    int size;
    public Tire(Integer size) {
        this.size = size;
        System.out.println("tire init, size:" + size);
    }
}

这段代码存在一个致命问题：高耦合。如果轮胎尺寸从 21 改成 18，Bottom、Framework、Car 的构造器都要跟着改——整个调用链都得重写-1。

再看另一个例子，Service 层直接 new DAO 对象：

public class UserServiceImpl implements UserService {
    // 主动 new 依赖对象，控制权在开发者手中
    private UserDao userDao = new UserDaoImpl();
    
    @Override
    public void queryUser() {
        userDao.queryUser();
    }
}

三个痛点：

耦合高：类与类之间强绑定，底层一变，上层全改。
扩展性差：想换 UserDao 的实现（比如从 MySQL 切到 Oracle），必须修改 UserServiceImpl 的代码-4。
维护困难：对象多了之后，手动管理所有依赖关系，代码臃肿不堪，可测试性极差。

解决方案：将对象的创建和管理职责交给外部容器——这就是 IoC 诞生的背景。

核心概念讲解（概念 A）：IoC 控制反转

标准定义：IoC 全称 Inversion of Control，中文译为“控制反转”，是一种设计思想-2。

拆解关键词：

“控制” ：指对象的创建权、依赖的装配权、生命周期的管理权。
“反转” ：指将上述控制权从程序代码本身反转给外部容器（即 Spring IoC 容器）。

生活化类比：

传统模式就像自己做饭——买菜、洗菜、切菜、炒菜，全流程自己动手。IoC 模式就像去餐厅点餐——你只管说“我要一份宫保鸡丁”，餐厅（容器）自动把菜做好送到你面前，你根本不用关心菜是怎么做的、食材是从哪来的-1。

作用和价值：

将对象的管理从业务代码中剥离，业务逻辑更纯粹。
降低代码耦合度，提高可维护性和可测试性。
简化开发——开发者只需声明“我需要什么”，容器自动提供。

关联概念讲解（概念 B）：DI 依赖注入

标准定义：DI 全称 Dependency Injection，中文译为“依赖注入”。它是一种设计模式，通过外部容器将对象所需依赖自动注入，而非在类内部直接创建-。

与 IoC 的关系：

IoC 是“思想” ，描述的是“控制权转移”的设计理念。
DI 是“手段” ，描述的是如何具体实现这种控制权转移。

简单说：IoC 是目标，DI 是手段。

三种注入方式-2：

注入方式	示例	推荐度
构造器注入	通过构造方法参数注入依赖	⭐⭐⭐ 推荐（依赖不可变，易于测试）
Setter 方法注入	通过 setXXX 方法注入依赖	⭐⭐ 可选
字段注入	直接在字段上加 @Autowired	⭐ 不推荐（难以测试，依赖隐藏）

简单示例（构造器注入）：

@Service
public class UserServiceImpl implements UserService {
    private final UserDao userDao;
    
    // 构造器注入（Spring 4.3+ 可省略 @Autowired）
    public UserServiceImpl(UserDao userDao) {
        this.userDao = userDao;
    }
    
    @Override
    public void queryUser() {
        userDao.queryUser();
    }
}

概念关系与区别总结

对比维度	IoC（控制反转）	DI（依赖注入）
定位	设计思想 / 指导原则	具体实现 / 技术手段
回答的问题	谁来管理对象的生命周期？	如何把依赖交给对象？
本质	控制权的转移	对象获取依赖的方式
类比	“把管理权交给管家”	“管家把东西送到手上”

一句话高度概括：IoC 是思想，DI 是手段。IoC 告诉我们“把对象的创建和依赖管理交给容器”，DI 则具体回答了“容器怎么把依赖交给对象”-。

代码/流程示例：对比新旧实现

传统方式（高耦合）

// 传统：Service 主动创建 DAO
public class UserServiceImpl implements UserService {
    private UserDao userDao = new UserDaoImpl();  // 硬编码创建
    // ...
}

IoC + DI 方式（低耦合）

Step 1：定义接口和实现类

// DAO 接口
public interface UserDao {
    void queryUser();
}

// DAO 实现类——交给 Spring 管理
@Repository
public class UserDaoImpl implements UserDao {
    @Override
    public void queryUser() {
        System.out.println("查询用户信息");
    }
}

Step 2：Service 层声明依赖，由容器注入

@Service
public class UserServiceImpl implements UserService {
    // 仅声明依赖，不主动创建
    private UserDao userDao;
    
    // 提供注入入口
    @Autowired
    public void setUserDao(UserDao userDao) {
        this.userDao = userDao;
    }
    
    @Override
    public void queryUser() {
        userDao.queryUser();
    }
}

Step 3：启动容器并使用

// 测试类：从容器中获取对象，无需手动管理依赖
public class Test {
    public static void main(String[] args) {
        // 容器初始化，自动创建 Bean、装配依赖
        ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
        
        // 直接获取对象，依赖已自动注入
        UserService userService = context.getBean(UserService.class);
        userService.queryUser();  // 输出：查询用户信息
    }
}

核心变化：控制权从开发者转移到 Spring 容器——对象的创建、依赖的装配、生命周期的管理，全由容器负责-4。

底层原理/技术支撑：反射机制

Spring 的 IoC/DI 之所以能“动态”管理对象，底层的核心依赖就是 Java 反射机制。可以这样说：没有反射，就没有 Spring 的 IoC/DI-23。

反射在 Spring 中的三个关键应用：

1. 对象创建——通过反射调用构造器

Spring 扫描到 @Component、@Service 等注解后，通过反射获取类的 Class 对象，再调用其构造方法动态创建实例-23：

// 伪代码：Spring 创建对象的过程
Class<?> clazz = Class.forName("com.example.UserService");
Constructor<?> constructor = clazz.getConstructor();  // 获取构造方法
Object instance = constructor.newInstance();          // 反射创建实例

2. 依赖注入——通过反射访问私有字段

当类中存在 @Autowired 标注的字段时，Spring 通过 Field.setAccessible(true) 访问私有字段，直接注入依赖对象-23：

// 伪代码：反射注入依赖
Field field = clazz.getDeclaredField("userDao");
field.setAccessible(true);           // 绕过 private 访问限制
field.set(targetObject, userDaoInstance);

3. 注解解析——通过反射读取注解信息

Spring 通过 Class.getAnnotations() 反射获取类、方法、字段上的注解，再根据注解信息执行相应逻辑-23。

注意：反射确实有性能损耗，但 Spring 通过缓存、懒加载等优化手段将其影响降到了最低，在绝大多数应用场景中可以忽略不计。

高频面试题与参考答案

1. 什么是 IoC？什么是 DI？两者的关系是什么？

参考答案：

IoC（控制反转） 是一种设计思想，将对象的创建、依赖的管理和生命周期的控制权，从程序代码本身转移给外部容器（Spring IoC 容器）。
DI（依赖注入） 是实现 IoC 的具体技术手段，指容器在创建对象时，自动将依赖对象通过构造器、Setter 或字段的方式注入进来。
两者的关系：IoC 是思想，DI 是手段。IoC 描述的是“控制权转移”的理念，DI 描述的是“如何把依赖送进去”的具体实现方式--。

加分点：能补充三种注入方式的区别，并能说明构造器注入推荐使用（依赖不可变、便于单元测试）。

2. Spring IoC 容器有哪两种主要实现？有什么区别？

参考答案：

BeanFactory：Spring 的基础 IoC 容器，采用懒加载策略——Bean 只有在第一次被使用时才创建，适合资源受限的轻量级场景。
ApplicationContext：BeanFactory 的子接口，功能更丰富，采用立即加载策略——在容器启动时就创建所有单例 Bean，启动稍慢但运行时访问快。支持国际化、事件传播、AOP 等企业级功能-14。

加分点：能说出绝大多数实际项目都使用 ApplicationContext，除非在嵌入式设备等资源极端受限的场景下才考虑 BeanFactory-。

3. @Autowired 和 @Resource 有什么区别？

参考答案：

@Autowired 是 Spring 提供的注解，默认按类型（byType） 注入。如果同一类型有多个 Bean，需要配合 @Qualifier 按名称指定。
@Resource 是 Java 标准 JSR-250 提供的注解，默认按名称（byName） 注入。如果找不到对应名称的 Bean，则回退到按类型注入-39。