Spring 面试题

最新推荐文章于 2023-05-08 14:41:58 发布

G5513

最新推荐文章于 2023-05-08 14:41:58 发布

阅读量299

点赞数

分类专栏：面试

本文链接：https://blog.csdn.net/Same_Liu/article/details/89919021

版权

面试专栏收录该内容

2 篇文章 0 订阅

订阅专栏

1.Spring拦截器实现了哪些方法？底层原理？

// HandlerInterceptor.java

/**
 * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行之前
 */
default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
		throws Exception {
	return true;
}

/**
 * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行成功之后
 */
default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
		@Nullable ModelAndView modelAndView) throws Exception {
}

/**
 * 拦截处理器，在 {@link HandlerAdapter#handle(HttpServletRequest, HttpServletResponse, Object)} 执行完之后，无论成功还是失败
 *
 * 并且，只有该处理器 {@link #preHandle(HttpServletRequest, HttpServletResponse, Object)} 执行成功之后，才会被执行
 */
default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
		@Nullable Exception ex) throws Exception {
}

一共有三个方法，分别为：

#preHandle(…) 方法，调用 Controller 方法之前执行。
#postHandle(…) 方法，调用 Controller 方法之后执行。
#afterCompletion(…) 方法，处理完 Controller 方法返回结果之后执行。
- 例如，页面渲染后。
- 当然，要注意，无论调用 Controller 方法是否成功，都会执行。
举个例子：
- 当俩个拦截器都实现放行操作时，执行顺序为 preHandle[1] => preHandle[2] => postHandle[2] => postHandle[1] => afterCompletion[2] => afterCompletion[1] 。
- 当第一个拦截器 #preHandle(…) 方法返回 false ，也就是对其进行拦截时，第二个拦截器是完全不执行的，第一个拦截器只执行 #preHandle(…) 部分。
- 当第一个拦截器 #preHandle(…) 方法返回 true ，第二个拦截器 #preHandle(…) 返回 false ，执行顺序为 preHandle[1] => preHandle[2] => afterCompletion[1] 。
总结来说：
- #preHandle(…) 方法，按拦截器定义顺序调用。若任一拦截器返回 false ，则 Controller 方法不再调用。
- #postHandle(…) 和 #afterCompletion(…) 方法，按拦截器定义逆序调用。
- #postHandler(…) 方法，在调用 Controller 方法之后执行。
- #afterCompletion(…) 方法，只有该拦截器在 #preHandle(…) 方法返回 true 时，才能够被调用，且一定会被调用。为什么“且一定会被调用”呢？即使 #afterCompletion(…) 方法，按拦截器定义逆序调用时，前面的拦截器发生异常，后面的拦截器还能够调用，即无视异常。

拦截器能做的事情非常非常非常多，例如：

记录访问日志。
记录异常日志。
需要登陆的请求操作，拦截未登陆的用户。

Spring MVC 的拦截器和 Filter 过滤器有什么差别？

功能相同：拦截器和 Filter都能实现相应的功能，谁也不比谁强。
容器不同：拦截器构建在 Spring MVC 体系中；Filter 构建在 Servlet 容器之上。
使用便利性不同：拦截器提供了三个方法，分别在不同的时机执行；过滤器仅提供一个方法，当然也能实现拦截器的执行时机的效果，就是麻烦一些。

我们会发现，拓展性好的框架，都会提供相应的拦截器或过滤器机制，方便的我们做一些拓展。例如：

Dubbo 的 Filter 机制。
Spring Cloud Gateway 的 Filter 机制。
Struts2 的拦截器机制。

2. Spring AOP如何配置，底层原理、2种动态代理，aop注解实现，xml定义切面。

