java面试题二

forward 和redirect的区别
答：forward是服务器请求资源，服务器直接访问目标地址的URL，把那个URL的响应内容读取过来，然后把这些内容再发给浏览器，浏览器根本不知道服务器发送的内容是从哪儿来的，所以它的地址栏中还是原来的地址。
redirect就是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址，一般来说浏览器会用刚才请求的所有参数重新请求，所以session,request参数都可以获取。

jsp有哪些内置对象?作用分别是什么?
答：JSP共有以下9种基本内置组件（可与ASP的6种内部组件相对应）：
　request 用户端请求，此请求会包含来自GET/POST请求的参数
response 网页传回用户端的回应
pageContext 网页的属性是在这里管理
session 与请求有关的会话期
application servlet 正在执行的内容
out 用来传送回应的输出
config servlet的构架部件
page JSP网页本身
exception 针对错误网页，未捕捉的例外

jsp有哪些动作?作用分别是什么?
答:JSP共有以下6种基本动作
jsp:include：在页面被请求的时候引入一个文件。
jsp:useBean：寻找或者实例化一个JavaBean。
jsp:setProperty：设置JavaBean的属性。
jsp:getProperty：输出某个JavaBean的属性。
jsp:forward：把请求转到一个新的页面。
jsp:plugin：根据浏览器类型为Java插件生成OBJECT或EMBED标记

JSP中动态INCLUDE与静态INCLUDE的区别？
答：动态INCLUDE用jsp:include动作实现
<jsp:include page="included.jsp" flush="true" />它总是会检查所含文件中的变化，适合用于包含动态页面，并且可以带参数
静态INCLUDE用include伪码实现,定不会检查所含文件的变化，适用于包含静态页面
<%@ include file="included.htm" %>

两种跳转方式分别是什么?有什么区别?
答：有两种，分别为：
<jsp:include page="included.jsp" flush="true">
<jsp:forward page= "nextpage.jsp"/>
前者页面不会转向include所指的页面，只是显示该页的结果，主页面还是原来的页面。执行完后还会回来，相当于函数调用。并且可以带参数.后者完全转向新页面，不会再回来。相当于go to 语句。

JSP的内置对象及方法。
答：request表示HttpServletRequest对象。它包含了有关浏览器请求的信息，并且提供了几个用于获取cookie, header, 和session数据的有用的方法。
response表示HttpServletResponse对象，并提供了几个用于设置送回 浏览器的响应的方法（如cookies,头信息等）
out对象是javax.jsp.JspWriter的一个实例，并提供了几个方法使你能用于向浏览器回送输出结果。
pageContext表示一个javax.servlet.jsp.PageContext对象。它是用于方便存取各种范围的名字空间、servlet相关的对象的API，并且包装了通用的servlet相关功能的方法。
session表示一个请求的javax.servlet.http.HttpSession对象。Session可以存贮用户的状态信息
applicaton 表示一个javax.servle.ServletContext对象。这有助于查找有关servlet引擎和servlet环境的信息
config表示一个javax.servlet.ServletConfig对象。该对象用于存取servlet实例的初始化参数。
page表示从该页面产生的一个servlet实例

 

struts1与struts2的区别

Struts2与Struts1的对比
Action类:
• Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。
• Struts 2 Action类可以实现一个Action接口，也可实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去 实现 常用的接口。Action接口不是必须的，任何有execute标识的POJO对象都可以用作Struts2的Action对象。

线程模式:
• Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能作的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的。
• Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。（实际上，servlet容器给每个请求产生许多可丢弃的对象，并且不会导致性能和垃圾回收问题）

Servlet 依赖:
• Struts1 Action 依赖于Servlet API ,因为当一个Action被调用时HttpServletRequest 和 HttpServletResponse 被传递给execute方法。
• Struts 2 Action不依赖于容器，允许Action脱离容器单独被测试。如果需要，Struts2 Action仍然可以访问初始的request和response。但是，其他的元素减少或者消除了直接访问HttpServetRequest 和 HttpServletResponse的必要性。

