Java面试题系列（六）——Java EE

1. Spring

Spring的模块大概分为6个。分别是：

-   Core Container（Spring的核心）【重要】
-   AOP（面向切面变成）【重要】
-   Messaging（消息发送的支持）
-   Data Access/Integration（数据访问和集成）
-   Web（主要是SpringWeb内容，包括MVC）【重要】
-   Test（Spring测试支持，包含JUint等测试单元的支持）
-   Instrumentation（设备支持，比如Tomcat的支持）

2. spring框架的优点

Spring是一个轻量级的DI和AOP容器框架，在项目的中的使用越来越广泛，它的优点主要有以下几点：

• Spring是一个非侵入式框架，其目标是使应用程序代码对框架的依赖最小化，应用代码可以在没有Spring或者其他容器的情况运行。
• Spring提供了一个一致的编程模型，使应用直接使用POJO开发，从而可以使运行环境隔离开来。
• Spring推动应用的设计风格向面向对象及面向接口编程转变，提高了代码的重用性和可测试性。
• Spring改进了结构体系的选择，虽然作为应用平台，Spring可以帮助我们选择不同的技术实现，比如从Hibernate切换到其他的ORM工具，从Struts切换到Spring MVC，尽管我们通常不会这么做，但是我们在技术方案上选择使用Spring作为应用平台，Spring至少为我们提供了这种可能性的选择，从而降低了平台锁定风险。

3. Spring用到的设计模式

• 单例模式：bean默认为单例模式
• 工厂模式：beanfactory就是简单工厂模式的体现，用来创建对象实例
• 代理模式：AOP用到的jdk动态代理和CGLB字节码生成技术
• 模板方法：用来解决代码重复问题，如RestTemplate， JmsTemplate， JpaTemplate。
• 观察者模式：定义对象间一种一对多的依赖关系，当一个对象发生改变时，所有依赖他的对象都会被通知更新，如listener的实现

4. SpringMVC处理请求流程

image.png

5. springmvc和spring-boot区别

  Spring 就像一个大家族，有众多衍生产品例如 Boot，Security，JPA等等。但他们的基础都是Spring 的 IOC 和 AOP，IOC提供了依赖注入的容器，而AOP解决了面向切面的编程，然后在此两者的基础上实现了其他衍生产品的高级功能；因为 Spring 的配置非常复杂，各种xml，properties处理起来比较繁琐。于是为了简化开发者的使用，Spring社区创造性地推出了Spring Boot，它遵循约定优于配置，极大降低了Spring使用门槛，但又不失Spring原本灵活强大的功能。

6. Springboot

• 定义：SpringBoot是由Pivotal团队在2013年开始研发、2014年4月发布第一个版本的全新开源的轻量级框架。它基于Spring4.0设计，不仅继承了Spring框架原有的优秀特性，而且还通过简化配置来进一步简化了Spring应用的整个搭建和开发过程。另外SpringBoot通过集成大量的框架使得依赖包的版本冲突，以及引用的不稳定性等问题得到了很好的解决。
• 特征
  （1）可以创建独立的Spring应用程序，并且基于其Maven或Gradle插件，可以创建可执行的JARs和WARs；
  （2）内嵌Tomcat或Jetty等Servlet容器；
  （3）提供自动配置的“starter”项目对象模型（POMS）以简化Maven配置；
  （4）尽可能自动配置Spring容器；
  （5）提供准备好的特性，如指标、健康检查和外部化配置；
  （6）绝对没有代码生成，不需要XML配置。
• 策略：开箱即用和约定优于配置
  (1) 开箱即用，Outofbox，是指在开发过程中，通过在MAVEN项目的pom文件中添加相关依赖包，然后使用对应注解来代替繁琐的XML配置文件以管理对象的生命周期。这个特点使得开发人员摆脱了复杂的配置工作以及依赖的管理工作，更加专注于业务逻辑。
  (2) 约定优于配置，Convention over configuration，是一种由SpringBoot本身来配置目标结构，由开发者在结构中添加信息的软件设计范式。这一特点虽降低了部分灵活性，增加了BUG定位的复杂性，但减少了开发人员需要做出决定的数量，同时减少了大量的XML配置，并且可以将代码编译、测试和打包等工作自动化。

7. Spring中自动装配的方式

• no：不进行自动装配，手动设置Bean的依赖关系。
• byName：根据Bean的名字进行自动装配。
• byType：根据Bean的类型进行自动装配。
• constructor：类似于byType，不过是应用于构造器的参数，如果正好有一个Bean与构造器的参数类型相同则可以自动装配，否则会导致错误。
• autodetect：如果有默认的构造器，则通过constructor的方式进行自动装配，否则使用byType的方式进行自动装配。

