java面试题(3)--SSH

java面试题(3)--SSH

博客分类： 

• 面试题

 

Struts

1.struts1和struts2的区别

1. 在Action实现类方面的对比：Struts1要求Action类继承一个抽象基类；Struts1的一个具体问题是使用抽象类编程而不是接口。Struts2 Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去实现常用的接口。即使Action接口不是必须实现的，只有一个包含execute方法的POJO类都可以用作Struts2的Action。
2. 线程模式方面的对比：Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能做的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的；Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。
3. Servlet依赖方面的对比：Struts1 Action依赖于Servlet API，因为Struts1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts2 Action不再依赖于Servlet API，从而允许Action脱离Web容器运行，从而降低了测试Action的难度。 当然，如果Action需要直接访问HttpServletRequest和HttpServletResponse参数，Struts2 Action仍然可以访问它们。但是，大部分时候，Action都无需直接访问HttpServetRequest和HttpServletResponse，从而给开发者更多灵活的选择。
4. 可测性方面的对比：测试Struts1 Action的一个主要问题是execute方法依赖于Servlet API，这使得Action的测试要依赖于Web容器。为了脱离Web容器测试Struts1的Action，必须借助于第三方扩展：Struts TestCase，该扩展下包含了系列的Mock对象（模拟了HttpServetRequest和HttpServletResponse对象），从而可以脱离Web容器测试Struts1的Action类。Struts2 Action可以通过初始化、设置属性、调用方法来测试。
5. 封装请求参数的对比：Struts1使用ActionForm对象封装用户的请求参数，所有的ActionForm必须继承一个基类：ActionForm。普通的JavaBean不能用作ActionForm，因此，开发者必须创建大量的ActionForm类封装用户请求参数。虽然Struts1提供了动态ActionForm来简化ActionForm的开发，但依然需要在配置文件中定义ActionForm；Struts2直接使用Action属性来封装用户请求属性，避免了开发者需要大量开发ActionForm类的烦琐，实际上，这些属性还可以是包含子属性的Rich对象类型。如果开发者依然怀念Struts1 ActionForm的模式，Struts2提供了ModelDriven模式，可以让开发者使用单独的Model对象来封装用户请求参数，但该Model对象无需继承任何Struts2基类，是一个POJO，从而降低了代码污染。
6. 表达式语言方面的对比：Struts1整合了JSTL，因此可以使用JSTL表达式语言。这种表达式语言有基本对象图遍历，但在对集合和索引属性的支持上则功能不强；Struts2可以使用JSTL，但它整合了一种更强大和灵活的表达式语言：OGNL（Object Graph Notation Language），因此，Struts2下的表达式语言功能更加强大。
7. 绑定值到视图的对比：Struts1使用标准JSP机制把对象绑定到视图页面；Struts2使用“ValueStack”技术，使标签库能够访问值，而不需要把对象和视图页面绑定在一起。
8. 类型转换的对比：Struts1 ActionForm 属性通常都是String类型。Struts1使用Commons-Beanutils进行类型转换，每个类一个转换器，转换器是不可配置的；Struts2使用OGNL进行类型转换，支持基本数据类型和常用对象之间的转换。
9. 数据校验的对比：Struts1支持在ActionForm重写validate方法中手动校验，或者通过整合Commons alidator框架来完成数据校验。Struts2支持通过重写validate方法进行校验，也支持整合XWork校验框架进行校验。
10. Action执行控制的对比：Struts1支持每一个模块对应一个请求处理（即生命周期的概念），但是模块中的所有Action必须共享相同的生命周期。Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。开发者可以根据需要创建相应堆栈，从而和不同的Action一起使用。

2.Struts2的工作机制

1. 客户端初始化一个指向Servlet容器（例如Tomcat）的请求；
2. 这个请求经过一系列的过滤器（Filter）（这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器，这个过滤器对于Struts2和其他框架的集成很有帮助，例如：SiteMesh Plugin）；
3. 接着FilterDispatcher被调用，FilterDispatcher询问ActionMapper来决定这个请求是否需要调用某个Action；
4. 如果ActionMapper决定需要调用某个Action，FilterDispatcher把请求的处理交给ActionProxy；
5. ActionProxy通过Configuration Manager询问框架的配置文件，找到需要调用的Action类；
6. ActionProxy创建一个ActionInvocation的实例；
7. ActionInvocation实例使用命名模式来调用，在调用Action的过程前后，涉及到相关拦截器（Intercepter）的调用；
8. 一旦Action执行完毕，ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果通常是（但不总是，也可 能是另外的一个Action链）一个需要被表示的JSP或者FreeMarker的模版。在表示的过程中可以使用Struts2 框架中继承的标签。在这个过程中需要涉及到ActionMapper。

 

