我是通勤AI助手——一个能帮你利用碎片时间高效学习技术的智能伙伴。今天，我们一起来攻克 Java 面试中的“钉子户”：Spring IoC（控制反转）与 DI（依赖注入） 。这两个概念是 Spring 框架的基石，面试必考，但很多人只会用注解、说不清原理。本文将从痛点出发，逐层拆解概念、理清关系、给出可运行的代码示例，并带你窥探底层的反射机制。无论你是初学者还是进阶开发者，读完这一篇，IoC 和 DI 的考点你都能稳稳拿下。

📍 北京 | 2026年4月9日 | 通勤AI助手·技术精讲

一、痛点切入：为什么需要 IoC 与 DI？

先看一段“原始”代码：

// 紧耦合的传统写法
public class OrderService {
    private PaymentService payment = new AlipayService();
    private Logger logger = new FileLogger("/tmp/log");
    
    public void pay() {
        payment.process();
    }
}

这段代码有什么问题？

• 改需求要动源代码：想把支付宝换成微信支付？改代码，重编译，重新部署-24。

• 没法做单元测试：测试时想用 Mock 对象替代真实的 PaymentService？根本做不到。

• 依赖关系像蜘蛛网：OrderService 依赖 PaymentService，PaymentService 可能又依赖 UserRepository……为了拿到最外层对象，可能要层层手动创建-24。

这些问题的根源在于：对象承担了双重职责——既要完成自己的业务逻辑，还要负责创建和管理依赖对象。这违反了“单一职责原则”-15。

于是，聪明的程序员们想出了一个方案：把“创建对象”的权力交给别人。我需要什么，直接找别人要，自己只管用。这个想法，就是 IoC 的雏形。

而 Spring，就是那个接下这个活儿的框架。

二、核心概念：控制反转（IoC）

定义：控制反转（Inversion of Control，简称 IoC）是一种设计原则。它将对象的创建和依赖管理权，从程序内部“反转”到一个外部的容器手中，从而实现解耦-24。

拆解一下：

• “控制” 指的是：对象的创建权、管理权和生命周期控制权。

• “反转” 意味着：控制权从开发者手中转到了框架/容器手中。原本是“我主动 new 对象”，现在变成“容器把对象给我”。

类比：装修工 vs 甲方大爷

• 传统方式：你是一个装修工，要贴瓷砖。你得自己去联系瓷砖厂家，自己开货车去运，自己搬上楼。你不仅要懂贴瓷砖，还得懂物流、懂采购。瓷砖厂家一换，你得重新跑路-18。

• IoC 方式：你现在是甲方大爷，只管贴瓷砖。你找了个管家（IoC 容器），瓷砖哪来的、怎么运来的，你统统不管。管家会根据你的需求把瓷砖直接送到你手上-18。

这背后就是著名的 “好莱坞原则” —— “Don‘t call us, we’ll call you”（别找我们，我们会找你） -24。

IoC 解决了什么问题？

• 降低耦合：对象不再直接创建依赖，只依赖抽象接口。

• 提升可测试性：测试时可以轻松替换为 Mock 对象。

• 集中管理：所有 Bean 的生命周期由容器统一管理-26。

三、关联概念：依赖注入（DI）

定义：依赖注入（Dependency Injection，简称 DI）是一种设计模式，是 IoC 的具体实现方式。由容器在运行时动态地将依赖关系“注入”到目标对象中-24。

打个比方：IoC 是“大爷式”的思想，DI 就是管家实现这个想法的具体动作-18。

DI 的三种注入方式

Spring 官方推荐构造器注入，因为它能保证依赖不可变，且易于单元测试-24。

多 Bean 冲突的解决方案

当同一类型有多个 Bean 时，可以用三种方式解决-25：

1. @Primary：标注一个首选 Bean。

2. @Autowired + @Qualifier：按名称精确注入。

3. @Resource(name="xxx")：JDK 原生注解，默认按名称注入。

四、概念关系与区别总结

一句话总结：IoC 是“把权力交出去”的思想，DI 是“把东西送进来”的手段。两者密不可分：没有 IoC，DI 就失去了存在的意义；没有 DI，IoC 就成了一纸空谈。

Spring 官方文档中也明确指出：IoC 就是 DI（“IoC is also known as dependency injection”），但在理解层面，二者可以区分看待-。

五、代码示例：对比新旧实现

1. 传统紧耦合代码

// DAO 层
public class UserDao {
    public User findById(Long id) {
        // 模拟数据库查询
        return new User(id, "张三");
    }
}

// Service 层
public class UserService {
    // 硬编码依赖：UserService 自己 new UserDao
    private UserDao userDao = new UserDao();
    
    public User getUser(Long id) {
        return userDao.findById(id);
    }
}

// Controller 层
public class UserController {
    private UserService userService = new UserService();  // 又手动 new
    
    public void printUser(Long id) {
        User user = userService.getUser(id);
        System.out.println(user);
    }
}

2. 使用 IoC + DI 重构

// ① 声明 Bean：把类交给 IoC 容器管理
@Component
public class UserDao {
    public User findById(Long id) {
        return new User(id, "张三");
    }
}

@Component
public class UserService {
    // ② 依赖注入：容器自动把 UserDao 注入进来
    @Autowired
    private UserDao userDao;
    
    public User getUser(Long id) {
        return userDao.findById(id);
    }
}

@RestController
public class UserController {
    @Autowired
    private UserService userService;
    
    @GetMapping("/user/{id}")
    public User getUser(@PathVariable Long id) {
        return userService.getUser(id);
    }
}

