Java笔试必考知识点合集六——Spring专场

1.Servlet中使用过滤器，web.xml中配置

Servlet过滤器的配置包括两部分：

第一部分是过滤器在Web应用中的定义，由<filter>元素表示，包括<filter-name>和<filter-class>两个必需的子元素
第二部分是过滤器映射的定义，由<filter-mapping>元素表示,可以将一个过滤器映射到一个或者多个Servlet或JSP文件，也可以采用url-pattern将过滤器映射到任意特征的URL。

eg:

2.Spring中依赖注入的方式

spring依赖注入有如下几种方式：

①setter方式注入（设值注入）

②构造器方式注入

Spring支持利用构造器注入参数实例化Bean方式。只要在Spring的配置文件中增加构造器参数constructor-arg

Spring就会自动的调用有参数的构造器创建bean对象实例, 整个过程无需程序编码只需要配置applicationContext.xml文件即可

③自动装配功能实现属性自动注入

Spring IoC容器可以自动装配（autowire）相互协作bean之间的关联关系，autowire可以针对单个bean进行设置，

autowire的方便之处在于减少xml的注入配置。

在xml配置文件中，可以在<bean/>元素中使用autowire属性指定自动装配规则，一共有五种类型值：

如果Bean的某一个属性没有注入，BeanFactory加载后，直至第一次使用调用getBean方法才会抛出异常；而ApplicationContext则在初始化自身时检验，这样有利于检查所依赖属性是否注入。

3.Spring DAO的知识点

Spring提供的DAO(数据访问对象)支持主要的目的是便于以标准的方式使用不同的数据访问技术。简化 DAO 组件的开发。 Spring提供了一套抽象DAO类供你扩展。这些抽象类提供了一些方法，用来简化代码开发。

IoC 容器的使用，提供了 DAO 组件与业务逻辑组件之间的解耦。所有的 DAO 组件，都由容器负责注入到业务逻辑组件中，其业务组件无须关心 DAO 组件的实现。
面向接口编程及 DAO 模式的使用，提高了系统组件之间的解耦，降低了系统重构的成本。
方便的事务管理: Spring的声明式事务管理力度是方法级。
异常包装:Spring能够包装Hibernate异常，把它们从CheckedException变为RuntimeException; 开发者可选择在恰当的层处理数据中不可恢复的异常，从而避免烦琐的 catch/throw 及异常声明。

4.Spring框架中如何获取数据库连接池

四种方式，如下：

1：DBCP数据源
DBCP类包位于 <SPRING_HOME>/lib/jakarta-commons/commons-dbcp.jar，DBCP是一个依赖Jakarta commons-pool对象池机制的数据库连接池，所以在类路径下还必须包括<SPRING_HOME>/lib/jakarta-commons/commons-pool.jar。下面是使用DBCP配置oracle数据源的配置片断：
<bean id=”dataSource”
class=”org.apache.commons.dbcp.BasicDataSource” destroy-method=”close”>
<property name=”driverClassName” value=” oracle.jdbc.driver.OracleDriver ” />
<property name=”url” value=”jdbc:oracle:thin:@localhost:1521:orcl ” />
<property name=”username” value=”root” />
<property name=”password” value=”1234″ />

</bean>

2：C3P0数据源

C3P0是一个开放源代码的JDBC数据源实现项目，它在lib目录中与Hibernate一起发布，实现了JDBC3和JDBC2扩展规范说明的Connection 和Statement 池。C3P0类包位于<SPRING_HOME>/lib/c3p0/c3p0-0.9.0.4.jar。下面是使用C3P0配置一个Oracle数据源：

3. Spring的数据源实现类(DriverManagerDataSource)

Spring本身也提供了一个简单的数据源实现类DriverManagerDataSource ，它位于org.springframework.jdbc.datasource包中。这个类实现了javax.sql.DataSource接口，但它并没有提供池化连接的机制，每次调用getConnection()获取新连接时，只是简单地创建一个新的连接。因此，这个数据源类比较适合在单元测试或简单的独立应用中使用，因为它不需要额外的依赖类。

<bean id=”dataSource” class=”org.springframework.jdbc.datasource.DriverManagerDataSource” destroy-method=”close”>
<property name=”driverClassName”

value=” oracle.jdbc.driver.OracleDriver ” />
<property name=”url” value=”jdbc:oracle:thin:@localhost:1521:orcl ” />
<property name=”username” value=”root” />
<property name=”password” value=”1234″ />
</bean>

4.获取JNDI数据源

如果应用配置在高性能的应用服务器（如WebLogic或Websphere等）上，我们可能更希望使用应用服务器本身提供的数据源。应用服务器的数据源使用JNDI开放调用者使用，Spring为此专门提供引用JNDI资源的JndiObjectFactoryBean类。下面是一个简单的配置：

<bean id=”dataSource”

class=”org.springframework.jndi.JndiObjectFactoryBean”>
<property name=”jndiName” value=”java:comp/env/jdbc/oracle”/>
</bean>

通过jndiName指定引用的JNDI数据源名称。

