Spring IoC

清疚 2023-10-14 18:01 0阅读 0赞

Spring IoC 控制反转  
1.1、IoC是什么  
　　Ioc—Inversion of Control，即“控制反转”，不是什么技术，而是一种设计思想。在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。如何理解好Ioc呢？理解好Ioc的关键是要明确“谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”，那我们来深入分析一下：

●谁控制谁，控制什么：传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对 象的创建；谁控制谁？当然是IoC 容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。

●为何是反转，哪些方面反转了：有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。  
　  
　　用图例说明一下，传统程序设计如图2-1，都是主动去创建相关对象然后再组合起来：  
　　![在这里插入图片描述][baa5f726b4404f7eb3b22efc1d73ed4b.png]  
　　当有了IoC/DI的容器后，在客户端类中不再主动去创建这些对象了，如图2-2所示:  
　　![在这里插入图片描述][fd17466e9df54da9b528ff0638e45730.png]  
1.2、IoC能做什么  
　　IoC 不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是 松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。

其实IoC对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。

IoC很好的体现了面向对象设计法则之一—— 好莱坞法则：“别找我们，我们找你”；即由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。

1.3、IoC和DI  
　　DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。

理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”，那我们来深入分析一下：

●谁依赖于谁：当然是应用程序依赖于IoC容器；

●为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；

●谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；

●注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

IoC和DI由什么关系呢？其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。

看过很多对Spring的Ioc理解的文章，好多人对Ioc和DI的解释都晦涩难懂，反正就是一种说不清，道不明的感觉，读完之后依然是一头雾水，感觉就是开涛这位技术牛人写得特别通俗易懂，他清楚地解释了IoC(控制反转) 和DI(依赖注入)中的每一个字，读完之后给人一种豁然开朗的感觉。我相信对于初学Spring框架的人对Ioc的理解应该是有很大帮助的。

IOC 底层原理  
xml 解析、工厂模式、反射  
![在这里插入图片描述][0c4575f633d744158ff96ed4ac1a3015.png]  
IOC（BeanFactory 接口）  
1、IOC 思想基于 IOC 容器完成，IOC 容器底层就是对象工厂  
2、Spring 提供 IOC 容器实现两种方式：（两个接口）  
（1）BeanFactory：IOC 容器基本实现，是 Spring 内部的使用接口，不提供开发人员进行使用

加载配置文件时候不会创建对象，在获取对象（使用）才去创建对象  
（2）ApplicationContext：BeanFactory 接口的子接口，提供更多更强大的功能，一般由开发人员进行使用  
加载配置文件时候就会把在配置文件对象进行创建  
日常开发中，我们都使用ApplicationContext 去获取xml配置信息。  
3、ApplicationContext 接口的实现类有哪些？

BeanFactory和ApplicationContext是Spring的两大核心接口，都可以当做Spring的容器。**其中ApplicationContext是BeanFactory的子接口。**

两者区别如下：

1、功能上的区别。BeanFactory是Spring里面最底层的接口，包含了各种Bean的定义，读取bean配置文档，管理bean的加载、实例化，控制bean的生命周期，维护bean之间的依赖关系。

ApplicationContext接口作为BeanFactory的派生，除了提供BeanFactory所具有的功能外，还提供了更完整的框架功能，如继承MessageSource、支持国际化、统一的资源文件访问方式、同时加载多个配置文件等功能。

2、加载方式的区别。BeanFactroy采用的是延迟加载形式来注入Bean的，即只有在使用到某个Bean时(调用getBean())，才对该Bean进行加载实例化。这样，我们就不能发现一些存在的Spring的配置问题。如果Bean的某一个属性没有注入，BeanFacotry加载后，直至第一次使用调用getBean方法才会抛出异常。

而ApplicationContext是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可以发现Spring中存在的配置错误，这样有利于检查所依赖属性是否注入。 ApplicationContext启动后预载入所有的单例Bean，那么在需要的时候，不需要等待创建bean，因为它们已经创建好了。

相对于基本的BeanFactory，ApplicationContext 唯一的不足是占用内存空间。当应用程序配置Bean较多时，程序启动较慢。

3、创建方式的区别。BeanFactory通常以编程的方式被创建，ApplicationContext还能以声明的方式创建，如使用ContextLoader。

