简介
Ioc—Inversion of Control，即“控制反转”，不是什么技术，而是一种设计思想，后来被叫做依赖注入。在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。其主要就是解决了依赖对象之间耦合度的问题，使得类更加关注自己的功能而无需关心自己所需的资源是怎么来的，从哪里来？要理解Ioc的原理，需要搞清楚几件事：
1. 依赖关系是什么？
2. 没有IOC怎么依赖？引入后呢？
3. 谁控制谁，控制什么？
4. 为何是反转（有反转就应该有正转了）？
1、依赖关系是什么？
依赖关系其实很简单，当A类中成员变量中有B类时，我们就说A类依赖于B类。描述代码如下：
public class A {
private B b;
public A(){
}
}
public class B {
public String funB(){
return "funB...";
}
public B(){
}
}
2、没有Ioc时类是如何获取自身所需的依赖对象的？引入Ioc之后呢？
我们知道了依赖关系后，想想如果没有依赖关系，当我们创建A类时，在A类中使用到B类，那么就需要创建一个B类的实例。那么一般都是直接使用new一个类的实例。描述代码如下：
public class A {
@Autowired
private B b;
public A(){
}
public void funA(){
System.out.println(b.funB());
}
}
上面代码其实是很常见的场景，就是A类需要对B类中的一些数据资源进行操作。而在获取B类的资源时，首先要就是要先将B类实例化。这里可以看到，我们在A类的代码中，我们还需要关心B类何时实例化，B类实例化是否需要额外的数据资源，如果需要还需要为B类找到其所需的资源，才能完成funA()的调用。如果类A和类B是一个人编码实现，并且类B没有依赖的对象，或者依赖的关系不复杂，那么这样做显然是可以的。但是当类A和类B是分开两个人编写的时候呢？是否意味着编写类A的人还需要把先把类B的实例化代码看一遍，才能使用。
而引入Ioc之后，我们看看发生了什么变化？
public class A {
private B b = new B();
public A(){
}
public void funA(){
System.out.println(b.funB());
}
}
@Component
public class B {
public String funB(){
return "funB...";
}
public B(){
}
}
上面使用了Spring中实现的Ioc，可以看到在A类中没有new，而是直接使用了B的实例b中的资源。这对于A类的开发者来说会轻松许多，因为它无需关心B是如何实例化，何时实例化。那么谁应该来关心B类何时实例化呢？它就是一个叫做Ioc容器的东西，整个依赖注入的过程都是Ioc容器在负责完成，其中@Component相当于在告诉Ioc容器，我这里有一个B类的资源。 @Autowired是告诉Ioc容器，我需要一个B类的资源。然后Ioc就会在自己管理的资源中，找到B类的资源给A类。
3、谁控制谁，控制什么？
由上面可以看出，对象的创建是由Ioc容器来创建的，即由Ioc容器来控制对象的创建。谁控制谁？当然是Ioc容器控制了对象。控制了什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。
4、为何是反转（有反转就应该有正转了）？
有反转就有正转，传统应用程序是由我们自己在对象中主动控制去获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象。为何是反转？因为容器帮我们查找及注入了依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。
总结
Ioc就是说创建对象的控制权进行转移，以前对象的创建主动权和创建时机是由自己把控的，而现在这种权力转移到了Ioc容器中。你要什么对象，它就给你什么对象，有了Ioc容器，依赖关系就变了，原来的依赖关系就没了，它们都依赖Ioc容器了，通过Ioc容器来建立它们之间的关系。再举个简单的例子来加强理解：比如现在疫情期间自己在家想去吃顿大餐，如果没有Ioc模式的话，我就需要思考怎么去做大餐，什么时候做？但是在Ioc模式下，我只需要点个外卖，告诉商家（Ioc容器）我想吃什么，然后就做好给我送上门，就开吃了。
