前言

说起 Spring，IOC 绝对是绕不开的话题。

面试官最爱问：什么是 IOC？为什么要用 IOC？IOC 到底解决了什么问题？

很多同学只知道 @Autowired 一用就行，但 IOC 的本质是什么，却说不清楚。

今天我们就把 IOC 给讲透。

什么是 IOC

传统方式的痛点

先看没有 IOC 的时候，我们怎么写代码：

// 传统方式：对象自己管理依赖
public class UserService {
    private UserDao userDao;
  
    public UserService() {
        // 自己new依赖对象
        this.userDao = new UserDaoImpl();
    }
}
​

看起来没毛病，但问题很多：

依赖关系：

┌─────────────┐  直接new  ┌─────────────┐
│ UserService │ ──────▶  │ UserDaoImpl │
│   "我要"    │          │   "被要"    │
└─────────────┘          └─────────────┘

问题：
1. 紧耦合：UserService直接依赖具体实现
2. 难测试：UserDao写死了，没法换mock
3. 难扩展：换个实现就得改代码
​

IOC 的解决思路

IOC（Inversion of Control）控制反转，核心就是：

不要你自己 new 对象，我（容器）给你！

IOC方式：

┌─────────────┐          ┌─────────────┐
│ UserService │          │ UserDaoImpl │
│  "我需要"   │          │  "我在这"   │
└─────────────┘          └─────────────┘
      ↑                        ↑
      │                        │
      └──── 我来搭线 ────────────┘
              |
        ┌─────────────┐
        │ Spring容器  │
        │  "红娘"     │
        └─────────────┘
​

这就是控制反转：

• 以前：UserService 自己控制依赖的创建
• 现在：Spring 容器控制依赖的创建和注入

控制权从对象转移到了容器，所以叫"反转"。

IOC vs DI

经常有人搞混这俩概念：

IOC 控制反转：
┌─────────────────────────────────┐
│         设计思想                │
│    "让容器来控制对象"           │
└─────────────────────────────────┘
                │
                │ 怎么实现？
                ▼
DI 依赖注入：
┌─────────────────────────────────┐
│         实现手段                │
│    "容器把依赖注入进来"         │
└─────────────────────────────────┘

简单说：
IOC = 设计理念（what）
DI  = 实现方式（how）
​

IOC 怎么工作

Spring 容器做了什么

Spring容器的工作流程：

1. 扫描阶段
┌─────────────────────────────────┐
│ 找到所有@Component、@Service     │
│ 等注解的类，记录下来             │
└─────────────────────────────────┘
                │
                ▼
2. 创建阶段
┌─────────────────────────────────┐
│ 根据记录，创建所有Bean实例       │
│ 处理依赖关系                   │
└─────────────────────────────────┘
                │
                ▼
3. 注入阶段
┌─────────────────────────────────┐
│ 把依赖对象注入到需要的地方       │
│ @Autowired就是注入的标记        │
└─────────────────────────────────┘
​

实际例子

// 1. 定义接口
public interface UserDao {
    User findById(String id);
}

// 2. 实现类
@Repository  // 告诉Spring：我是一个Bean
public class UserDaoImpl implements UserDao {
    public User findById(String id) {
        // 具体实现
        return new User(id, "张三");
    }
}

// 3. 服务类
@Service  // 告诉Spring：我也是一个Bean
public class UserService {
  
    @Autowired  // 告诉Spring：请注入UserDao
    private UserDao userDao;
  
    public User getUser(String id) {
        return userDao.findById(id);
    }
}
​

Spring 看到这些注解后：

Spring的工作：

1. 发现Bean
   ├─ UserDaoImpl (因为@Repository)
   └─ UserService (因为@Service)

2. 分析依赖
   └─ UserService需要UserDao (因为@Autowired)

3. 创建和注入
   ├─ 创建UserDaoImpl实例
   ├─ 创建UserService实例
   └─ 把UserDaoImpl注入到UserService中

结果：UserService.userDao指向UserDaoImpl实例
​

IOC 的好处

松耦合

// 没有IOC：紧耦合
public class UserService {
    private UserDao userDao = new MySQLUserDao();  // 写死了MySQL实现
}

// 有了IOC：松耦合
@Service
public class UserService {
    @Autowired
    private UserDao userDao;  // 不关心具体实现，只依赖接口
}

// 想换实现？配置一下就行
@Repository
public class RedisUserDao implements UserDao {
    // Redis实现
}
​

易测试

// 测试时可以注入Mock对象
@Test
public void testUserService() {
    UserDao mockDao = Mockito.mock(UserDao.class);
    // 通过Spring注入mock对象
  
    UserService service = new UserService(mockDao);
    // 测试业务逻辑
}
​

配置灵活

// 开发环境用内存数据库
@Profile("dev")
@Repository
public class MemoryUserDao implements UserDao {
    // 内存实现
}

// 生产环境用MySQL
@Profile("prod")
@Repository  
public class MySQLUserDao implements UserDao {
    // MySQL实现
}

// UserService不用改一行代码，Spring自动选择合适的实现
​

常见问题

循环依赖

// 这样会有问题吗？
@Service
public class ServiceA {
    @Autowired
    private ServiceB serviceB;  // A依赖B
}

@Service
public class ServiceB {
    @Autowired
    private ServiceA serviceA;  // B依赖A
}
​

Spring 可以解决这种循环依赖：

解决思路：

1. 先创建ServiceA（空壳）
2. 创建ServiceB时，把空壳ServiceA注入进去
3. ServiceB创建完成
4. 把完整的ServiceB注入到ServiceA中
5. ServiceA也完成了

关键：先创建对象，再注入依赖
​

依赖找不到

@Service
public class UserService {
    @Autowired
    private UserDao userDao;  // 如果没有UserDao的实现类怎么办？
}
​

Spring 会报错：

NoSuchBeanDefinitionException: 
No qualifying bean of type 'UserDao'
​

解决办法：

1. 确保有 @Repository 标注的实现类
2. 确保在 @ComponentScan 范围内
3. 或者用 @Bean 手动定义

小结

IOC 的核心思想很简单：别自己 new 对象，让容器帮你管理。

好处显而易见：

• 松耦合：依赖接口不依赖实现
• 易测试：可以注入 mock 对象
• 易扩展：换实现不用改代码
• 易管理：统一的对象生命周期管理

理解要点：

• IOC 是设计思想，DI 是实现方式
• @Autowired 是注入的标记
• Spring 容器负责创建和管理 Bean
• 循环依赖可以解决，但最好避免

掌握了 IOC，就理解了 Spring 的核心。其他特性都是在这个基础上构建的。