8. @Autowired 和@Resource

• 共同点：两者都可以写在字段和setter方法上。两者如果都写在字段上，那么就不需要再写setter方法。
• 不同点
  1)@Autowired为Spring提供的注解，需要导入包org.springframework.beans.factory.annotation.Autowired；只按照byType注入。@Autowired注解是按照类型（byType）装配依赖对象，默认情况下它要求依赖对象必须存在，如果允许null值，可以设置它的required属性为false。如果我们想使用按照名称（byName）来装配，可以结合@Qualifier注解一起使用。
  2)@Resource默认按照byName自动注入，由J2EE提供，需要导入包javax.annotation.Resource。@Resource有两个重要的属性：name和type，而Spring将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。所以，如果使用name属性，则使用byName的自动注入策略，而使用type属性时则使用byType自动注入策略。如果既不制定name也不制定type属性，这时将通过反射机制使用byName自动注入策略。

9. Spring中Bean的作用域

image.png

10. Bean在什么时候被实例化？

• 对于Prototype： 在第一次请求的时候才被实例化的
• 对于Singleton：
  1)一般在IoC容器启动的时候就被实例化，然后被缓存在内存中
  2)如果bean标签中有设置lazy-init=true，则会在第一次请求时才会被实例化，而不是在容器启动的时候就被实例化
  3)但是，当一个懒实例化的Bean依赖了一个非懒实例化的Bean，那么IOC容器在启动的时候也会实例化这个Bean，因为它必须满足单例的依赖性

11. Bean的生命周期

image.png

如上图所示，Bean 的生命周期还是比较复杂的，下面来对上图每一个步骤做文字描述：

1)Spring启动，查找并加载需要被Spring管理的bean，进行Bean的实例化
2)Bean实例化后对将Bean的引入和值注入到Bean的属性中
3)如果Bean实现了BeanNameAware接口的话，Spring将Bean的Id传递给setBeanName()方法
4)如果Bean实现了BeanFactoryAware接口的话，Spring将调用setBeanFactory()方法，将BeanFactory容器实例传入
5)如果Bean实现了ApplicationContextAware接口的话，Spring将调用Bean的setApplicationContext()方法，将bean所在应用上下文引用传入进来。
6)如果Bean实现了BeanPostProcessor接口，Spring就将调用他们的postProcessBeforeInitialization()方法。
7)如果Bean 实现了InitializingBean接口，Spring将调用他们的afterPropertiesSet()方法。类似的，如果bean使用init-method声明了初始化方法，该方法也会被调用
8)如果Bean 实现了BeanPostProcessor接口，Spring就将调用他们的postProcessAfterInitialization()方法。
9)此时，Bean已经准备就绪，可以被应用程序使用了。他们将一直驻留在应用上下文中，直到应用上下文被销毁。
10)如果bean实现了DisposableBean接口，Spring将调用它的destory()接口方法，同样，如果bean使用了destory-method 声明销毁方法，该方法也会被调用。

12. Spring Bean的加载过程

• 获取 BeanName，对传入的 name 进行解析，转化为可以从 Map 中获取到 BeanDefinition 的 bean name。
• 合并 Bean 定义，对父类的定义进行合并和覆盖，如果父类还有父类，会进行递归合并，以获取完整的 Bean 定义信息。
• 实例化，使用构造或者工厂方法创建 Bean 实例。
• 属性填充，寻找并且注入依赖，依赖的 Bean 还会递归调用 getBean 方法获取。
• 初始化，调用自定义的初始化方法。
• 获取最终的 Bean，如果是 FactoryBean 需要调用 getObject 方法，如果需要类型转换调用 TypeConverter 进行转化。