4、注册方式的区别。BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但两者之间的区别是：BeanFactory需要手动注册，而ApplicationContext则是自动注册。

**IOC容器初始化过程？**

从XML中读取配置文件。
    将bean标签解析成 BeanDefinition，如解析 property 元素， 并注入到 BeanDefinition 实例中。
    将 BeanDefinition 注册到容器 BeanDefinitionMap 中。
    BeanFactory 根据 BeanDefinition 的定义信息创建实例化和初始化 bean。

> BeanDefinition主要是用来描述Bean，存储Bean的相关信息，主要包括：Bean的属性、是否单例、延迟加载、Bean的名称、构造方法等。

单例bean的初始化以及依赖注入一般都在容器初始化阶段进行，只有懒加载（lazy-init为true）的单例bean是在应用第一次调用getBean()时进行初始化和依赖注入。

// AbstractApplicationContext  
// Instantiate all remaining (non-lazy-init) singletons.  
finishBeanFactoryInitialization(beanFactory);  
多例bean 在容器启动时不实例化，即使设置 lazy-init 为 false 也没用，只有调用了getBean()才进行实例化。

loadBeanDefinitions采用了模板模式，具体加载 BeanDefinition 的逻辑由各个子类完成。

Bean注入容器有哪些方式？  
1、@Configuration + @Bean

@Configuration用来声明一个配置类，然后使用 @Bean 注解，用于声明一个bean，将其加入到Spring容器中。

@Configuration
    public class MyConfiguration {
        
        @Bean
        public Person person() {
        
            Person person = new Person();
            person.setName("大彬");
            return person;
        }
    }

2、通过包扫描特定注解的方式

@ComponentScan放置在我们的配置类上，然后可以指定一个路径，进行扫描带有特定注解的bean，然后加至容器中。

特定注解包括@Controller、@Service、@Repository、@Component

@Component
    public class Person {
        
        //...
    }
     
    @ComponentScan(basePackages = "com.dabin.test.*")
    public class Demo1 {
        
        public static void main(String[] args) {
        
            AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(Demo1.class);
            Person bean = applicationContext.getBean(Person.class);
            System.out.println(bean);
        }
    }

3、@Import注解导入

@Import注解平时开发用的不多，但是也是非常重要的，在进行Spring扩展时经常会用到，它经常搭配自定义注解进行使用，然后往容器中导入一个配置文件。

@ComponentScan
    /*把用到的资源导入到当前容器中*/
    @Import({
        Person.class})
    public class App {
        
        public static void main(String[] args) throws Exception {
        
            ConfigurableApplicationContext context = SpringApplication.run(App.class, args);
            System.out.println(context.getBean(Person.class));
            context.close();
        }
    }

4、实现BeanDefinitionRegistryPostProcessor进行后置处理。

在Spring容器启动的时候会执行 BeanDefinitionRegistryPostProcessor 的 postProcessBeanDefinitionRegistry 方法，就是等beanDefinition加载完毕之后，对beanDefinition进行后置处理，可以在此进行调整IOC容器中的beanDefinition，从而干扰到后面进行初始化bean。

在下面的代码中，我们手动向beanDefinitionRegistry中注册了

person的BeanDefinition。最终成功将person加入到applicationContext中。
    
    public class Demo1 {
        
        public static void main(String[] args) {
        
            AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext();
            MyBeanDefinitionRegistryPostProcessor beanDefinitionRegistryPostProcessor = new MyBeanDefinitionRegistryPostProcessor();
            applicationContext.addBeanFactoryPostProcessor(beanDefinitionRegistryPostProcessor);
            applicationContext.refresh();
            Person bean = applicationContext.getBean(Person.class);
            System.out.println(bean);
        }
    }
     
    class MyBeanDefinitionRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor {
        
        @Override
        public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException {
        
            AbstractBeanDefinition beanDefinition = BeanDefinitionBuilder.rootBeanDefinition(Person.class).getBeanDefinition();
            registry.registerBeanDefinition("person", beanDefinition);
        }
        
        @Override
        public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        
        }
    }

5、使用FactoryBean接口

如下图代码，使用@Configuration + @Bean的方式将

