2011年金山面试

笔试题部分：

10道选择题，非常基础的题，在java编程思想里面都有提到的

3道问答题

1.servlet生命周期，servlet与CGI的区别

Servlet的生命周期包含了下面4个阶段：（1）加载和实例化Servlet容器负责加载和实例化Servlet。当Servlet容器启动时，或者在容器检测到需要这个Servlet来响应第一个请求时，创建Servlet实例。当Servlet容器启动后，它必须要知道所需的Servlet类在什么位置，Servlet容器可以从本地文件系统、远程文件系统或者其他的网络服务中通过类加载器加载Servlet类，成功加载后，容器创建Servlet的实例。因为容器是通过Java的反射API来创建Servlet实例，调用的是Servlet的默认构造方法（即不带参数的构造方法），所以我们在编写Servlet类的时候，不应该提供带参数的构造方法。（2）初始化在Servlet实例化之后，容器将调用Servlet的init()方法初始化这个对象。初始化的目的是为了让Servlet对象在处理客户端请求前完成一些初始化的工作，如建立数据库的连接，获取配置信息等。对于每一个Servlet实例，init()方法只被调用一次。在初始化期间，Servlet实例可以使用容器为它准备的ServletConfig对象从Web应用程序的配置信息（在web.xml中配置）中获取初始化的参数信息。在初始化期间，如果发生错误，Servlet实例可以抛出ServletException异常或者UnavailableException异常来通知容器。ServletException异常用于指明一般的初始化失败，例如没有找到初始化参数；而UnavailableException异常用于通知容器该Servlet实例不可用。例如，数据库服务器没有启动，数据库连接无法建立，Servlet就可以抛出UnavailableException异常向容器指出它暂时或永久不可用。（3）请求处理Servlet容器调用Servlet的service()方法对请求进行处理。要注意的是，在service()方法调用之前，init()方法必须成功执行。在service()方法中，Servlet实例通过ServletRequest对象得到客户端的相关信息和请求信息，在对请求进行处理后，调用ServletResponse对象的方法设置响应信息。在service()方法执行期间，如果发生错误，Servlet实例可以抛出ServletException异常或者UnavailableException异常。如果UnavailableException异常指示了该实例永久不可用，Servlet容器将调用实例的destroy()方法，释放该实例。此后对该实例的任何请求，都将收到容器发送的HTTP 404（请求的资源不可用）响应。如果UnavailableException异常指示了该实例暂时不可用，那么在暂时不可用的时间段内，对该实例的任何请求，都将收到容器发送的HTTP 503（服务器暂时忙，不能处理请求）响应。（4）服务终止当容器检测到一个Servlet实例应该从服务中被移除的时候，容器就会调用实例的destroy()方法，以便让该实例可以释放它所使用的资源，保存数据到持久存储设备中。当需要释放内存或者容器关闭时，容器就会调用Servlet实例的destroy()方法。在destroy()方法调用之后，容器会释放这个Servlet实例，该实例随后会被Java的垃圾收集器所回收。如果再次需要这个Servlet处理请求，Servlet容器会创建一个新的Servlet实例。

概括来讲，Servlet可以完成和CGI相同的功能。　　CGI应用开发比较困难，因为它要求程序员有处理参数传递的知识，这不是一种通用的技能。CGI不可移植，为某一特定平台编写的CGI应用只能运行于这一环境中。每一个CGI应用存在于一个由客户端请求激活的进程中，并且在请求被服务后被卸载。这种模式将引起很高的内存、CPU开销，而且在同一进程中不能服务多个客户。　　Servlet提供了Java应用程序的所有优势——可移植、稳健、易开发。使用Servlet Tag技术，Servlet能够生成嵌于静态HTML页面中的动态内容。　　Servlet对CGI的最主要优势在于一个Servlet被客户端发送的第一个请求激活，然后它将继续运行于后台，等待以后的请求。每个请求将生成一个新的线程，而不是一个完整的进程。多个客户能够在同一个进程中同时得到服务。一般来说，Servlet进程只是在Web Server卸载时被卸载。