13. IOC和DI

  IoC叫控制反转，是Inversion of Control的缩写，DI（Dependency Injection）叫依赖注入，是对IoC更简单的诠释。控制反转是把传统上由程序代码直接操控的对象的调用权交给容器，通过容器来实现对象组件的装配和管理。所谓的"控制反转"就是对组件对象控制权的转移，从程序代码本身转移到了外部容器，由容器来创建对象并管理对象之间的依赖关系。
  依赖注入的基本原则是应用组件不应该负责查找资源或者其他依赖的协作对象。配置对象的工作应该由容器负责，查找资源的逻辑应该从应用组件的代码中抽取出来，交给容器来完成。DI是对IoC更准确的描述，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中。
  一个类A需要用到接口B中的方法，那么就需要为类A和接口B建立关联或依赖关系，最原始的方法是在类A中创建一个接口B的实现类C的实例，但这种方法需要开发人员自行维护二者的依赖关系，也就是说当依赖关系发生变动的时候需要修改代码并重新构建整个系统。如果通过一个容器来管理这些对象以及对象的依赖关系，则只需要在类A中定义好用于关联接口B的方法（构造器或setter方法），将类A和接口B的实现类C放入容器中，通过对容器的配置来实现二者的关联。
  依赖注入可以通过setter方法注入（设值注入）、构造器注入和接口注入三种方式来实现，Spring支持setter注入和构造器注入，通常使用构造器注入来注入必须的依赖关系，对于可选的依赖关系，则setter注入是更好的选择，setter注入需要类提供无参构造器或者无参的静态工厂方法来创建对象。

• 实现IOC的步骤
  1)定义用来描述bean的配置的Java类
  2)解析bean的配置，將bean的配置信息转换为BeanDefinition对象保存在内存中，spring中采用HashMap进行对象存储，其中会用到一些xml解析技术
  3)遍历存放BeanDefinition的HashMap对象，逐条取出BeanDefinition对象，获取bean的配置信息，利用Java的反射机制实例化对象，將实例化后的对象保存在另外一个Map中即可。

14. AOP

  AOP（Aspect Oriented Programming），即面向切面编程，可以说是OOP（Object Oriented Programming，面向对象编程）的补充和完善。OOP引入封装、继承、多态等概念来建立一种对象层次结构，用于模拟公共行为的一个集合。不过OOP允许开发者定义纵向的关系，但并不适合定义横向的关系，例如日志功能。日志代码往往横向地散布在所有对象层次中，而与它对应的对象的核心功能毫无关系对于其他类型的代码，如安全性、异常处理和透明的持续性也都是如此，这种散布在各处的无关的代码被称为横切（cross cutting），在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。
  AOP技术恰恰相反，它利用一种称为"横切"的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其命名为"Aspect"，即切面。所谓"切面"，简单说就是那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块之间的耦合度，并有利于未来的可操作性和可维护性。使用"横切"技术，AOP把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处基本相似，比如权限认证、日志、事务。AOP的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。
  Spring AOP中的动态代理主要有两种方式，JDK动态代理和CGLIB字节码生成技术。JDK动态代理通过反射来接收被代理的类，并且要求被代理的类必须实现一个接口。JDK动态代理的核心是InvocationHandler接口和Proxy类。CGLIB（Code Generation Library），是一个代码生成的类库，可以在运行时动态的生成某个类的子类，注意，CGLIB是通过继承的方式做的动态代理，因此如果某个类被标记为final，那么它是无法使用CGLIB做动态代理的。

• 动态代理应用场景：
  1)统计每个 api 的请求耗时
  2)统一的日志输出
  3)校验被调用的 api 是否已经登录和权限鉴定
  4)Spring的 AOP 功能模块就是采用动态代理的机制来实现切面编程
• JDK是基于反射机制，生成一个实现代理接口的匿名类，然后重写方法，实现方法的增强。它生成类的速度很快，但是运行时因为是基于反射，调用后续的类操作会很慢.而且他是只能针对接口编程的。
• CGLIB是基于继承机制，继承被代理类，所以方法不要声明为final，然后重写父类方法达到增强了类的作用。它底层是基于asm第三方框架，是对代理对象类的class文件加载进来，通过修改其字节码生成子类来处理。生成类的速度慢，但是后续执行类的操作时候很快。可以针对类和接口。
• 因为jdk是基于反射，CGLIB是基于字节码。所以性能上会有差异。在老版本CGLIB的速度是JDK速度的10倍左右，但是CGLIB启动类比JDK慢8倍左右，但是实际上JDK的速度在版本升级的时候每次都提高很多性能，而CGLIB仍止步不前。
• 在对JDK动态代理与CGlib动态代理的代码实验中看，1W次执行下，JDK7及8的动态代理性能比CGlib要好20%左右。
• 具体应用：
  • 如果目标对象实现了接口，默认情况下是采用JDK动态实现AOP
  • 如果目标对象没有实现接口，必须采用CGLIB库.

15. Spring中BeanFactory和ApplicationContext的区别