AOP，一般称为面向切面，作为面向对象的一种补充，用于将那些与业务无关，但却对多个对象产生影响的公共行为和逻辑，抽取并封装为一个可重用的模块，这个模块被命名为“切面”（Aspect），减少系统中的重复代码，降低了模块间的耦合度，同时提高了系统的可维护性。可用于权限认证、日志、事务处理。
AOP实现的关键在于代理模式，AOP代理主要分为静态代理和动态代理。静态代理的代表为AspectJ；动态代理则以Spring AOP为代表。
（1）AspectJ是静态代理的增强，所谓静态代理，就是AOP框架会在编译阶段生成AOP代理类，因此也称为编译时增强，他会在编译阶段将AspectJ(切面)织入到Java字节码中，运行的时候就是增强之后的AOP对象。
（2）Spring AOP使用的动态代理，所谓的动态代理就是说AOP框架不会去修改字节码，而是每次运行时在内存中临时为方法生成一个AOP对象，这个AOP对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法。
- Spring AOP中的动态代理主要有两种方式，JDK动态代理和CGLIB动态代理：
  ①JDK动态代理只提供接口的代理，不支持类的代理。核心InvocationHandler接口和Proxy类，InvocationHandler 通过invoke()方法反射来调用目标类中的代码，动态地将横切逻辑和业务编织在一起；接着，Proxy利用 InvocationHandler动态创建一个符合某一接口的的实例, 生成目标类的代理对象。
  ②如果代理类没有实现 InvocationHandler 接口，那么Spring AOP会选择使用CGLIB来动态代理目标类。CGLIB（Code Generation Library），是一个代码生成的类库，可以在运行时动态的生成指定类的一个子类对象，并覆盖其中特定方法并添加增强代码，从而实现AOP。CGLIB是通过继承的方式做的动态代理，因此如果某个类被标记为final，那么它是无法使用CGLIB做动态代理的。
（3）静态代理与动态代理区别在于生成AOP代理对象的时机不同，相对来说AspectJ的静态代理方式具有更好的性能，但是AspectJ需要特定的编译器进行处理，而Spring AOP则无需特定的编译器处理。
InvocationHandler 的 invoke(Object proxy,Method method,Object[] args)：proxy是最终生成的代理实例; method 是被代理目标实例的某个具体方法; args 是被代理目标实例某个方法的具体入参, 在方法反射调用时使用。
AOP注解和XML配置使用方式：
配置xml开启扫描：

	<!-- 开启包扫描 -->
    <context:component-scan base-package="指定要扫描的包的范围"/>
    <!-- 开启aop注解 -->
    <aop:aspectj-autoproxy/>

AOP常用注解：
- @Aspect ：定义切面类
- @Before :前置通知
- @AfterReturning:后置通知
- @Around :环绕通知
- @AfterThrowing:异常抛出通知
- @After :最终通知
- @Pointcut :定义切入点
使用方法：

@Component("myAspect")
@Aspect
public class MyAspect {
    @Before("execution(* * com..service.*.*(..))")
    public void before(){
        System.out.println("前置增强执行了。。。");
    }
}

切入点的使用：

@Pointcut("execution(* com..service.*.*(..))")
    public void pointcut1() {
    }

    // 前置增强
    @Before("pointcut1()")
    public void mybefore() {
        System.out.println("前置方法");
    }
    // 后置增强
    @AfterReturning("pointcut1()")
    public void myreturning() {
        System.out.println("后置方法");
    }

AOP纯注解配置方式：
编写一个配置类来取代XML文件：

@Configuration //表示当前类是配置类
@ComponentScan("指定要扫描的包的范围") //开启包扫描器
@EnableAspectJAutoProxy  //开启aop注解扫描
public class SpringConfiguration {
}

//获取容器的方法
ApplicationContext ac = 
            new AnnotationConfigApplicationContext(SpringConfiguration.class);

3.Bean的作用域，单例模式是否线程安全？恶汉模式是否线程安全？bean如何结束生命周期？