5.Session机制追踪客户状态

<1>. Java Servlet API 中引用 Session 机制来追踪客户的状态。Servlet API 中定义了 javax.servlet.http.HttpSession 接口，Servlet 容器必须实现这个接口。
<2>.当一个 Session 开始时，Servlet 容器将创建一个 HttpSession 对象，Servlet 容器为 HttpSession 分配一个唯一标识符，称为 Session ID。Servlet 容器将 Session ID 作为 Cookie 保存在客户的浏览器中。每次客户发出 HTTP 请求时，Servlet 容器可以从 HttpRequest 对象中读取 Session ID，然后根据 Session ID 找到相应的 HttpSession 对象，从而获取客户的状态信息。
<3>.当客户端浏览器中禁止 Cookie，Servlet 容器无法从客户端浏览器中取得作为 Cookie 的 Session ID，也就无法跟踪客户状态。
Java Servlet API 中提出了跟踪 Session 的另一种机制，如果客户端浏览器不支持 Cookie，Servlet 容器可以重写客户请求的 URL，把 Session ID 添加到 URL 信息中。
<4>. HttpServletResponse 接口提供了重写 URL 的方法：public java.lang.String encodeURL(java.lang.String url)
该方法的实现机制为：

● 先判断当前的 Web 组件是否启用 Session，如果没有启用 Session，直接返回参数 url。
● 再判断客户端浏览器是否支持 Cookie，如果支持 Cookie，直接返回参数 url；如果不支持 Cookie，就在参数 url 中加入 Session ID 信息，然后返回修改后的 url。

我们可以对网页中的链接稍作修改，解决以上问题：

修改前：

<a href=“maillogin.jsp“>
修改后：

6.AOP和OOP的区别

AOP和OOP都是一套方法论，也可以说成设计模式、思维方式、理论规则等等。

AOP不能替代OOP，OOP是obejct abstraction（对象抽象），而AOP是concern abstraction（关系抽象）

OOP主要是对对象的抽象，偏重业务处理，诸如抽象出某类业务对象的公用接口、报表业务对象的逻辑封装，更注重于某些共同对象共有行为的抽象，如报表模块中专门需要报表业务逻辑的封装，其他模块中需要其他的逻辑抽象。
AOP是对分散在各个模块中的共同行为的抽象，即关注点抽象。一些系统级的问题或者思考起来总与业务无关又多处存在的功能，可使用AOP，如异常信息处理机制统一将自定义的异常信息写入响应流进而到前台展示、行为日志记录用户操作过的方法等，这些东西用OOP来做，就是一个良好的接口、各处调用，但有时候会发现太多模块调用的逻辑大都一致、并且与核心业务无大关系，可以独立开来，让处理核心业务的人专注于核心业务的处理，关注分离了，自然代码更独立、更易调试分析、更具好维护。

核心业务还是要OOP来发挥作用，与AOP的侧重点不一样，前者有种纵向抽象的感觉，后者则是横向抽象的感觉， AOP只是OOP的补充，无替代关系。

Spring实现AOP有几种方式:

1. Spring 1.2版本中通过ProxyFactoryBean来实现aop,即通过动态代理来实现的,Aspect必须继承MethodBeforeAdvice,MethodAfterAdvice等
2. Spring 2.0 AOP需要改的是FBI 这个类，而且它也不需要再实现某些接口
3. 三使用标注（@AspectJ）实现AOP

7.Spring的作用域scope

scope的作用域默认是单例模式，即scope="singleton"。另外scope还有prototype、request、session、global session作用域。scope="prototype"多例。再配置bean的作用域时，它的头文件形式如下：

如何使用spring的作用域：

<bean id="role" class="spring.chapter2.maryGame.Role" scope="singleton"/>

这里的 scope 就是用来配置 spring bean 的作用域，它标识 bean 的作用域。

Scope描述的是Spring容器如何新建Bean实例的。Spring的Scope有以下几种，也可以通过@Scope注解来实现。

（1）Singleton：一个Spring容器中只有一个Bean的实例，此为Spring的默认配置，全容器共享一个实例。
（2）Prototype：每次调用新建一个Bean实例。
（3）Request：Web项目中，给每一个 http request 新建一个Bean实例。
（4）Session：Web项目中，给每一个 http session 新建一个Bean实例。
（5）GlobalSession：这个只在portal应用中有用，给每一个 global http session 新建一个Bean实例。

8.Spring的七大模块