2.java提交表单乱码问题

1）入门方法，在所有的servlet和jsp中“堆”写设定用的代码。所谓入门方法，那就是现实十分简单，当然效果也是很好的。只是必须在每个相应的文件中写相同的设定代码，代码的重复性就比较大。由前面所述，由于“POST”和“GET”方式的不同，因此对应着两种的设定方式也不同。“POST”的情况下，如果服务器端脚本是一个servlet，那只要在doPost()方法里面插入一句request.setCharacterEncode("GB2312");需要注意的是，这句设定必须在所有从request对象做提取操作之前执行，如果类似于request.getParameter()的操作在前，那么系统将使用默认的“8859_1”编码方式，而忽略后面的设定代码。如果服务器端是一个jsp脚本，那只要在该脚本的jsp申明部分做好设定即可：<%@ page language="java" contentType="text/html; charset=gb2312" pageEncoding="gb2312"%>如果是“GET”方式，也就是想通过URL来传递中文的话，稍微要麻烦些，首先因为浏览器地址栏是不支持中文的，也就是如果直接将中文放置在超级连接里面是无效的。因此需要在发送端对中文内容进行编码，比如：URLEncoder.encoder("http://localhost/submit?name=张三","UTF-8");“UTF-8”表示用这种编码方式对原字符串进行编码，编码好之后看到的结果是http://localhost/submit?name=%D5%C5%C8%FD所以我们经常看到在浏览器里面有众多的类似与“%D5%C5%C8%FD”这样的字符串，就是表明被UTF-8编码过了。由于UTF-8是跨各种平台的通用编码方式，因此比较常用于各种语言文字的传输载体。相对应的，在接受方需要进行反向的解码即可，代码如下：new String( request.getParameter("name").getBytes("8859_1"), "gb2312" );这里可能会有一些疑问，为什么用“8859_1”来解码。事实上，我在第一次尝试的时候也曾使用“UTF-8”来尝试解码，结果出现乱码失败。究其原因，尽管“张三”被编码成了“%D5%C5%C8%FD”来传输，但是在传输过程中，“%D5%C5%C8%FD”仍旧需要由“8859_1”来编码打包成HTTP，因此，在接收端，自然先需要由“8859_1”来还原到“%D5%C5%C8%FD”的“UTF-8”格式，然后再由“UTF-8”还原到“GB2312”。所以这样也不难理解为什么所谓“浏览器地址栏是不支持中文”，不能直接用中文而要用“UTF-8”来通过“8859_1”来打包了，原因就是“%D5%C5%C8%FD”这串类似于密码般的字符串本身就是西文字符，用“8859_1”编解码没有任何问题。而中文由于是2byte一个汉字，直接用西文方式来编解码自然就会出现问题。这也就是为什么称“UTF-8”为“跨各种平台的通用编码方式”了。背景小资料：由于“UTF-8”是通用编码方式，因此所有的语言格式均可以转换为“UTF-8”，在日益国际的今天，多语言的系统要求越来越多，因此强烈建议使用“UTF-8”来做为系统统一的编解码方式，从而彻底解决中文乱码的问题。“UTF-8”为了能做到兼容所有语言的编解码，因此每一个字符均用2个byte来编码。这样就造成了存西文字符时需要多一倍的空间。这也算是为了通用而付出的代价了。2）中级方法，对web伺服器进行配置可想而知，相对于“堆”写大量代码，配置一下web伺服器config文件来解决中文乱码问题就显得优雅许多。但是由于各种web伺服器的情况不同，其配置方法也不尽相同。因此，其兼容性是个比较大的问题。这里列举一下，如何通过修改Tomcat的conf配置文件来解决中文乱码的问题。找到Tomcat的配置文件server.xml中的Connector这一行，为其添加一个如下的属性URIEncoding = "GB2312"这样就指定了使用“GB2312”来进行编解码。不过需要注意的是，tomcat4.x以以前的版本由于蒋“POST”和“GET”等同视之，因此这样一句设定就可以适用于两种方法。而到了tomcat5.x以后，两种方式就分开处理了。因此在tomcat5.x的情况下，只做这个设定，那仅仅对“POST”方式有效，“GET”方式仍然会得到乱码。不过好在tomcat5.x考虑到了这个问题，提供了一个附加的参数：useBodyEncodingForURI = "true"如果做了这样的设定，那5.x就将兼容4.x而“POST”和“GET”等同视之。3）高级方法，编写filter过滤器，对“POST”和“GET”独立过滤处理。 