Spring容器中的bean可以分为5个范围：
- singleton：默认，每个容器中只有一个bean的实例，单例的模式由BeanFactory自身来维护。
- prototype：为每一个bean请求提供一个实例。
- request：为每一个网络请求创建一个实例，在请求完成以后，bean会失效并被垃圾回收器回收。
- session：与request范围类似，确保每个session中有一个bean的实例，在session过期后，bean会随之失效。
- global-session：全局作用域，global-session和Portlet应用相关。当你的应用部署在Portlet容器中工作时，它包含很多portlet。如果你想要声明让所有的portlet共用全局的存储变量的话，那么这全局变量需要存储在global-session中。全局作用域与Servlet中的session作用域效果相同。
Spring框架并没有对单例bean进行任何多线程的封装处理。关于单例bean的线程安全和并发问题需要开发者自行去搞定。但实际上，大部分的Spring bean并没有可变的状态(比如Serview类和DAO类)，所以在某种程度上说Spring的单例bean是线程安全的。如果你的bean有多种状态的话（比如 View Model 对象），就需要自行保证线程安全。最浅显的解决办法就是将多态bean的作用域由“singleton”变更为“prototype”。
饿汉式是线程安全的，因为在类被加载的时候创建实例。
Spring上下文中的Bean生命周期也类似，如下：
- 实例化Bean：对于BeanFactory容器，当客户向容器请求一个尚未初始化的bean时，或初始化bean的时候需要注入另一个尚未初始化的依赖时，容器就会调用createBean进行实例化。对于ApplicationContext容器，当容器启动结束后，通过获取BeanDefinition对象中的信息，实例化所有的bean。
- 设置对象属性（依赖注入）：实例化后的对象被封装在BeanWrapper对象中，紧接着，Spring根据BeanDefinition中的信息以及通过BeanWrapper提供的设置属性的接口完成依赖注入。
- 处理Aware接口：接着，Spring会检测该对象是否实现了xxxAware接口，并将相关的xxxAware实例注入给Bean：
1. 如果这个Bean已经实现了BeanNameAware接口，会调用它实现的setBeanName(String beanId)方法，此处传递的就是Spring配置文件中Bean的id值；
2. 如果这个Bean已经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory()方法，传递的是Spring工厂自身。
3. 如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文；
- BeanPostProcessor：如果想对Bean进行一些自定义的处理，那么可以让Bean实现了BeanPostProcessor接口，那将会调用postProcessBeforeInitialization(Object obj, String s)方法。由于这个方法是在Bean初始化结束时调用的，所以可以被应用于内存或缓存技术；
- InitializingBean 与 init-method：如果Bean在Spring配置文件中配置了 init-method 属性，则会自动调用其配置的初始化方法。
- 如果这个Bean实现了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法；
  以上几个步骤完成后，Bean就已经被正确创建了，之后就可以使用这个Bean了。
- DisposableBean：当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean这个接口，会调用其实现的destroy()方法；
- destroy-method：最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法。

4.Spring事务种类，如何回滚，A方法调用B方法，在B方法中出现异常，会回滚吗？（动态代理）。

Spring支持编程式事务管理和声明式事务管理两种方式：
- 编程式事务管理使用TransactionTemplate。
- 声明式事务管理建立在AOP之上的。其本质是通过AOP功能，对方法前后进行拦截，将事务处理的功能编织到拦截的方法中，也就是在目标方法开始之前加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。
  - 声明式事务最大的优点就是不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明或通过@Transactional注解的方式，便可以将事务规则应用到业务逻辑中。
  - 声明式事务管理要优于编程式事务管理，这正是spring倡导的非侵入式的开发方式，使业务代码不受污染，只要加上注解就可以获得完全的事务支持。唯一不足地方是，最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。
Spring事务的传播行为说的是，当多个事务同时存在的时候，spring如何处理这些事务的行为。
① PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。
② PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。‘
③ PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。
④ PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。
⑤ PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
⑥ PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。
⑦ PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则按REQUIRED属性执行。

5.SpringBoot 和 Spring MVC的区别？

Spring Boot 是基于spring4整合开发包；
Spring Boot 内嵌tomcat，Jetty和Undertow容器，可以直接运行起来，不在再做部署；
Spring Boot 自动配置，减少了xml文件的大量配置；
Spring MVC是基于 Servlet 的一个 MVC 框架主要解决 WEB 开发的问题，因为 Spring 的配置非常复杂，各种XML、 JavaConfig、hin处理起来比较繁琐。于是为了简化开发者的使用，从而创造性地推出了Spring boot，约定优于配置，简化了spring的配置流程。

6. Spring 中各种 Context 有什么功能，他们之间有什么联系？

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

（1）BeanFactory：是Spring里面最底层的接口，包含了各种Bean的定义，读取bean配置文档，管理bean的加载、实例化，控制bean的生命周期，维护bean之间的依赖关系。ApplicationContext接口作为BeanFactory的派生，除了提供BeanFactory所具有的功能外，还提供了更完整的框架功能：

继承MessageSource，因此支持国际化。
统一的资源文件访问方式。
提供在监听器中注册bean的事件。
同时加载多个配置文件。
载入多个（有继承关系）上下文，使得每一个上下文都专注于一个特定的层次，比如应用的web层。

（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则是自动注册。