1. Spring Core： Core封装包是框架的最基础部分，提供IOC和依赖注入特性。这里的基础概念是BeanFactory，它提供对Factory模式的经典实现来消除对程序性单例模式的需要，并真正地允许你从程序逻辑中分离出依赖关系和配置。
2.Spring Context: 构建于Core封装包基础上的 Context封装包，提供了一种框架式的对象访问方法，有些象JNDI注册器。Context封装包的特性得自于Beans封装包，并添加了对国际化（I18N）的支持（例如资源绑定），事件传播，资源装载的方式和Context的透明创建，比如说通过Servlet容器。
3．Spring DAO: DAO (Data Access Object)提供了JDBC的抽象层，它可消除冗长的JDBC编码和解析数据库厂商特有的错误代码。并且，JDBC封装包还提供了一种比编程性更好的声明性事务管理方法，不仅仅是实现了特定接口，而且对所有的POJOs（plain old Java objects）都适用。（提供了自己的实现）
4.Spring ORM: ORM 封装包提供了常用的“对象/关系”映射APIs的集成层。其中包括JPA、JDO、Hibernate 和 iBatis 。利用ORM封装包，可以混合使用所有Spring提供的特性进行“对象/关系”映射，如前边提到的简单声明性事务管理。
5.Spring AOP: Spring的 AOP 封装包提供了符合AOP Alliance规范的面向方面的编程实现，让你可以定义，例如方法拦截器（method-interceptors）和切点（pointcuts），从逻辑上讲，从而减弱代码的功能耦合，清晰的被分离开。而且，利用source-level的元数据功能，还可以将各种行为信息合并到你的代码中。
6.Spring Web: Spring中的 Web 包提供了基础的针对Web开发的集成特性，例如多方文件上传，利用Servlet listeners进行IOC容器初始化和针对Web的ApplicationContext。当与WebWork或Struts一起使用Spring时，这个包使Spring可与其他框架结合。
7.Spring Web MVC: Spring中的MVC封装包提供了Web应用的Model-View-Controller（MVC）实现。Spring的MVC框架并不是仅仅提供一种传统的实现，它提供了一种清晰的分离模型，在领域模型代码和Web Form之间。并且，还可以借助Spring框架的其他特性。

9.Spring MVC和struts2的比较

1>. 机制：spring mvc的入口是servlet，而struts2是filter。

补充几点知识：

Filter 实现javax.servlet.Filter接口，在web.xml中配置与标签指定使用哪个Filter实现类过滤哪些URL链接。只在web启动时进行初始化操作。 filter 流程是线性的， url传来之后，检查之后，可保持原来的流程继续向下执行，被下一个filter, servlet接收等，而servlet 处理之后，不会继续向下传递。filter功能可用来保持流程继续按照原来的方式进行下去，或者主导流程，而servlet的功能主要用来主导流程。特点：可以在响应之前修改Request和Response的头部，只能转发请求，不能直接发出响应。filter可用来进行字符编码的过滤，检测用户是否登陆的过滤，禁止页面缓存等

Servlet， servlet 流程是短的，url传来之后，就对其进行处理，之后返回或转向到某一自己指定的页面。它主要用来在业务处理之前进行控制。
Listener，我们知道 servlet、filter都是针对url之类的，而listener是针对对象的操作的，如session的创建，session.setAttribute的发生，在这样的事件发生时做一些事情

2>. 性能：

spring会稍微比struts快。 spring mvc是基于方法的设计，而sturts是基于类，每次发一次请求都会实例一个action，每个action都会被注入属性，而spring基于方法，粒度更细(粒度级别的东西比较sychronized和lock)，但要小心把握像在servlet控制数据一样。 spring3 mvc是方法级别的拦截，拦截到方法后根据参数上的注解，把request数据注入进去，在spring3 mvc中，一个方法对应一个request上下文。而struts2框架是类级别的拦截，每次来了请求就创建一个Action，然后调用setter、getter方法把request中的数据注入；struts2实际上是通过setter、getter方法与request打交道的；struts2中，一个Action对象对应一个request上下文。

3>. 参数传递：

struts是在接受参数的时候，可以用属性来接受参数，这就说明参数是让多个方法共享的。

4>. 设计思想上：

struts更加符合oop的编程思想， spring就比较谨慎，在servlet上扩展。

5>. intercepter(拦截器)的实现机制：

struts有以自己的interceptor机制， spring mvc用的是独立的AOP方式。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继承，所以我觉得，就拿使用上来讲，spring mvc使用更加简洁，开发效率Spring MVC确实比struts2高。

spring mvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应，所以说从架构本身上 spring3 mvc就容易实现restful url 。
struts2是类级别的拦截，一个类对应一个request上下文；实现restful url要费劲，因为struts2 action的一个方法可以对应一个url；而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。

spring3 mvc的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架方法之间不共享变量，而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码，读程序时带来麻烦。

6. 另外：spring3 mvc的验证也是一个亮点，支持JSR303，处理ajax的请求更是方便，只需一个注解 @ResponseBody ，然后直接返回响应文本即可。代码：

@RequestMapping (value= "/whitelists" )
public String index(ModelMap map) {
Account account = accountManager.getByDigitId(SecurityContextHolder.get().getDigitId());
List<Group> groupList = groupManager.findAllGroup(account.getId());
map.put("account" , account);
map.put("groupList" , groupList);
return "/group/group-index" ;
}
// @ResponseBody ajax响应，处理Ajax请求也很方便
@RequestMapping (value= "/whitelist/{whiteListId}/del" )
@ResponseBody
public String delete( @PathVariable Integer whiteListId) {
whiteListManager.deleteWhiteList(whiteListId);
return "success" ;
}