3.aop是什么，aop的作用

　AOP是OOP的延续，是Aspect Oriented Programming的缩写，意思是面向方面编程。AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可以说也是这种目标的一种实现。

  　举例：假设有在一个应用系统中，有一个共享的数据必须被并发同时访问，首先，将这个数据封装在数据对象中，称为Data Class，同时，将有多个访问类，专门用于在同一时刻访问这同一个数据对象。

　　为了完成上述并发访问同一资源的功能，需要引入锁Lock的概念，也就是说，某个时刻，当有一个访问类访问这个数据对象时，这个数据对象必须上锁Locked，用完后就立即解锁unLocked，再供其它访问类访问。

　　使用传统的编程习惯，我们会创建一个抽象类，所有的访问类继承这个抽象父类，如下：

abstract class Worker{

　　abstract void locked();
　　abstract void accessDataObject();
　　abstract void unlocked();

}

 

　缺点：

• accessDataObject()方法需要有“锁”状态之类的相关代码。
• Java只提供了单继承，因此具体访问类只能继承这个父类，如果具体访问类还要继承其它父类，比如另外一个如Worker的父类，将无法方便实现。
• 重用被打折扣，具体访问类因为也包含“锁”状态之类的相关代码，只能被重用在相关有“锁”的场合，重用范围很窄。
  
  仔细研究这个应用的“锁”，它其实有下列特性：
• “锁”功能不是具体访问类的首要或主要功能，访问类主要功能是访问数据对象，例如读取数据或更改动作。

“锁”行为其实是和具体访问类的主要功能可以独立、区分开来的

“锁”功能其实是这个系统的一个纵向切面，涉及许多类、许多类的方法。如下图： 

　因此，一个新的程序结构应该是关注系统的纵向切面，例如这个应用的“锁”功能，这个新的程序结构就是aspect（方面）

　　在这个应用中，“锁”方面（aspect）应该有以下职责：

　　提供一些必备的功能，对被访问对象实现加锁或解锁功能。以保证所有在修改数据对象的操作之前能够调用lock()加锁，在它使用完成后，调用unlock()解锁。

AOP应用范围

　　很明显，AOP非常适合开发J2EE容器服务器，目前JBoss 4.0正是使用AOP框架进行开发。
　　具体功能如下：
Authentication 权限
Caching 缓存
Context passing 内容传递
Error handling 错误处理
Lazy loading　懒加载
Debugging　　调试
logging, tracing, profiling and monitoring　记录跟踪　优化　校准

 

Performance optimization　性能优化
Persistence　　持久化
Resource pooling　资源池
Synchronization　同步
Transactions 事务

AOP有必要吗？

　　当然，上述应用范例在没有使用AOP情况下，也得到了解决，例如JBoss 3.XXX也提供了上述应用功能，但是没有使用AOP。

　　但是，使用AOP可以让我们从一个更高的抽象概念来理解软件系统，AOP也许提供一种有价值的工具。可以这么说：因为使用AOP结构，现在JBoss 4.0的源码要比JBoss 3.X容易理解多了，这对于一个大型复杂系统来说是非常重要的。

　　从另外一个方面说，好像不是所有的人都需要关心AOP，它可能是一种架构设计的选择，如果选择J2EE系统，AOP关注的上述通用方面都已经被J2EE容器实现了，J2EE应用系统开发者可能需要更多地关注行业应用方面aspect。

两个编程题

1.打印下面

*****

****

***

**

*

2.是写sql语句，两表联查，orderby groupby等都有考到，大概就是需要查出每个组别中排名前三的元素