• BeanFactory是spring中比较原始，比较古老的Factory。因为比较古老，所以BeanFactory无法支持spring插件，例如：AOP、Web应用等功能。
• ApplicationContext是BeanFactory的子类，因为古老的BeanFactory无法满足不断更新的spring的需求，于是ApplicationContext就基本上代替了BeanFactory的工作，以一种更面向框架的工作方式以及对上下文进行分层和实现继承
• 区别：
  1)如果使用ApplicationContext，如果配置的bean是singleton，那么不管你有没有或想不想用它，它都会被实例化。好处是可以预先加载，坏处是浪费内存。
  2)BeanFactory，当使用BeanFactory实例化对象时，配置的bean不会马上被实例化，而是等到你使用该bean的时候（getBean）才会被实例化。好处是节约内存，坏处是速度比较慢。多用于移动设备的开发。
  3)没有特殊要求的情况下，应该使用ApplicationContext完成。因为BeanFactory能完成的事情，ApplicationContext都能完成，并且提供了更多接近现在开发的功能。

16. Spring支持的事务管理类型

  Spring支持编程式事务管理和声明式事务管理。许多Spring框架的用户选择声明式事务管理，因为这种方式和应用程序的关联较少，因此更加符合轻量级容器的概念。声明式事务管理要优于编程式事务管理，尽管在灵活性方面它弱于编程式事务管理，因为编程式事务允许你通过代码控制业务。
  事务分为全局事务和局部事务。全局事务由应用服务器管理，需要底层服务器JTA支持（如WebLogic、WildFly等）。局部事务和底层采用的持久化方案有关，例如使用JDBC进行持久化时，需要使用Connetion对象来操作事务；而采用Hibernate进行持久化时，需要使用Session对象来操作事务。
  这些事务的父接口都是PlatformTransactionManager。Spring的事务管理机制是一种典型的策略模式，PlatformTransactionManager代表事务管理接口，该接口定义了三个方法，该接口并不知道底层如何管理事务，但是它的实现类必须提供getTransaction()方法（开启事务）、commit()方法（提交事务）、rollback()方法（回滚事务）的多态实现，这样就可以用不同的实现类代表不同的事务管理策略。使用JTA全局事务策略时，需要底层应用服务器支持，而不同的应用服务器所提供的JTA全局事务可能存在细节上的差异，因此实际配置全局事务管理器是可能需要使用JtaTransactionManager的子类，如：WebLogicJtaTransactionManager（Oracle的WebLogic服务器提供）、UowJtaTransactionManager（IBM的WebSphere服务器提供）等。

17. Spring MVC注解的优点

• XML配置起来有时候冗长，此时注解可能是更好的选择，如jpa的实体映射；注解在处理一些不变的元数据时有时候比XML方便的多，比如springmvc的数据绑定，如果用xml写的代码会多的多；
• 注解最大的好处就是简化了XML配置；其实大部分注解一旦确定后很少会改变，所以在一些中小项目中使用注解反而提供了开发效率；
• 注解相对于XML的另一个好处是类型安全的，XML只能在运行期才能发现问题。

18. @Controller和@RestController

@RestController注解相当于@ResponseBody ＋ @Controller合在一起的作用

• 如果只是使用@RestController注解Controller，则Controller中的方法无法返回jsp页面，或者html，配置的视图解析器 InternalResourceViewResolver不起作用，返回的内容就是Return 里的内容。
• 如果需要返回到指定页面，则需要用 @Controller配合视图解析器InternalResourceViewResolver才行。
  如果需要返回JSON，XML或自定义mediaType内容到页面，则需要在对应的方法上加上@ResponseBody注解。

19. SpringMVC的Controller是单例还是多例，有没有并发安全问题，如何解决？

• Controller默认是单例，可以通过@Scope(“prototype”)设置为多例模式，如果定义了成员变量就有并发问题，单例是不安全的，会导致属性重复使用。
• 解决方案
  1)不要在controller中定义成员变量。
  2)万一必须要定义一个非静态成员变量时候，则通过注解@Scope(“prototype”)，将其设置为多例模式。
  3)在Controller中使用ThreadLocal变量

20. 持久层

  持久就是将内存中的数据保存到关系型数据库、文件系统、消息队列等提供持久化支持的设备中。持久层就是系统中专注于实现数据持久化的相对独立的层面。
持久层设计的目标包括：

• 数据存储逻辑的分离，提供抽象化的数据访问接口。
• 数据访问底层实现的分离，可以在不修改代码的情况下切换底层实现。
• 资源管理和调度的分离，在数据访问层实现统一的资源调度（如缓存机制）。
• 数据抽象，提供更面向对象的数据操作。