可测性:
• 测试Struts1 Action的一个主要问题是execute方法暴露了servlet API（这使得测试要依赖于容器）。一个第三方扩展－－Struts TestCase－－提供了一套Struts1的模拟对象（来进行测试）。
• Struts 2 Action可以通过初始化、设置属性、调用方法来测试，“依赖注入”支持也使测试更容易。

捕获输入:
• Struts1 使用ActionForm对象捕获输入。所有的ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm，开发者经 常创建多余的类捕获输入。动态Bean（DynaBeans）可以作为创建传统ActionForm的选择，但是，开发者可能是在重新描述(创建)已经存 在的JavaBean（仍然会导致有冗余的javabean）。
• Struts 2直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。输入属性可能是有自己(子)属性的rich对象类型。Action属性能够通过 web页面上的taglibs访问。Struts2也支持ActionForm模式。rich对象类型，包括业务对象，能够用作输入/输出对象。这种 ModelDriven 特性简化了taglib对POJO输入对象的引用。

表达式语言：
• Struts1 整合了JSTL，因此使用JSTL EL。这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱。
• Struts2可以使用JSTL，但是也支持一个更强大和灵活的表达式语言－－"Object Graph Notation Language" (OGNL).

绑定值到页面（view）:
• Struts 1使用标准JSP机制把对象绑定到页面中来访问。
• Struts 2 使用 "ValueStack"技术，使taglib能够访问值而不需要把你的页面（view）和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面（view）。
　
类型转换：
• Struts 1 ActionForm 属性通常都是String类型。Struts1使用Commons-Beanutils进行类型转换。每个类一个转换器，对每一个实例来说是不可配置的。
• Struts2 使用OGNL进行类型转换。提供基本和常用对象的转换器。

校验：
• Struts 1支持在ActionForm的validate方法中手动校验，或者通过Commons Validator的扩展来校验。同一个类可以有不同的校验内容，但不能校验子对象。
• Struts2支持通过validate方法和XWork校验框架来进行校验。XWork校验框架使用为属性类类型定义的校验和内容校验，来支持chain校验子属性

Action执行的控制：
• Struts1支持每一个模块有单独的Request Processors（生命周期），但是模块中的所有Action必须共享相同的生命周期。
• Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。堆栈能够根据需要和不同的Action一起使用。

使用Spring管理的对象是单例的，Service需要做哪些处理？

1：尽量少或者不定义成员变量

2：定义成员变量应该定义成私有的，或者不变的final型

public class GroupimgService implements IGroupimgService{ private IGroupimgDao groupimgDao; public IGroupimgDao getGroupimgDao() { return groupimgDao; } public void setGroupimgDao(IGroupimgDao groupimgDao) { this.groupimgDao = groupimgDao; } /** * save or update */ public Groupimg addGroupimg(Groupimg groupimg) throws Exception{ Groupimg g=(Groupimg)groupimgDao.save(groupimg); return g; } }

上面代码定义了变量groupimgDao，私有且同样在spring中是单例，

关于addGroupimg方法是否需要做同步？

对同一个对象，如果同时有两个线程调用这个对象的同一个方法，那么jvm会自动开

两个栈用以存储这个方法内部的变量，所以没有同步问题。

 

Spring配置Webwork Action Bean时，需要加上属性scope=”prototype”或singleton=”false”。
singleton模式指的是对某个对象的完全共享，包括代码空间和数据空间，说白了，如果一个类是singleton的，

假如这个类有成员变量，那么这个成员变量的值是各个线程共享的（有点类似于static的样子了），当线程A往

给变量赋了一个值以后，线程B就能读出这个值。

 

spring中的控制反转

何谓控制反转（IoC =  Inversion of Control） ，何谓依赖注入（DI = Dependency  Injection）？
  IoC，用白话来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也

就是所谓“控制反转”的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。
相对IoC而言， “依赖注入”的确更加准确的描述了这种古老而又时兴的设计理念。从名字上理解，
所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关
系注入到组件之中。
  依赖注入的目标并非为软件系统带来更多的功能，而是为了提升组件重用的概率，并为系统搭建
一个灵活、可扩展的平台。依赖注入机制减轻了组件之间的依赖关系，同时也大大提高了组件的可移植性，这意味着，

组件得到重用的机会将会更多。

 

举例说明

