spring ioc依赖注入有几种 每种区别，优缺点
spring的核心思想是IOC和AOP，IOC-控制反转，是一个重要的面向对象编程的法则来消减计算机程序的耦合问题，控制反转一般分为两种类型，依赖注入和依赖查找，依赖什么？为什么需要依赖？注入什么？控制什么？依赖注入和控制反转是一样的概念吗？接触新的知识，小编的脑袋中全是大大的问号，不过没有关系，今天这篇博文，小编主要来简单的介绍一下在spring IOC中依赖注入的方法。
依赖注入和控制反转，目的是为了使类与类之间解耦合，提高系统的可扩展性和可维护性。我们可以从以下几个方面理解：
a、参与者都有谁？
b、依赖：谁依赖谁？为什么需要依赖？
c、注入：谁注入谁？又注入了什么呢？
d、控制反转：谁控制谁？控制什么？为什么叫反转呢？存在正转吗？
e、控制反转和依赖注入是同一个概念吗？我们需要弄明白上面的问题，这样对于控制反转和依赖注入的理解有大大的帮助。
首先：第一个问题，参与者都有谁？
1）对象
2）IOC/DI容器
3）某个对象的外部资源
第二问题：依赖，谁依赖谁？为什么需要依赖？
依赖嘛，很好理解的，对象依赖于IOC/DI容器，至于为什么要依赖呢？对象需要IOC/DI容器来提供对象需要的外部资源。
第三个问题：注入，谁注入谁？又注入了什么呢？
显而易见是IOC/DI容器注入对象，注入了what呢？肯定注入的是某个需要的东西那就是注入对象所需要的资源，肯定不会注入无关紧要的内容，你说呢？
第四个问题：控制反转，谁控制谁？控制什么？为什么叫反转呢？存在正转吗？
控制反转，控制什么？肯定是IOC/DI容器控制对象，主要是控制对象实例的创建，反转是相对于正向而言的，那么什么算是正向的呢？考虑一下常规情况下的应用程序，如果要在A里面使用C，你会怎么做呢？当然是直接去创建C的对象，也就是说，是在A类中主动去获取所需要的外部资源C，这种情况被称为正向的。那么什么是反向呢？就是A类不再主动去获取C，而是被动等待，等待IoC/DI的容器获取一个C的实例，然后反向的注入到A类中。-依赖注入
第五个问题：控制反转和依赖注入式同一个概念吗？
依赖注入和控制反转是对同一件事情的不同描述，从某个方面讲，就是它们描述的角度不同。依赖注入是从应用程序的角度在描述，可以把依赖注入描述完整点：应用程序依赖容器创建并注入它所需要的外部资源；而控制反转是从容器的角度在描述，描述完整点：容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。
-pring
了解了这些基本的概念，弄明白她们之间的联系和区别，能够帮助我们更好的理解，接着小编来重点介绍一下依赖注入，在spring ioc中有三种依赖注入，分别是：
a、接口注入；
b、setter方法注入；
c、构造方法注入；
接着小编对这三种注入方式一一进行讲解，通过demo的讲解，希望能够帮助小伙伴们更好的理解，不足之处还请多多指教。
接口注入
public class ClassA {
private InterfaceB clzB;
public void doSomething() {
Ojbect obj = Class.forName(Config.BImplementation).newInstance();
clzB = (InterfaceB)obj;
clzB.doIt();
}
……
}解释一下上述的代码部分，ClassA依赖于InterfaceB的实现，我们如何获得InterfaceB的实现实例呢？传统的方法是在代码中创建 InterfaceB实现类的实例，并将赋予clzB.这样一来，ClassA在编译期即依赖于InterfaceB的实现。为了将调用者与实现者在编译期分离，于是有了上面的代码。我们根据预先在配置文件中设定的实现类的类名(Config.BImplementation),动态加载实现类，并通过InterfaceB强制转型后为ClassA所用，这就是接口注入的一个最原始的雏形。-依赖注入
setter方法注入
setter注入模式在实际开发中有非常广泛的应用，setter方法更加直观，我们来看一下spring的配置文件：
《?xml version=“1.0“ encoding=“UTF-8“?》
《beans xmlns=“真实版Spring面试题，欢迎作答!
1.ApplicationContext提供了BeanFactory所能提供的功能管理，包括bean的加载，实例化，维护bean之间的依赖关系，负责bean的声明周期之外，还提供了更完整的框架功能：
a. 国际化支持
通过配置org.springframework.context.support.ResourceBundleMessageSource
b. 资源访问：Resource rs = ctx. getResource(“classpath:config.properties”), file:c:/config.properties”
c. 事件传递：通过实现ApplicationContextAware接口
2. 默认scope是singleton，另外几个范围是 prototype
区别是singleton 只在初始化时候创建一个对象
prototype 在每次访问都会创建一个对象
3.根据输入的参数创建实例对象
一种为setter
定义property name 在class里面使用setter方法定义对象
一种为constractor
定义constructor-arg
4.没有
5. Log
定义促销活动日志
@Aspect
public class logpromotion{
@Before(“execution(* com.herb.aop.PromotionOwner.*(..))“)
public void before(JoinPoint joinPoint){
System.out.println(“Logging before “ + joinPoint.getSignature().getName());
}
}
public class PromotionOwner.BuyXgetYfree{
....
}
6.Before Advice 方法执行前
Around Advice 方法执行时
After Advice 方法执行后
Throw Advice 方法出现异常
-pring如何使用Spring Cloud
Spring Cloud项目的既定目标在于为Spring开发人员提供一整套易于使用的工具集，从而保证其轻松构建起自己需要的分布式系统方案。为了实现这一目标，Spring Cloud以Netflix OSS堆栈为基础将大量实现堆栈加以整合并打包。这些堆栈而后可以通过大家所熟知的各类基于注释的配置工具、Java配置工具以及基于模板的编程工具实现交付。下面就让我们一起了解Spring Cloud当中的几类常见组件。 Spring Cloud Config Server Spring Cloud Config Server能够提供一项具备横向扩展能力的集中式配置服务。它所使用的数据被保存在一套可插拔库层当中，后者目前能够支持本地存储、Git以及Subversion。通过利用一套版本控制系统作为配置存储方案，开发人员能够轻松实现版本与审计配置的内容调整。 如何利用Spring Cloud构建起自我修复型分布式系统 配置内容会以Java属性或者YAML文件的形式体现。该Config Server会将这些文件合并为环境对象，其中包含易于理解的Spring属性模型以及作为REST API存在的配置文件。任何应用程序都能够直接调用该REST API当中所包含的配置数据，但我们也可以将智能客户端绑定方案添加到Spring Boot应用程序当中，并由后者自动将接收自Config Server的配置信息分配至任意本地配置当中。 Spring Cloud Bus Spring Cloud Config Server是一套强大的配置分发机制，能够在保障一致性的前提下将配置内容分发到多个应用程序实例当中。然而根据其设计思路的限定，我们目前只能在应用程序启动时对其配置进行更新。在向Git中的某一属性发送新值时，我们需要以手动方式重启每个应用程序进程，从而保证该值被切实纳入应用当中。很明显，大家需要能够在无需重启的前提下完成对应用程序配置内容的更新工作。 如何利用Spring Cloud构建起自我修复型分布式系统 Spring Cloud Bus的任务正是为应用程序实例添加一套管理背板。它目前依靠将一套客户端绑定至一组AMQP交换与队列当中来实现，但这一后端在设计上也实现了可插拔特性。Spring Cloud Bus为我们的应用程序带来了更多管理端点。在图二中，我们可以看到一个面向greeting属性的值被发送至Git当中，而后一条请求被发送至应用A中的/bus/refresh端点。该请求会触发以下三个事件： 应用A从Config Server处请求获取最新版本的配置内容。任意注明了@RefreshScope的Spring Bean都会被重新初始化并载入新的配置内容。 应用A向AMQP交换机制发送一条消息，表明其已经收到更新指示。 通过监听AMQP队列而被纳入Cloud Bus的应用B与应用C会获取到上述消息，并以与应用A同样的方式实现配置更新。 现在我们已经有能力在无需重启的情况下对应用程序配置进行更新了。
-依赖注入