Hibernate

1.为什么使用hibernate

1. 对JDBC操作提供封装,方便操作简化数据库访问的代码
2. 简化DAO层的代码量ORM从关系型DB到面向对象(java)的转变
3. 在java代码中充斥着大量的sql语句不便于维护,但是ORM映射可以减少此类代码,便于维护
4. 数据库可移植性好
5. 缓存机制，提供了一级缓存和二级缓存

2.Hibernate与ibatis区别

ibatis优点：

1. iBatis的特性更容易进行SQL的优化
2. iBatis的特性是可以进行细粒度的优化。比如说我有一个表，这个表有几个或者几十个字段，我需要更新其中的一个字段，如果我需要更新一条记录（一个对象），如果使用Hibernate，需要现把对象 select 出来，然后再做 update。这对数据库来说就是两条SQL。而iBatis只需要一条 update 的SQL就可以了。减少一次与数据库的交互，对于性能的提升是非常重要。我需要列出一个表的部分内容，用iBatis的时候，这里面的好处是可以少从数据库读很多数据，节省流量。一般情况下Hibernate会把所有的字段都选出来。比如说有一个上面表有8个字段，其中有一两个比较大的字段。
3. 可维护性方面，我觉得iBatis更好一些。因为iBatis的 SQL都保存到单独的文件中。而Hibernate在有些情况下可能会在 java 代码中保存sql/hql。
4. 在不考虑 cache 的情况下，iBatis 应该会比Hibernate快一些或者很多。

ibatis缺点：

1. 不同数据库类型的支持不好，如果你要开发的系统是要在对中数据间移植，那可能用Hibernate比较好。
2. 缺省的 cache 支持不好，但是Hibernate的 cache 支持其实也不是很好，而且很复杂。尤其是对于大并发量的应用。所以我更倾向于自己管理 cache。

3.hibernate n+1问题

Hibernate中常会用到set，bag等集合表示1对多的关系， 在获取实体的时候就能根据关系将关联的对象或者对象集取出， 还可以设定cacade进行关联更新和删除。这不得部说hibernate的orm做得很好，很贴近oo的使用习惯了。 但是对数据库访问还是必须考虑性能问题的， 在设定了1对多这种关系之后， 查询就会出现传说中的n+1问题。

1. 1对多，在1方，查找得到了n个对象， 那么又需要将n个对象关联的集合取出，于是本来的一条sql查询变成了n+1条
2. 多对1，在多方，查询得到了m个对象，那么也会将m个对象对应的1方的对象取出， 也变成了m+1

怎么解决n+1问题？

1. lazy=true， hibernate3开始已经默认是lazy=true了；lazy=true时不会立刻查询关联对象，只有当需要关联对象（访问其属性，非id字段）时才会发生查询动作。
2. 二级缓存， 在对象更新，删除，添加相对于查询要少得多时， 二级缓存的应用将不怕n+1问题，因为即使第一次查询很慢，之后直接缓存命中也是很快的。

不同解决方法，不同的思路，第二条却刚好又利用了n+1。

 

4.session.load和session.get的区别

1. 两者都是用缓存,load查询数据如果没有会出现Exception ,get会出现null。load 查询 先查一级缓存,如果没有数据则会生成ciglib,在实际使用的时候(也就是lazy=true)查询二级缓存,还没有数据查询数据库,在没有就会出现异常,主意这里是Exception；get 先查询一级缓存,在查询二级缓存最后查询数据库如果没有数据则出现null。
2. load支持lazy , get不支持lazy

5.list和iterate的区别

1. list每次都会发出查询语句，list向缓存中放入数据，但不利用缓存中的数据
2. iterate在默认情况下利用缓存中的数据，只有在缓存中根据id无法找到相应记录时才会到数据库中查找

6.Hibernate的缓存范围

• 事务范围: 一级缓存就属于事务范围
• 应用范围: 二级缓存就属于应用范围
• 集群范围

7.二级缓存中的数据