<beans> <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName"> <value>java:comp/env/jdbc/sample</value> </property> </bean> <bean id="SampleDAO" class="net.xiaxin.spring.dao.SampleDAO"> <property name="dataSource"> <ref local="dataSource"/> </property> </bean> </beans>

其中SampleDAO中的dataSource将由容器在运行期动态注入， 而DataSource的具体配置和初始化工作
也将由容器在运行期完成。
 
对比传统的实现方式（如通过编码初始化DataSource实例） ，我们可以看到，基于依赖注入的系统实现相
当灵活简洁。
通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定SampleDAO中所需的
DataSource实例。SampleDAO只需利用容器注入的DataSource实例，完成自身的业务逻辑，而不用
关心具体的资源来自何处、由谁实现。
 
上面的实例中，我们假设SampleDAO是一个运行在J2EE容器中的组件（如 Weblogic） 。在运行期，通
过JNDI从容器中获取DataSource实例。

现在假设我们的部署环境发生了变化，系统需要脱离应用服务器独立运行，这样，由于失去了容器的支持，
原本通过JNDI获取DataSource的方式不再有效。我们需要如何修改以适应新的系统环境？很简单，我们
只需要修改dataSource的配置：

<beans> <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName"> <value>org.gjt.mm.mysql.Driver</value> </property> <property name="url"> <value>jdbc:mysql://localhost/sample</value></property> <property name="username"> <value>user</value> </property> <property name="password"> <value>mypass</value> </property> </bean> <bean id="SampleDAO" class="net.xiaxin.spring.dao.SampleDAO"> <property name="dataSource"> <ref local="dataSource"/> </property> </bean> </beans>

这里我们的DataSource改为由Apache DBCP组件提供。没有编写任何代码我们即实现了DataSource的
切换。回想传统编码模式中，如果要进行同样的修改，我们需要付出多大的努力。
 
依赖注入机制减轻了组件之间的依赖关系，同时也大大提高了组件的可移植性，这意味着，组件得到重用
的机会将会更多。

 

AOP

Aspect Oriented Programming（AOP）

而在AOP中，Aspect的含义，可能更多的理解为“切面”比较合适。所以笔者更倾向
于“面向切面编程”的译法。
 
另外需要提及的是，AOP、OOP在字面上虽然非常类似，但却是面向不同领域的两种
设计思想。OOP（面向对象编程）针对业务处理过程的实体及其属性和行为进行抽象封装，
以获得更加清晰高效的逻辑单元划分。
而AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步
骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。这两种设计思想在目标上有
着本质的差异。
 
上面的陈述可能过于理论化，举个简单的例子，对于“雇员”这样一个业务实体进行封
装，自然是OOP/OOD的任务，我们可以为其建立一个“Employee”类，并将“雇员”相
关的属性和行为封装其中。而用AOP设计思想对“雇员”进行封装将无从谈起。
同样，对于 “权限检查” 这一动作片断进行划分， 则是AOP的目标领域。 而通过OOD/OOP
对一个动作进行封装，则有点不伦不类。
 
换而言之，OOD/OOP面向名词领域，AOP面向动词领域。
 
AOP和OOD/OOP并不冲突，我们完全可以在一个应用系统中同时应用OOD/OOP和
AOP设计思想，通过OOD/OOP对系统中的业务对象进行建模，同时通过AOP对实体处理
过程中的阶段进行隔离处理。 即使不是OOD/OOP，而是在传统的POP（面向过程编程）中，
AOP也能起到同样的作用。
 
将不同阶段领域加以分隔，这是否就算是AOP呢？
 
AOP还有另外一个重要特点：源码组成无关性

倘若应用中通过某个具体的业务逻辑类实现了独立的权限检查， 而请求调度方法通过预
编码调用这个权限模块实现权限管理。那么这也不算是AOP。对于AOP组件而言，很重要
的一点就是源码组成无关性，所谓源码组成无关性，体现在具体设计中就是AOP组件必须
与应用代码无关，简单来讲，就是应用代码可以脱离AOP组件独立编译。
 
为了实现源码组成无关性，AOP往往通过预编译方式（如AspectJ）和运行期动态代理
模式（如Spring AOP 和JBoss AOP）实现