1，经常把Spring的IOC和DI搞混，其实DI(依赖注入)其实就是IOC的另外一个角度的说法。 在平时的Java应用开发中，我们要实现某一个功能或者说是完成某个业务逻辑时至少需要两个或以上的对象来协作完成，在没有使用Spring的时候，每个对象在需要使用他的合作对象或者依赖对象时，自己均要使用像new object() 这样的语法来将合作对象创建出来，这个合作对象是由自己主动创建出来的，创建合作对象的主动权在自己手上，自己需要哪个合作对象，就主动去创建，创建合作对象的主动权和创建时机是由自己把控的，而这样就会使得对象间的耦合度高了，A对象需要使用合作对象B来共同完成一件事，A要使用B，那么A就对B产生了依赖，也就是A和B之间存在一种耦合关系，并且是紧密耦合在一起，而使用了Spring之后就不一样了，创建合作对象B的工作是由Spring来做的，Spring创建好B对象，然后存储到一个容器里面，当A对象需要使用B对象时，Spring就从存放对象的那个容器里面取出A要使用的那个B对象，然后交给A对象使用，至于Spring是如何创建那个对象，以及什么时候创建好对象的，A对象不需要关心这些细节问题(你是什么时候生的，怎么生出来的我可不关心，能帮我干活就行)，A得到Spring给我们的对象B之后，两个人一起协作完成要完成的工作即可。
所以控制反转IOC(Inversion of Control)是说创建对象的控制权进行转移，以前创建对象的主动权和创建时机是由自己把控的，而现在这种权力转移到第三方，比如转移交给了IOC容器，它就是一个专门用来创建对象的工厂，你要什么对象，它就给你什么对象，有了 IOC容器，依赖关系就变了，原先的依赖关系就没了，它们都依赖IOC容器了，通过IOC容器来建立它们之间的关系。 DI(依赖注入)其实就是IOC的另外一种说法，DI是由Martin Fowler 在2004年初的一篇论文中首次提出的。他总结道：控制的什么被反转了？就是获得依赖对象的方式反转了。
2，Spring IOC 和 DI 的基本原理 用自己的语音表述：
Spring IOC 的基本流程：
1），读取配置文件
2），解析配置文件，并封装成BeanDefinition
3），把BeanDefinition对应的实例放入到容器进行缓存。
Spring DI 的基本流程：
1），循环读取BeanDefinition的缓存信息
2），调用getBean()方法创建对象实例
3），将创建好的对象实例包装秤BeanWrapper对象
4），将BeanWrapper对象缓存到IOC容器中
5），循环IOC容器执行依赖注入
3,SpringMvc九大组件
MultipartResolver 多文件上传组件
LocaleResolver 本地语言环境
ThemeResolver 主体模板处理器
HandlerMapper 保存URL映射关系
HandlerAdapter 动态参数适配器
HandleExceptionResolver 异常拦截器
RequestToViewNameTranslator 视图提取器，从request中提取viewName
ViewResolvers 视图转换器，模板引擎
FlashMapManeger 参数缓存器