PersonFactoryBean 加入到容器中，这里没有向容器中直接注入 Person，而是注入 PersonFactoryBean，然后从容器中拿Person这个类型的bean。
    
    @Configuration
    public class Demo1 {
        
        @Bean
        public PersonFactoryBean personFactoryBean() {
        
            return new PersonFactoryBean();
        }
     
        public static void main(String[] args) {
        
            AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(Demo1.class);
            Person bean = applicationContext.getBean(Person.class);
            System.out.println(bean);
        }
    }
     
    class PersonFactoryBean implements FactoryBean<Person> {
        
        @Override
        public Person getObject() throws Exception {
        
            return new Person();
        }
    
        @Override
        public Class<?> getObjectType() {
        
            return Person.class;
        }
    }

**Bean的作用域**

1、singleton：单例，Spring中的bean默认都是单例的。
    
    2、prototype：每次请求都会创建一个新的bean实例。
    
    3、request：每一次HTTP请求都会产生一个新的bean，该bean仅在当前HTTP request内有效。
    
    4、session：每一次HTTP请求都会产生一个新的bean，该bean仅在当前HTTP session内有效。
    
    5、global-session：全局session作用域。

**Spring自动装配的方式有哪些？**

> Spring的自动装配有三种模式：byType(根据类型)，byName(根据名称)、constructor(根据构造函数)。

byType

找到与依赖类型相同的bean注入到另外的bean中，这个过程需要借助setter注入来完成，因此必须存在set方法，否则注入失败。

当xml文件中存在多个相同类型名称不同的实例Bean时，Spring容器依赖注入仍然会失败，因为存在多种适合的选项，Spring容器无法知道该注入那种，此时我们需要为Spring容器提供帮助，指定注入那个Bean实例。可以通过＜bean＞标签的autowire-candidate设置为false来过滤那些不需要注入的实例Bean

byName

将属性名与bean名称进行匹配，如果找到则注入依赖bean。

<bean id="userDao"  class="com.zejian.spring.springIoc.dao.impl.UserDaoImpl" />
    <bean id="userDao2" class="com.zejian.spring.springIoc.dao.impl.UserDaoImpl" />
    
    
    <bean id="userService" autowire="byName" class="com.zejian.spring.springIoc.service.impl.UserServiceImpl" />
    constructor

存在单个实例则优先按类型进行参数匹配（无论名称是否匹配），当存在多个类型相同实例时，按名称优先匹配，如果没有找到对应名称，则注入失败。

@Autowired和@Resource的区别？  
Autowire是spring的注解。默认情况下@Autowired是按类型匹配的(byType)。如果需要按名称(byName)匹配的话，可以使用@Qualifier注解与@Autowired结合。@Autowired 可以传递一个required=false的属性，false指明当userDao实例存在就注入不存就忽略，如果为true，就必须注入，若userDao实例不存在，就抛出异常。

public class UserServiceImpl implements UserService {
        
        //标注成员变量
        @Autowired
        @Qualifier("userDao1")
        private UserDao userDao;   
     }

上述两种自动装配的依赖注入并不适合简单值类型，如int、boolean、long、String以及Enum等，对于这些类型，Spring容器也提供了@Value注入的方式。

@Value和@Autowired、@Resource类似，也是用来对属性进行注入的，只不过@Value是用来从Properties文件中来获取值的，并且@Value可以解析SpEL(Spring表达式)。

比如，jdbc.properties文件如下：

jdbc.driver=com.mysql.jdbc.Driver
    jdbc.url=jdbc:mysql://127.0.0.1:3306/test?characterEncoding=UTF-8&allowMultiQueries=true
    jdbc.username=root
    jdbc.password=root

利用注解@Value获取jdbc.url和jdbc.username的值，实现如下：

public class UserServiceImpl implements UserService {
        
        //占位符方式
        @Value("${jdbc.url}")
        private String url;
        //SpEL表达方式，其中代表xml配置文件中的id值configProperties
        @Value("#{configProperties['jdbc.username']}")
        private String userName;
    
    }

@Bean和@Component有什么区别？  
都是使用注解定义 Bean。@Bean 是使用 Java 代码装配 Bean，@Component 是自动装配 Bean。

@Component 注解用在类上，表明一个类会作为组件类，并告知Spring要为这个类创建bean，每个类对应一个 Bean。

@Bean 注解用在方法上，表示这个方法会返回一个 Bean。@Bean 需要在配置类中使用，即类上需要加上@Configuration注解。