21. Mybatis动态SQL

https：//www.cnblogs.com/ysocean/p/7289529.html

-   if 语句
-   if+where 语句
-   if+set 语句
-   choose(when，otherwise) 语句
-   trim 语句
-   SQL 片段
-   foreach 语句

22. mybatis 一级缓存和二级缓存区别

• 一级缓存基于sqlSession默认开启，在操作数据库时需要构造SqlSession对象，在对象中有一个HashMap用于存储缓存数据。不同的SqlSession之间的缓存数据区域是互相不影响的。一级缓存的作用域是SqlSession范围的，当在同一个sqlSession中执行两次相同的sql语句时，第一次执行完毕会将数据库中查询的数据写到缓存（内存），第二次查询时会从缓存中获取数据，不再去底层数据库查询，从而提高查询效率。如果SqlSession执行了DML操作（增删改），并且提交到数据库，MyBatis则会清空SqlSession中的一级缓存，这样做的目的是为了保证缓存中存储的是最新的信息，避免出现脏读现象。当一个SqlSession结束后该SqlSession中的一级缓存也就不存在了。
• 二级缓存是mapper级别的缓存。使用二级缓存时，多个SqlSession使用同一个Mapper的sql语句去操作数据库，得到的数据会存在二级缓存区域，它同样是使用HashMap进行数据存储。相比一级缓存SqlSession，二级缓存的范围更大，多个Sqlsession可以共用二级缓存，二级缓存是跨SqlSession的。二级缓存的作用域是mapper的同一个namespace。不同的sqlSession两次执行相同的namespace下的sql语句，且向sql中传递的参数也相同，即最终执行相同的sql语句，则第一次执行完毕会将数据库中查询的数据写到缓存，第二次查询会从缓存中获取数据，不再去底层数据库查询，从而提高效率。

23. Mybatis和Hibernate的区别

• Mybatis常见面试题：https：//www.cnblogs.com/qmillet/p/12523636.html
• Mybatis和Hibernate的区别：https：//www.cnblogs.com/lixuwu/p/10941649.html
  （1）hibernate是全自动，而mybatis是半自动
  hibernate完全可以通过对象关系模型实现对数据库的操作，拥有完整的JavaBean对象与数据库的映射结构来自动生成sql。而mybatis仅有基本的字段映射，对象数据以及对象实际关系仍然需要通过手写sql来实现和管理。
  （2）hibernate数据库移植性远大于mybatis
  hibernate通过它强大的映射结构和hql语言，大大降低了对象与数据库（Oracle、MySQL等）的耦合性，而mybatis由于需要手写sql，因此与数据库的耦合性直接取决于程序员写sql的方法，如果sql不具通用性而用了很多某数据库特性的sql语句的话，移植性也会随之降低很多，成本很高。
  （3）hibernate拥有完整的日志系统，mybatis则欠缺一些
  hibernate日志系统非常健全，涉及广泛，包括：sql记录、关系异常、优化警告、缓存提示、脏数据警告等；而mybatis则除了基本记录功能外，功能薄弱很多。
  （4）mybatis相比hibernate需要关心很多细节
  hibernate配置要比mybatis复杂的多，学习成本也比mybatis高。但也正因为mybatis使用简单，才导致它要比hibernate关心很多技术细节。mybatis由于不用考虑很多细节，开发模式上与传统jdbc区别很小，因此很容易上手并开发项目，但忽略细节会导致项目前期bug较多，因而开发出相对稳定的软件很慢，而开发出软件却很快。hibernate则正好与之相反。但是如果使用hibernate很熟练的话，实际上开发效率丝毫不差于甚至超越mybatis。
  （5）sql直接优化上，mybatis要比hibernate方便很多
  由于mybatis的sql都是写在xml里，因此优化sql比hibernate方便很多。而hibernate的sql很多都是自动生成的，无法直接维护sql；虽有hql，但功能还是不及sql强大，见到报表等变态需求时，hql也歇菜，也就是说hql是有局限的；hibernate虽然也支持原生sql，但开发模式上却与orm不同，需要转换思维，因此使用上不是非常方便。总之写sql的灵活度上hibernate不及mybatis。
  （6）缓存机制上，hibernate要比mybatis更好一些
  MyBatis的二级缓存配置都是在每个具体的表-对象映射中进行详细配置，这样针对不同的表可以自定义不同的缓存机制。并且Mybatis可以在命名空间中共享相同的缓存配置和实例，通过Cache-ref来实现。