简单的说，ioc--控制反转，就是把对象生命周期的管理权限交给Spring去管理。不管是对象的创建还是对象的销毁，均由Spring去打理
对象的创建不再交给程序本身，对象的销毁也不再是程序本身的责任。
我们现在拿一个小例子讲一下，Spring IOC的思想：
首先我们创建一根DAO接口：
public interface UserDao {
void getUser();
}
然后我们创建他的实现类：
public class UserDaoImplimplements UserDao {
@Override
public void getUser() {
System.out.println("User");
}
}
然后我们写一个Service接口：
public interface UserSerevice {
void getUser();
}
然后将Service接口的实现类写出来：
public class UserServiceImplimplements UserSerevice {
private UserDaouserDao=new UserDaoImplimplements （） ;
public void setUserDao(UserDao userDao) {
this.userDao = userDao;
}
@Override
public void getUser() {
userDao.getUser();
}
}
我们写一个入口程序去创建其对象：
public class Test {
public static void main(String[] args) {
UserServiceImpl service=new UserServiceImpl();
service.getUser();
}
}
输出：
大家应该可以看到，我在service接口的实现类里面是直接把Dao这个实现类直接在里面new出来了，这样子的耦合性很强，不利于后期的修改，所以，我就修改成为这样子：
然后我们可以创建两个Dao实现类，但是里面的内容你们可以自己修改，这个我就不一一写出来了：
程序的入口程序可以这样写：
public class Test {
public static void main(String[] args) {
UserServiceImpl userDao =new UserServiceImpl();
userDao.setUserDao(new UserDaoMySqlImpl());
userDao.getUser();
userDao.setUserDao(new UserDaoOracleImpl());
userDao.getUser();
}
}
然后我们看输出：
我这样写，极大的降低了程序和接口之间的耦合性，方便以后的程序修改，然后我在主程序里面可以分开创建对象，这样做也方便之后程序的管理。我在setUserDao方法里面写的是Dao的接口，通过转型，替换为实现类，进一步得到相应的实现功能。
但是，我们使用了Spring以后就不一样了，对象的产生和销毁都交给Spring去统一管理，不再由程序本身去管理。
我们可以写一个小示例试试看：
我们先创建一个Spring的项目，然后先写一个bean类：public class User {
private Stringusername;
private Stringpassword;
public StringgetUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public StringgetPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
public void UserShow() {
System.out.println("Username:" +username +"\n\n"+"password:" +password);
}
}
然后我们写一个xml配置文件：
然后我们写一个实现方法：
public class Test {
public static void main(String[] args) {
ApplicationContext context=new ClassPathXmlApplicationContext("com/spring/demo/controller/user.xml");
User user = (User) context.getBean("user");
user.UserShow();
}
}
注意，路径问题，我写的是我的包名加上文件名，因为我吧xml文件放在我的同目录写，所有我这样写，如果你们是maven项目，你们把包名路径换成classpath：就好了，如果是java项目，你们写WEB-INF/+文件名就好了
然后我们点击运行，我们看看结果：
Look，我们是不是没有创建对象啊，但是你肯定会说，是真的创建对象了吗，那我们在bean类的构造方法里面写一个队友的输出：
点击运行：
你看，是不是创建对象了
Spring就是这样子，我们不需要再去按照老样子自己在程序里面创建对象，销毁对象。一切的对象管理都交给Spring去做，告诉他，我什么时候需要创建对象了，我什么时候要加入什么值。对象的管理权交给了Spring，我们不需要去管理。
简单粗俗一点说，好比你爸爸的工资使用权不再是你爸爸的，这个使用权都给你老妈了，你爸爸没有权利去管理自己的工资。
然后我们现在总结：
第一点：什么是IOC：
IoC 容器：最主要是完成了完成对象的创建和依赖的管理注入等等。
先从我们自己设计这样一个视角来考虑：
所谓控制反转，就是把原先我们代码里面需要实现的对象创建、依赖的代码，反转给容器来帮忙实现。那么必然的我们需要创建一个容器，同时需要一种描述来让容器知道需要创建的对象与对象的关系。这个描述最具体表现就是我们可配置的文件。
对象和对象关系怎么表示？
可以用 xml ， properties 文件等语义化配置文件表示。
描述对象关系的文件存放在哪里？
可能是 classpath ， filesystem ，或者是 URL 网络资源， servletContext 等。
回到正题，有了配置文件，还需要对配置文件解析。
不同的配置文件对对象的描述不一样，如标准的，自定义声明式的，如何统一？ 在内部需要有一个统一的关于对象的定义，所有外部的描述都必须转化成统一的描述定义。
如何对不同的配置文件进行解析？需要对不同的配置文件语法，采用不同的解析器
第二点： Spring IOC体系结构
(1) BeanFactory
Spring Bean的创建是典型的工厂模式，这一系列的Bean工厂，也即IOC容器为开发者管理对象间的依赖关系提供了很多便利和基础服务，在Spring中有许多的IOC容器的实现供用户选择和使用，其相互关系如下：
其中BeanFactory作为最顶层的一个接口类，它定义了IOC容器的基本功能规范，BeanFactory 有三个子类：ListableBeanFactory、HierarchicalBeanFactory 和AutowireCapableBeanFactory。但是从上图中我们可以发现最终的默认实现类是 DefaultListableBeanFactory，他实现了所有的接口。那为何要定义这么多层次的接口呢？查阅这些接口的源码和说明发现，每个接口都有他使用的场合，它主要是为了区分在 Spring 内部在操作过程中对象的传递和转化过程中，对对象的数据访问所做的限制。例如 ListableBeanFactory 接口表示这些 Bean 是可列表的，而 HierarchicalBeanFactory 表示的是这些 Bean 是有继承关系的，也就是每个Bean 有可能有父 Bean。
AutowireCapableBeanFactory 接口定义 Bean 的自动装配规则。这四个接口共同定义了 Bean 的集合、Bean 之间的关系、以及 Bean 行为.
在BeanFactory里只对IOC容器的基本行为作了定义，根本不关心你的bean是如何定义怎样加载的。正如我们只关心工厂里得到什么的产品对象，至于工厂是怎么生产这些对象的，这个基本的接口不关心。
而要知道工厂是如何产生对象的，我们需要看具体的IOC容器实现，spring提供了许多IOC容器的实现。比如XmlBeanFactory，ClasspathXmlApplicationContext等。其中XmlBeanFactory就是针对最基本的ioc容器的实现，这个IOC容器可以读取XML文件定义的BeanDefinition（XML文件中对bean的描述）,如果说XmlBeanFactory是容器中的屌丝，ApplicationContext应该算容器中的高帅富.
ApplicationContext是Spring提供的一个高级的IoC容器，它除了能够提供IoC容器的基本功能外，还为用户提供了以下的附加服务。
从ApplicationContext接口的实现，我们看出其特点：
1. 支持信息源，可以实现国际化。（实现MessageSource接口）
2. 访问资源。(实现ResourcePatternResolver接口，这个后面要讲)
3. 支持应用事件。(实现ApplicationEventPublisher接口)
(2) BeanDefinition
SpringIOC容器管理了我们定义的各种Bean对象及其相互的关系，Bean对象在Spring实现中是以BeanDefinition来描述的，其继承体系如下：
Bean 的解析过程非常复杂，功能被分的很细，因为这里需要被扩展的地方很多，必须保证有足够的灵活性，以应对可能的变化。Bean 的解析主要就是对 Spring 配置文件的解析。这个解析过程主要通过下图中的类完成：
Spring IOC控制反转，我就基本介绍到这里，个人见解，如果有什么不对的地方，请指正