@Component
    public class Student {
        
        private String name = "lkm";
     
        public String getName() {
        
            return name;
        }
    }
    
    @Configuration
    public class WebSocketConfig {
        
        @Bean
        public Student student(){
        
            return new Student();
        }
    }

@Bean 注解更加灵活。当需要将第三方类装配到 Spring 容器中，因为没办法源代码上添加@Component注解，只能使用@Bean 注解的方式，当然也可以使用 xml 的方式。

@Component、@Controller、@Repositor和@Service 的区别？  
@Component：最普通的组件，可以被注入到spring容器进行管理。

@Controller：将类标记为 Spring Web MVC 控制器。

@Service：将类标记为业务层组件。

@Repository：将类标记为数据访问组件，即DAO组件。

Spring 事务实现方式有哪些？  
事务就是一系列的操作原子执行。Spring事务机制主要包括声明式事务和编程式事务。

编程式事务：通过编程的方式管理事务，这种方式带来了很大的灵活性，但很难维护。

使用TransactionTemplate实现编程式事务

声明式事务：将事务管理代码从业务方法中分离出来，通过aop进行封装。Spring声明式事务使得我们无需要去处理获得连接、关闭连接、事务提交和回滚等这些操作。**使用 @Transactional 注解开启声明式事务。**  
![在这里插入图片描述][fccf88bc6f784bf5a8a65c89ba960343.png]

Spring 的单例 Bean 是否有并发安全问题？  
当多个用户同时请求一个服务时，容器会给每一个请求分配一个线程，这时多个线程会并发执行该请求对应的业务逻辑，如果业务逻辑有对单例状态的修改（体现为此单例的成员属性），则必须考虑线程安全问题。

无状态bean和有状态bean

有实例变量的bean，可以保存数据，是非线程安全的。  
没有实例变量的bean，不能保存数据，是线程安全的。  
在Spring中无状态的Bean适合用单例模式，这样可以共享实例提高性能。有状态的Bean在多线程环境下不安全，一般用Prototype模式或者使用ThreadLocal解决线程安全问题。

Spring Bean如何保证并发安全？  
Spring的Bean默认都是单例的，某些情况下，单例是并发不安全的。

以 Controller 举例，假如我们在 Controller 中定义了成员变量。当多个请求来临，进入的都是同一个单例的 Controller 对象，并对此成员变量的值进行修改操作，因此会互相影响，会有并发安全的问题。

应该怎么解决呢？

为了让多个HTTP请求之间不互相影响，可以采取以下措施：

1、单例变原型

对 web 项目，可以 Controller 类上加注解 @Scope(“prototype”) 或 @Scope(“request”)，对非 web 项目，在 Component 类上添加注解 @Scope(“prototype”) 。

这种方式实现起来非常简单，但是很大程度上增大了 Bean 创建实例化销毁的服务器资源开销。

2、尽量避免使用成员变量

在业务允许的条件下，可以将成员变量替换为方法中的局部变量。这种方式个人认为是最恰当的。

3、使用并发安全的类

如果非要在单例Bean中使用成员变量，可以考虑使用并发安全的容器，如 ConcurrentHashMap、ConcurrentHashSet 等等，将我们的成员变量包装到这些并发安全的容器中进行管理即可。

4、分布式或微服务的并发安全

如果还要进一步考虑到微服务或分布式服务的影响，方式3便不合适了。这种情况下可以借助于可以共享某些信息的分布式缓存中间件，如Redis等。这样即可保证同一种服务的不同服务实例都拥有同一份共享信息了。

[baa5f726b4404f7eb3b22efc1d73ed4b.png]: https://img-blog.csdnimg.cn/baa5f726b4404f7eb3b22efc1d73ed4b.png
[fd17466e9df54da9b528ff0638e45730.png]: https://img-blog.csdnimg.cn/fd17466e9df54da9b528ff0638e45730.png
[0c4575f633d744158ff96ed4ac1a3015.png]: https://img-blog.csdnimg.cn/0c4575f633d744158ff96ed4ac1a3015.png
[fccf88bc6f784bf5a8a65c89ba960343.png]: https://img-blog.csdnimg.cn/fccf88bc6f784bf5a8a65c89ba960343.png