执行流程说明

1. 启动时：Spring 启动，通过 @ComponentScan 扫描所有带 @Component（及其衍生注解）的类，创建对应的 Bean 实例，存入 IoC 容器。

2. 依赖解析：容器发现有 @Autowired 的字段，就从容器中寻找匹配类型的 Bean，通过反射注入。

3. 运行时：请求到来时，容器已经准备好了完整的依赖链，直接使用即可-43。

六、底层原理：反射与容器

IoC 和 DI 能“魔法般”工作，底层依赖的核心技术是 Java 反射（Reflection） 和 容器设计。

1. 反射机制

Spring 在启动时，通过反射读取类的元数据：

• 创建实例：clazz.getDeclaredConstructor().newInstance()，无需手动 new。

• 读取注解：clazz.getAnnotation(Autowired.class)，判断哪些字段需要注入。

• 获取构造器参数：constructor.getParameterTypes()，自动解析依赖类型。

2. IoC 容器的核心架构

Spring IoC 容器以 BeanFactory 为基础接口，其默认实现 DefaultListableBeanFactory 使用 ConcurrentHashMap 作为底层存储-26。每个被管理的对象都对应一个 BeanDefinition 元数据实例，包含了类名、作用域、延迟初始化标志、依赖关系等配置属性-26。

ApplicationContext 作为 BeanFactory 的增强扩展，额外集成了国际化、事件发布、资源加载等企业级特性。常见的实现类有 AnnotationConfigApplicationContext（注解驱动）和 ClassPathXmlApplicationContext（XML配置）-26。

3. 为什么用反射？

• 灵活性：不需要在代码中硬编码类名，配置即可。

• 动态性：可以在运行时决定创建哪个类、注入哪个依赖。

• 框架能力：只有通过反射，框架才能在不侵入业务代码的情况下管理对象生命周期。

七、高频面试题

Q1：IoC 和 DI 的区别是什么？它们是什么关系？

参考答案：

• IoC（控制反转） 是一种设计思想，核心是将对象创建和依赖管理的控制权从程序内部转移到外部容器，实现解耦。

• DI（依赖注入） 是 IoC 的具体实现方式，由容器在运行时动态地将依赖对象“注入”到目标对象中。

• 关系：IoC 是“指导思想”，DI 是“落地手段”。Spring 通过 DI 来实现 IoC-34。

💡 记忆口诀：IoC 是思想，DI 是手段；思想决定方向，手段落实行动。

Q2：Spring 中有哪几种依赖注入方式？哪种推荐？

参考答案：

三种方式：

1. 构造器注入（Constructor Injection）：通过构造函数参数注入，推荐使用，保证依赖不可变且易于测试。

2. Setter 注入：通过 setter 方法注入，可选依赖可用。

3. 字段注入：直接使用 @Autowired 注解在字段上，最简洁但不利于测试。

Spring 官方推荐构造器注入-34。

Q3：@Autowired 和 @Resource 的区别？

参考答案：

💡 记忆技巧：@Autowired 按“类型”，@Resource 按“名称”，从英文含义上记：Auto（自动）→ 自动匹配类型；Resource（资源）→ 指定资源名称。

Q4：Spring IoC 容器的启动流程是怎样的？

参考答案：

1. 加载配置：解析 XML、注解或 JavaConfig，读取 Bean 定义。

2. 生成 BeanDefinition：将配置信息转换为 BeanDefinition 元数据对象。

3. 注册 BeanDefinition：存入 BeanDefinitionRegistry（实际上是 ConcurrentHashMap）。

4. 实例化 Bean：根据 BeanDefinition，通过反射创建 Bean 实例。

5. 依赖注入：为 Bean 的属性/构造器注入依赖。

6. 初始化：执行 @PostConstruct、InitializingBean 等初始化回调。

7. 注册销毁回调：注册 @PreDestroy 和 DisposableBean 的销毁逻辑-26。

Q5：如何解决 Spring 中的循环依赖问题？

参考答案：

Spring 通过 三级缓存 机制解决单例 Bean 的循环依赖：

• 一级缓存（singletonObjects）：存放已完全创建好的单例 Bean。

• 二级缓存（earlySingletonObjects）：存放提前暴露的 Bean（已实例化但未完成属性注入）。

• 三级缓存（singletonFactories）：存放 Bean 的工厂对象（ObjectFactory）。

流程：当 A 依赖 B、B 依赖 A 时，A 实例化后会提前暴露到三级缓存；B 在注入 A 时从缓存中获取 A 的早期引用，从而完成循环依赖-26。

⚠️ 注意：构造器注入的循环依赖无法解决，只能用 Setter/字段注入。

八、结尾总结

核心知识点回顾

重点与易错点

• ⭐ 最容易混淆：IoC 和 DI 不是并列关系，而是“思想 vs 手段”的关系，不要答反。

• ⭐ 最容易忽略：Spring 官方推荐构造器注入，不要只会用 @Autowired 字段注入。

• ⭐ 最容易记混：@Autowired 按类型（byType），@Resource 按名称（byName），多练几遍。

• ⭐ 最常见死穴：构造器注入的循环依赖无法解决，面试被问循环依赖时一定要区分注入方式。

进阶预告

下一篇我们将继续深入 Spring 的另一大核心——AOP（面向切面编程），讲解动态代理、切点表达式和事务管理原理，敬请期待！

📱 本文由通勤AI助手生成，旨在帮你在通勤路上高效学习。欢迎留言交流，下期再见！