下面这几种情况就不适合加载到二级缓存中:

1. 经常被修改的数据
2. 绝对不允许出现并发访问的数据
3. 与其他应用共享的数据

下面这己种情况合适加载到二级缓存中:

1. 数据更新频率低
2. 允许偶尔出现并发问题的非重要数据
3. 不会被并发访问的数据
4. 常量数据
5. 不会被第三方修改的数据

 

Spring

1.Spring BeanFactory中Bean的生命周期

1. Bean的建立
2. 属性注入
3. BeanNameAware的setBeanName()
4. BeanFactoryAware的setBeanFactory()
5. BeanPostProcessors的processBeforeInitialization()
6. InitializingBean的afterPropertiesSet()
7. Bean定义文件中定义init-method
8. BeanPostProcessors的processaAfterInitialization()
9. DisposableBean的destroy()
10. Bean定义文件中定义destroy-method

2.Spring ApplicationContext中Bean的生命周期

1. Bean的建立
2. 属性注入
3. BeanNameAware的setBeanName()
4. BeanFactoryAware的setBeanFactory()
5. ApplicationContextAware的setApplicationContext()
6. BeanPostProcessors的processBeforeInitialization()
7. InitializingBean的afterPropertiesSet()
8. Bean定义文件中定义init-method
9. BeanPostProcessors的processaAfterInitialization()
10. DisposableBean的destroy()
11. Bean定义文件中定义destroy-method

3.Spring中ref local与ref bean区别

• ref bean：是寻找全局中的 bean;
• ref local：是寻找本 xml 文件中的 bean

4.Spring事务传播特性

类型	说明
PROPAGATION_REQUIRED	如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。
PROPAGATION_SUPPORTS	支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY	使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW	新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED	以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER	以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED	如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。

 

5.Spring两种事务管理方式

1. 声明式
2. 编程式

6.spring 的优点

1. 降低了组件之间的耦合性 ，实现了软件各层之间的解耦
2. 可以使用容易提供的众多服务，如事务管理，消息服务等
3. 容器提供单例模式支持
4. 容器提供了AOP技术，利用它很容易实现如权限拦截，运行期监控等功能
5. 容器提供了众多的辅助类，能加快应用的开发
6. spring对于主流的应用框架提供了集成支持，如hibernate，JPA，Struts等
7. spring属于低侵入式设计，代码的污染极低
8. 独立于各种应用服务器
9. spring的DI机制降低了业务对象替换的复杂性
10. Spring的高度开放性，并不强制应用完全依赖于Spring，开发者可以自由选择spring的部分或全部

7.什么是DI机制

依赖注入（Dependecy Injection）和控制反转（Inversion of Control）是同一个概念，具体的讲：当某个角色需要另外一个角色协助的时候，在传统的程序设计过程中，通常由调用者来创建被调用者的实例。但在spring中创建被调用者的工作不再由调用者来完成，因此称为控制反转。创建被调用者的工作由spring来完成，然后注入调用者因此也称为依赖注入。

spring以动态灵活的方式来管理对象 ， 注入的两种方式，设置注入和构造注入。

设置注入的优点：直观，自然

构造注入的优点：可以在构造器中决定依赖关系的顺序。

 

8.什么是AOP

面向切面编程（AOP）完善spring的依赖注入（DI），面向切面编程在spring中主要表现为两个方面：

1. 面向切面编程提供声明式事务管理
2. spring支持用户自定义的切面

面向切面编程（aop）是对面向对象编程（oop）的补充，面向对象编程将程序分解成各个层次的对象，面向切面编程将程序运行过程分解成各个切面。AOP从程序运行角度考虑程序的结构，提取业务处理过程的切面，oop是静态的抽象，aop是动态的抽象，是对应用执行过程中的步骤进行抽象，从而获得步骤之间的逻辑划分。

aop框架具有的两个特征：

1. 各个步骤之间的良好隔离性
2. 源代码无关性

9.Spring之BeanFactory与ApplicationConText区别

ApplicationContext和BeanFacotry相比,提供了更多的扩展功能，但其主要区别在于后者是延迟加载,如果Bean的某一个属性没有注入，BeanFacotry加载后，直至第一次使用调用getBean方法才会抛出异常；而ApplicationContext则在初始化自身是检验，这样有利于检查所依赖属性是否注入；所以通常情况下我们选择使用ApplicationContext。