Tomcat性能调整
作者：佚名 转贴自：CSDN 点击数：15554
|
一. 引言
性能测试与分析是软件开发过程中介于架构和调整的一个广泛并比较不容易理解的领域，更是一项较为复杂的活动。就像下棋游戏一样，有效的性能测试和分析只能在一个良好的计划策略和具备了对不可预料事件的处理能力的条件下顺利地完成。一个下棋高手赢得比赛靠的不仅仅是对游戏规则的认识，更是靠他的自己的能力和不断地专注于分析自己对手的实力来更加有效地利用和发挥规则的作用。同样一个优秀的性能测试和分析人员将要面对的是来自一个全新的应用程序和环境下带来的整个项目的挑战。本文中作者结合自己的使用经验和参考文档，对Tomcat性能方面的调整做一简要的介绍，并给出Tomcat性能的测试、分析和调整优化的一些方法。
二. 测量Web服务器的性能
测量web服务器的性能是一项让人感到畏缩的任务，但是我们在这里将给出一些需要注意的地方并且指点你了解其中更多的细节性的内容。它不像一些简单的任务，如测量CPU的速率或者是测量程序占用CPU的比例，web服务器的性能优化中包括许调整许多变量来达到目标。许多的测量策略中都包含了一个看似简单的浏览实际上是在向服务器发送大量的请求，我们称之为客户端的程序，来测量响应时间。客户端和服务器端是在同一台机器上吗？服务器在测试的时候还运行着其它的什么程序吗？客户端和服务器端的通讯是通过局域网，100baseT，10baseT还是使用调制解调器？客户端是否一直重复请求相同的页面，还是随机地访问不同的页面？（这些影响到了服务缓存的性能）客户端发送请求的有规律的还是突发的？你是在最终的配置环境下运行服务的还是在调试的配置环境下运行服务的？客户端请求中包含图片还是只有HTML页面？是否有请求是通过servlets和JSP的，CGI程序，服务端包含（Server-Side Includes ，SSI是一个可以让你使用动态HTML文件的技术）？所有这些都将是我们要关心的，并且几乎我们不可能精确地把所有的问题都清楚地列出来。
1.压力测试工具
“工欲善其事，必先利其器”，压力测试只有借助于一些工具才可得以实施。
大多数web压力测试工具的实现原理都是通过重复的大量的页面请求来模拟多用户对被测系统的并发访问，以此达到产生压力的目的。产生压力的手段都是通过录制或者是编写压力脚本，这些脚本以多个进程或者线程的形式在客户端运行，这样通过人为制造各种类型的压力，我们可以观察被测系统在各种压力状况下的表现，从而定位系统瓶颈，作为系统调优的基础。目前已经存在的性能测试工具林林总总，数量不下一百种，从单一的开放源码的免费小工具如 Aapache 自带的 web 性能测试工具 Apache Benchmark、开源的Jmeter 到大而全的商业性能测试软件如 Mercury 的 LoadRunner 等等。任何性能测试工具都有其优缺点，我们可以根据实际情况挑选用最合适的工具。您可以在这里找到一些web压力测试工具http://www.softwareqatest.com/qatweb1.html#LOAD
这里我们所使用的工具要支持web应用服务认证才可以，要支持接收发送cookies，不仅如此Tomcat支持多种认证方式，比如基本认证、基于表单的认证、相互认证和客户端认证，而一些工具仅仅支持HTTP基本认证。真实地模拟用户认证是性能测试工具的一个重要的部分，因为认证机制将对一个web站点的性能特征产生重要的影响。基于你在产品中使用的不同的认证方式，你需要从上面的工具列表中选择使用这种特性的测试工具。
Apache Benchmark和http_load是命令行形式的工具，非常易于使用。Apache Benchmark可以模仿单独的URL请求并且重复地执行，可以使用不同的命令行参数来控制执行迭代的次数，并发用户数等等。它的一个特点是可以周期性地打印出处理过程的信息，而其它工具只能给出一个全局的报告。
2.压力测试工具介绍
三. 外部环境的调整
在Tomcat和应用程序进行了压力测试后，如果您对应用程序的性能结果不太满意，就可以采取一些性能调整措施了，当然了前提是应用程序没有问题，我们这里只讲Tomcat的调整。由于Tomcat的运行依赖于JVM，所以在这里我们把Tomcat的调整可以分为两类来详细描述：
外部环境调整
调整非Tomcat组件，例如Tomcat运行的操作系统和运行Tomcat的java虚拟机。
自身调整
修改Tomcat自身的参数，调整Tomcat配置文件中的参数。
下面我们将详细讲解外部环境调整的有关内容，Tomcat自身调整的内容将在第2部分中阐述。
1.JAVA虚拟机性能优化
Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个java虚拟机。您可以选择自己的需要选择不同的操作系统和对应的JDK的版本（只要是符合Sun发布的Java规范的），但我们推荐您使用Sun公司发布的JDK。确保您所使用的版本是最新的，因为Sun公司和其它一些公司一直在为提高性能而对java虚拟机做一些升级改进。一些报告显示JDK1.4在性能上比JDK1.3提高了将近10%到20%。
可以给Java虚拟机设置使用的内存，但是如果你的选择不对的话，虚拟机不会补偿。可通过命令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。
|
参数 |
描述 |
|
-Xms<size> |
JVM初始化堆的大小 |
|
-Xmx<size> |
JVM堆的最大值 |
这两个值的大小一般根据需要进行设置。初始化堆的大小执行了虚拟机在启动时向系统申请的内存的大小。一般而言，这个参数不重要。但是有的应用程序在大负载的情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果虚拟机启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，虚拟机就必须重复地增加内存来满足使用。由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最大值设置为可用内存的最大值的80%。
Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。
Windows下，在文件{tomcat_home}/bin/catalina.bat，Unix下，在文件{tomcat_home}/bin/catalina.sh的前面，增加如下设置：
JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】'
需要把这个两个参数值调大。例如：
JAVA_OPTS='-Xms256m -Xmx512m'
表示初始化内存为256MB，可以使用的最大内存为512MB。
另外需要考虑的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。如果堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。如果你把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为保证最好的性能，要把堆的大小设大，保证垃圾收集不在整个基准测试的过程中出现。
如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。如果垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的详细输出，研究 垃圾收集参数对性能的影响。一般说来，你应该使用物理内存的 80% 作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。
[NextPage]
2.操作系统性能优化
这里说的操作系统是指运行web服务器的系统软件，当然，不同的操作系统是为不同的目的而设计的。比如OpenBSD是面向安全的，因此在它的内核中有许多的限制来防止不同形式的服务攻击（OpenBSD的一句座右铭是“默认是最安全的”）。这些限制或许更多地用来运行活跃的web服务器。
而我们常用的Linux操作系统的目标是易用使用，因此它有着更高的限制。使用BSD内核的系统都带有一个名为“Generic”的内核，表明所有的驱动器都静态地与之相连。这样就使系统易于使用，但是如果你要创建一个自定义的内核来加强其中某些限制，那就需要排除不需要的设备。Linux内核中的许多驱动都是动态地加载的。但是换而言之，内存现在变得越来越便宜，所以因为加载额外的设备驱动就显得不是很重要的。重要的是要有更多的内存，并且在服务器上腾出更多的可用内存。
小提示：虽然现在内存已经相当的便宜，但还是尽量不要购买便宜的内存。那些有牌子的内存虽然是贵一点，但是从可靠性上来说，性价比会更高一些。
如果是在Windows操作系统上使用Tomcat，那么最好选择服务器版本。因为在非服务器版本上，最终用户授权数或者操作系统本身所能承受的用户数、可用的网络连接数或其它方面的一些方面都是有限制的。并且基于安全性的考虑，必须经常给操作系统打上最新的补丁。
3.Tomcat与其它web服务器整合使用
虽然tomcat也可以作web服务器,但其处理静态html的速度比不上apache,且其作为web服务器的功能远不如apache,因此我们想把apache和tomcat集成起来，将html与jsp的功能部分进行明确分工，让tomcat只处理jsp部分，其它的由apache,IIS等这些web服务器处理，由此大大节省了tomcat有限的工作“线程”。
4.负载均衡
在负载均衡的思路下，多台服务器为对称方式，每台服务器都具有同等的地位，可以单独对外提供服务而无须其他服务器的辅助。通过负载分担技术，将外部发送来的请求按一定规则分配到对称结构中的某一台服务器上，而接收到请求的服务器都独立回应客户机的请求。
提供服务的一组服务器组成了一个应用服务器集群(cluster)，并对外提供一个统一的地址。当一个服务请求被发至该集群时，根据一定规则选择一台服务器，并将服务转定向给该服务器承担，即将负载进行均衡分摊。
通过应用负载均衡技术，使应用服务超过了一台服务器只能为有限用户提供服务的限制，可以利用多台服务器同时为大量用户提供服务。当某台服务器出现故障时，负载均衡服务器会自动进行检测并停止将服务请求分发至该服务器，而由其他工作正常的服务器继续提供服务，从而保证了服务的可靠性。
负载均衡实现的方式大概有四种：第一是通过DNS，但只能实现简单的轮流分配，不能处理故障，第二如果是基于MS IIS，Windows 2003 server本身就带了负载均衡服务，第三是硬件方式，通过交换机的功能或专门的负载均衡设备可以实现，第四种是软件方式，通过一台负载均衡服务器进行，上面安装软件。使用Apache Httpd Server做负载平衡器，Tomcat集群节点使用Tomcat就可以做到以上第四种方式。这种方式比较灵活，成本相对也较低。另外一个很大的优点就是可以根据应用的情况和服务器的情况采取一些策略。
[NextPage]
四. 自身调整
本节将向您详细介绍一些加速可使Tomcat实例加速运行的技巧和方法，无论是在什么操作系统或者何种Java虚拟机上。在有些情况下，您可能没有控制部署环境上的操作系统或者Java虚拟机。在这种情况下，您就需要逐行了解以下的的一些建议，然而你应该在修改后使之生效。我认为以下方法是Tomcat性能自身调整的最佳方式。
1.禁用DNS查询
当web应用程序向要记录客户端的信息时，它也会记录客户端的IP地址或者通过域名服务器查找机器名转换为IP地址。DNS查询需要占用网络，并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程，这样会消耗一定的时间。为了消除DNS查询对性能的影响我们可以关闭DNS查询，方式是修改server.xml文件中的enableLookups参数值：
Tomcat4
<Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=80 minProcessors=5 maxProcessors=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=20000 useURIValidationHack=false disableUploadTimeout=true />
Tomcat5
<Connector port=80 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=20000 disableUploadTimeout=true/>
除非你需要连接到站点的每个HTTP客户端的机器名，否则我们建议在生产环境上关闭DNS查询功能。可以通过Tomcat以外的方式来获取机器名。这样不仅节省了网络带宽、查询时间和内存，而且更小的流量会使日志数据也会变得更少，显而易见也节省了硬盘空间。对流量较小的站点来说禁用DNS查询可能没有大流量站点的效果明显，但是此举仍不失为一良策。谁又见到一个低流量的网站一夜之间就流量大增呢？
2.调整线程数
另外一个可通过应用程序的连接器（Connector）进行性能控制的的参数是创建的处理请求的线程数。Tomcat使用线程池加速响应速度来处理请求。在Java中线程是程序运行时的路径，是在一个程序中与其它控制线程无关的、能够独立运行的代码段。它们共享相同的地址空间。多线程帮助程序员写出CPU最大利用率的高效程序，使空闲时间保持最低，从而接受更多的请求。
Tomcat4中可以通过修改minProcessors和maxProcessors的值来控制线程数。这些值在安装后就已经设定为默认值并且是足够使用的，但是随着站点的扩容而改大这些值。minProcessors服务器启动时创建的处理请求的线程数应该足够处理一个小量的负载。也就是说，如果一天内每秒仅发生5次单击事件，并且每个请求任务处理需要1秒钟，那么预先设置线程数为5就足够了。但在你的站点访问量较大时就需要设置更大的线程数，指定为参数maxProcessors的值。maxProcessors的值也是有上限的，应防止流量不可控制（或者恶意的服务攻击），从而导致超出了虚拟机使用内存的大小。如果要加大并发连接数，应同时加大这两个参数。web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。
在Tomcat5对这些参数进行了调整，请看下表：
|
属性名 |
描述 |
|
maxThreads |
Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。 |
|
acceptCount |
指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。 |
|
connnectionTimeout |
网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。 |
|
minSpareThreads |
Tomcat初始化时创建的线程数。 |
|
maxSpareThreads |
一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。 |
最好的方式是多设置几次并且进行测试，观察响应时间和内存使用情况。在不同的机器、操作系统或虚拟机组合的情况下可能会不同，而且并不是所有人的web站点的流量都是一样的，因此没有一刀切的方案来确定线程数的值。
[NextPage]
3.加速JSP编译速度
当第一次访问一个JSP文件时，它会被转换为Java serverlet源码，接着被编译成Java字节码。你可以控制使用哪个编译器，默认情况下，Tomcat使用使用命令行javac进行使用的编译器。也可以使用更快的编译器，但是这里我们将介绍如何优化它们。
另外一种方法是不要把所有的实现都使用JSP页面，而是使用一些不同的java模板引擎变量。显然这是一个跨越很大的决定，但是事实证明至少这种方法是只得研究的。如果你想了解更多有关在Tomcat可使用的模板语言，你可以参考Jason Hunter和William Crawford合著的《Java Servlet Programming 》一书（O'Reilly公司出版）。
在Tomcat 4.0中可以使用流行而且免费的Jikes编译器。Jikes编译器的速度要由于Sun的Java编译器。首先要安装Jikes（可访问http://oss.software.ibm.com/pub/jikes 获得更多的信息），接着需要在环境变量中设置JIKESPATH包含系统运行时所需的JAR文件。装好Jikes以后还需要设置让JSP编译servlet使用Jikes，需要修改web.xml文件中jspCompilerPlugin的值：
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>
org.apache.jasper.servlet.JspServlet
</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>WARNING</param-value>
</init-param>
<init-param>
<param-name>jspCompilerPlugin</param-name>
<param-value>
org.apache.jasper.compiler.JikesJavaCompiler
</param-value>
</init-param>
<init-param>
<!-- <param-name>
org.apache.catalina.jsp_classpath
</param-name> -->
<param-name>classpath</param-name>
<param-value>
/usr/local/jdk1.3.1-linux/jre/lib/rt.jar:
/usr/local/lib/java/servletapi/servlet.ja
r</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
在Tomcat 4.1（或更高版本），JSP的编译由包含在Tomcat里面的Ant程序控制器直接执行。这听起来有一点点奇怪，但这正是Ant有意为之的一部分，有一个API文档指导开发者在没有启动一个新的JVM的情况下，使用Ant。这是使用Ant进行Java开发的一大优势。另外，这也意味着你现在能够在Ant中使用任何javac支持的编译方式，这里有一个关于Apache Ant使用手册的javac page列表。使用起来是容易的，因为你只需要在 元素中定义一个名字叫“compiler”，并且在value中有一个支持编译的编译器名字，示例如下：
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>
org.apache.jasper.servlet.JspServlet
</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>WARNING</param-value>
</init-param>
<init-param>
<param-name>compiler</param-name>
<param-value>jikes</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
Ant可用的编译器
|
名称 |
别名 |
调用的编译器 |
|
classic |
javac1.1, javac1.2 |
Standard JDK 1.1/1.2 compiler |
|
modern |
javac1.3, javac1.4 |
Standard JDK 1.3/1.4 compiler |
|
jikes |
|
The Jikes compiler |
| JVC |
Microsoft |
Microsoft command-line compiler from the Microsoft SDK for Java/Visual J++ |
| KJC |
|
The kopi compiler |
| GCJ |
|
The gcj compiler (included as part of gcc) |
| SJ |
Symantec |
Symantec's Java compiler |
|
extJavac |
|
Runs either the modern or classic compiler in a JVM of its own |
由于JSP页面在第一次使用时已经被编译，那么你可能希望在更新新的jsp页面后马上对它进行编译。实际上，这个过程完全可以自动化，因为可以确认的是新的JSP页面在生产服务器和在测试服务器上的运行效果是一样的。
[NextPage]
在Tomcat4的bin目录下有一个名为jspc的脚本。它仅仅是运行翻译阶段，而不是编译阶段，使用它可以在当前目录生成Java源文件。它是调试JSP页面的一种有力的手段。
可以通过浏览器访问再确认一下编译的结果。这样就确保了文件被转换成serverlet，被编译了可直接执行。这样也准确地模仿了真实用户访问JSP页面，可以看到给用户提供的功能。也抓紧这最后一刻修改出现的bug并且修改它J
Tomcat提供了一种通过请求来编译JSP页面的功能。例如，你可以在浏览器地址栏中输入http://localhost:8080/examples/jsp/dates/date.jsp?jsp_precompile=true，这样Tomcat就会编译data.jsp而不是执行它。此举唾手可得，不失为一种检验页面正确性的捷径。
4. 其它
前面我们提到过操作系统通过一些限制手段来防止恶意的服务攻击，同样Tomcat也提供了防止恶意攻击或禁止某些机器访问的设置。
Tomcat提供了两个参数供你配置：RemoteHostValve 和RemoteAddrValve。
通过配置这两个参数，可以让你过滤来自请求的主机或IP地址，并允许或拒绝哪些主机/IP。与之类似的，在Apache的httpd文件里有对每个目录的允许/拒绝指定。
例如你可以把Admin Web application设置成只允许本地访问，设置如下：
<Context path=/path/to/secret_files ...>
<Valve className=org.apache.catalina.valves.RemoteAddrValve
allow=127.0.0.1 deny=/>
</Context>
如果没有给出允许主机的指定，那么与拒绝主机匹配的主机就会被拒绝，除此之外的都是允许的。与之类似，如果没有给出拒绝主机的指定，那么与允许主机匹配的主机就会被允许，除此之外的都是拒绝的。
五. 容量计划
容量计划是在生产环境中使用Tomcat不得不提的提高性能的另一个重要的话题。如果你没有对预期的网络流量下的硬件和带宽做考虑的话那么无论你如何做配置修改和测试都无济于事。
这里先对提及的容量计划作一个简要的定义：容量计划是指评估硬件、操作系统和网络带宽，确定应用服务的服务范围，寻求适合需求和软件特性的软硬件的一项活动。因此这里所说的软件不仅包括Tomcat，也包括与Tomcat结合使用的任何第三方web服务器软件。
如果在购买软硬件或部署系统前你对容量计划一无所知，不知道现有的软硬件环境能够支撑多少的访问量，甚至更糟直到你已经交付并且在生产环境上部署产品后才意识到配置有问题时再进行变更可能为时已晚。此时只能增加硬件投入，增加硬盘容量甚至购买更好的服务器。如果事先做了容量计划那么就不会搞的如此焦头烂额了。
我们这里只介绍与Tomcat相关的内容。
首先为了确定Tomcat使用机器的容量计划，你应该从一下列表项目种着手研究和计划：
1. 硬件
采用什么样的硬件体系？需要多少台计算机？使用一个大型的，还是使用多台小型机？每个计算机上使用几个CPU？使用多少内存？使用什么样的存储设备，I/O的处理速度有什么要求？怎样维护这些计算机？不同的JVM在这些硬件上运行的效果如何（比如IBM AIX系统只能在其设计的硬件系统上运行）？
2. 网络带宽
带宽的使用极限是多少？web应用程序如何处理过多的请求？
3. 服务端操作系统
采用哪种操作系统作为站点服务器最好？在确定的操作系统上使用哪个JVM最好？例如，JVM在这种系统上是否支持本地多线程，对称多处理？哪种系统可使web服务器更快、更稳定，并且更便宜。是否支持多CPU？
[NextPage]
4. Tomcat容量计划
以下介绍针对Tomcat做容量计划的步骤：
1） 量化负载。如果站点已经建立并运行，可以使用前面介绍的工具模仿用户访问，确定资源的需求量。
2） 针对测试结果或测试过程中进行分析。需要知道那些请求造成了负载过重或者使用过多的资源，并与其它请求做比较，这样就确定了系统的瓶颈所在。例如：如果servlet在查询数据库的步骤上耗用较长的时间，那么就需要考虑使用缓冲池来降低响应时间。
3） 确定性能最低标准。例如，你不想让用户花20秒来等待结果页面的返回，也就是说甚至在达到访问量的极限时，用户等待的时间也不能超过20秒种（从点击链接到看到返第一条返回数据）。这个时间中包含了数据库查询时间和文件访问时间。同类产品性能在不同的公司可能有不同的标准，一般最好采取同行中的最低标准或对这个标准做出评估。
4） 确定如何合理使用底层资源，并逐一进行测试。底层资源包括CPU、内存、存储器、带宽、操作系统、JVM等等。在各种生产环境上都按顺序进行部署和测试，观察是否符合需求。在测试Tomcat时尽量多采用几种JVM，并且调整JVM使用内存和Tomcat线程池的大小进行测试。同时为了达到资源充分合理稳定地使用的效果，还需针对测试过程中出现的硬件系统瓶颈进行处理确定合理的资源配置。这个过程最为复杂，而且一般由于没有可参考的值所以只能靠理论推断和经验总结。
5） 如果通过第4步的反复测试如果达到了最优的组合，就可以在相同的生产环境上部署产品了。
此外应牢记一定要文档化你的测试过程和结果，因为此后可能还会进行测试，这样就可以拿以前的测试结果做为参考。另外测试过程要反复多次进行，每次的条件可能都不一样，因此只有记录下来才能进行结果比较和最佳条件的选择。
这样我们通过测试找到了最好的组合方式，各种资源得到了合理的配置，系统的性能得到了极大的提升。
六. 附加资料
很显然本文也很难全面而详尽地阐述性能优化过程。如果你进行更多研究的话可能会把性能调优做的更好，比如Java程序的性能调整、操作系统的调整、各种复杂环境与应用系统和其它所有与应用程序相关的东西。在这里提供一些文中提到的一些资源、文中提到的相关内容的链接以及本文的一些参考资料。
1. Web性能测试资料及工具
1） Jmeter Wiki首页，Jmeter为一个开源的100%Java开发的性能测试工具
http://wiki.apache.org/jakarta-jmeter/
2） Apache Benchmark使用说明
http://httpd.apache.org/docs-2.0/programs/ab.html
3） 一些Java相关测试工具的介绍，包含可以与Tomcat集成进行测试的工具
http://blog.csdn.net/wyingquan/
4） LoadRunner® 是一种预测系统行为和性能的工业标准级负载测试工具。它通过模拟数据以千万计用户来实施并发负载来对整个企业架构进行测试，来帮助您更快的查找和发现问题。
http://www.mercury.com/us/products/performance-center/loadrunner/
2. 文中介绍的相关内容的介绍
1） Apache 2.x + Tomcat 4.x做负载均衡，描述了如何利用jk配置集群的负载均衡。
http://raibledesigns.com/tomcat/index.html
2） 容量计划的制定，收集了许多有关制定web站点容量计划的例子：
http://www.capacityplanning.com/
3） 评测Tomcat5负载平衡与集群，
http://www.javaresearch.org/article/showarticle.jsp?column=556&thread=19777
4） Apache与Tomcat的安装与整合之整合篇
http://www.javaresearch.org/article/showarticle.jsp?column=23&thread=18139
5） 性能测试工具之研究，介绍了性能测试工具的原理与思路
http://www.51testing.com/emagzine/No2_2.htm
6） Java的内存泄漏
http://www.matrix.org.cn/resource/article/409.html
7） Web服务器和应用程序服务器有什么区别？
http://www.matrix.org.cn/resource/article/1429.html
8） 详细讲解性能中数据库集群的问题
http://www.theserverside.com/articles/article.tss?l=DB_Break
|
恭喜，你选择开发工程师做为自已的职业
悲哀，你选择开发工程师做为自已的职业
本文所指的开发工程师，仅指程序开发人员和以数字电路开发为主的电子工程师。
当你选择计算机或者电子、自控等专业进入大学时，你本来还是有机会从事其它行业的，可你毕业时执迷不悟，仍然选择了开发做为你的职业，真是自做孽不可活。不过，欢迎你和我一样加入这个被其它人认为是风光无限的“白领”吧。
如果你不是特别的与人世隔绝，我想你一定看过金老先生的名著《笑傲江湖》吧，里面有一门十分奇特的武功叫做"辟邪剑法"，你看这个小说第一次看到这种功夫的练法时，我想你当时一定笑歪了牙“呵呵，真好玩！”，可是现在我很痛心的告诉你：你选择的开发工作就是你人生路上的"辟邪剑法"，而你现在已经练了，并且无法再回头。
相对同时刚出校门同学从事其它行业而言优厚的薪水，以及不断学习更新的专业知识不仅仅让你感到生活的充实，更满足了你那不让外人知的虚荣心。在刚出校门的几年中，你经常回头看看被你落在后面的同学们，在内心怜悯他们的同时，你也会对自已天天加班的努力工作感到
心里平衡：“有付出才会有回报”这句话在那几年中你说的最多，不管是对自已的朋友们还是自已的爱人。第二句最常说的话是对公司的领导：“不行我就走人！”，实际上你也真的走过几回。对了，在这几年中，因为你的经济条件不错，你开始买房、开始谈恋爱、结婚、开始有了自已的小孩。有时候你会对自已说再过两年就去买车。当然其中可能有许多大件是需要分期付款的，但你对前途充满了信心，你确信认为这种日子会永远的持续下去，即使不是变得更好的话。
日子总是在这种平淡中一天天的过去，就在那么不经意间，你突然发现自已已经快30岁了，或者已经30了，莫名的，你心里会漫延着一种说不清楚的不安情绪，你好像觉得前途并非像前几年那样变得越来越好，你也忽然发现你以前所瞧不起的同学里好像已经有不少开着车的了，也有几个人住着比你还大的房子，好像房款还是一次付清的，你突然明白你现在的生活比起你的同学来最多是中游偏上了。工作中最让你感到心里不舒服的是，你越来越不敢对你的领导说不了，即使比你来的晚的同事升职或提薪，你也只是在私下与朋友们一起喝酒时才敢发发牢骚，在头的面前你的声间越来越小、笑脸是越来越温柔。
你终于开始迷茫“再过几年我会是在干什么呢？”，这句话常常出现在你的心里。
计算机开发工作，是一种以年轻为资本的工作，说句通俗点的话是“吃青春饭的”，嗯，这句话好像在一种特别的行业也听到过。
其标志就是一：工作的时间性非常强，一个开发项目被定的时限通常是很紧张的，更有甚者，有些号称开发管理的书里面还非常卑鄙的号召将一个项目切成多个小片，每个小片都定一个叫“里程碑”的东东来严格跟踪开发进度，加班加点在其它行业是需要加班工资的，而在开发行业，加班工资好像还没见到几个公司发过，是啊，反正有时间限制着，你干不完我再找你算账.所以开发工作通常有着其它工作所没有的精神上的压力。
一旦一个人步入而立之年，因为家庭和孩子的负担，加上精力上面的衰退，加班工作时间变得越来越少，这点让很多老板们感到：这些人已经老了，不好用了。指示人事部门：“以后招开发人员限制在30岁以下！”，相对而言硬件开发会年龄方面限制会稍好一点点，但也是五十步笑百步。还有一个很重要的一点就是：计算机这个烂东东实在是进步的太快了，前两年买的顶级配置电脑，现在怎么看怎么像废品，这还是小事，更可气的是好像每天都需要学习新的知识，刚毕业时只会书本上的PASCAL，学会了用腐蚀的办法来做电路板，一上班就开始学习TURBOC和TANGER2.0，刚刚学会，还没来得及高兴，马上开始学Borland C＋＋和Protel3.0，好不容易学会了，却发现需要学习VC和Protel98了。单片机也是啊：Z80的指令背的很熟，工作中没来得及用就要学8031，好好学吧，本来想着这辈子就吃它了，又发现又出来什么PIC、DSP、CPLD、FPGA、ARM等等....这还不包括中间要学一大堆74系列、4000系列、XX系列...IC卡居然里面还有CPU卡..如果学习的知识里每个字都能变成一分钱，我想所有的开发工程师都是腰缠万贯的富翁。
一眼看去，这种日子好像见不到头，年轻时乐此不彼，但现在你一定对自已能坚持到什么时候感到怀疑了。我们都玩过像仙剑奇侠传这样的RPG游戏，刚开始时你只是一个一名不文的少年，随着你去打怪物、捡宝贝、学秘芨，最后终于有一天你会变成一个大英雄！那么你在实际生活中过得比那些小侠们还辛苦，为什么成不了一个生活中的大侠呢？呵呵，原因在这里：因为开发工作是邪门功夫，它虽然可以让你速成的变成小资，但它最大的特点是经验不积累！日新月异的知识更新，让你总是感到自已在退步，你就像在RPG中的主人公，开始时就给了你一把好剑和好盔甲，而且让你的级别很高，但让你的经验不累积，虽然刚开始打小怪物时你觉得自已很爽，但越到后来，你会发现你会死的很惨！比较一下你与其它非开发行业的同学你就可以知道了，例如和你学医的同学比起来。套用岳不群他老人家说华山剑宗和气宗的区别那段话：前十年你比你那些学医的同学收入和地位要好的多，但十年以后你和他基本上各方面都会持平，而二十年以后你的各方面远远不能与你学医的同学相提并论！嗯，你已经开始不笑辟邪剑法了吧。
“敢问路在何方？路在脚下...”，不过猴兄和八戒兄这么认为是可以的，你呢？
总结了许多开发朋友在30岁以后的生活之路，让我们一起看看开发人员“路在何方？”那么开发人员在30岁以后都干些什么呢？
其路一：继续做你这个很有“前途”的职业吧！
偶掰着脚指头仔细数了数，发现还真的有很多朋友在30岁以后还在从事开发工作，我这里说的从事，是指你还需要天天在电脑边上编程序和画电路板，与你手下是否有几个小兵无关，也与你是否头上顶着什么项目经理、主任工程师的帽子无关，只要你还需要亲自开发，你就属于这一类。其中有个年龄最大的朋友是63年的，从事医疗仪器的开发工作，35岁左右还在从事软硬件开发工作的仍有一大堆，分析这些仍然从事开发的朋友，基本上都有以下特点：
1 痴迷工作或者痴迷电脑，晚上八点到十二点的这段时间，基本上是在电脑桌或工作台前渡过的。
2 不喜欢与人交住，朋友很少，常联系的人不超过五个。
3 与朋友交往时谈工作多，但一般不主动谈钱。
4 体型偏胖或偏廋，不在正常区间。
5 无未来计划，对五年后自已生活怎么样、从事什么工作说不清楚。
6 俭省，从不乱花钱。
即使你是还不到30岁的开发人员，你也可以看看自己对以上几条是否符合，是否会在30岁后还从事开发职业，四条疑似，五条以上基本确诊你也是这类型的人。
这些朋友们通常报着过一天是一天的态度生活，到了这个年龄，也不敢再轻易的换工作了，年轻时的锐气慢慢的也消退了。唯一不变的希望是有一天从天上掉下来一大堆钱把自己砸伤。说实在话因为他们的性格所限，基本上可以确定他们以后不可能在职场上获得更好的发展，当个小头头，带几个人开发已经是他们发展的顶点。至于以后的人生之路，不仅他们自己迷茫，可能上帝也正在头痛。
不过像这类朋友，偶很奇怪的发现：他们的小孩都是儿子！不知是偶然还是有什么其它说法。
简单建议：要改变命运，先改变性格：坚持半年晚上不从事工作、游戏及电视，用此时间与人交往，你的人生会有改变。
其路二：转行从事技术支持、行政或生产等工作还有一些朋友，从事了几年的开发工作，因为自已并非特别的爱好，或者领导上面的强制工作安排，他们转到了技术支持、服务或行政等工作，至少当时从表面上看起来，他们的薪水较开发要少一些，但真正的统计这些人，发现他们之中有半数的人获得了更好的发展，升职为服务部经理或行政经理等职，最历害的一个朋友已升职为总经理助理，进入高层。
这类朋友当时转行通常并非自已志愿，属被逼无奈或者其它原因，但显然，拥有专业知识技术的他们显然在非技术部门中鹤立鸡群，遇到什么事情他们均可从专业的角度提出建言，久而久之，他们获得更多的升职和加薪机会也就不足为奇。
因为不从事开发，所以经验开始积累，这类的职业通常会给你一个很安定的感觉，你到30多岁后会发现这类职业反而比开发工作更容易获得新的工作机会。
简单建议：你如果确定在开发部无法获得很好的发展机会，不妨转到其它几个部门试试，换个活法，钱少点就少点吧，机会多。
其路三：开发管理
如果你现在已经是总工或开发部经理，或者你眼看就有机会被提升为这类职务，那么恭喜你，你走的是从“弼马温”到“斗战胜佛”这条金光大路，你不仅拥有很高的专业技能，而且很显然，你也有着很强的人际交往能力，你这类人根本不需要对未来有着任何的担心，你在即使一无所有的时候也很容易白手起家。
你这种人算是练辟邪剑法练成了仙，嗯，我无话可说。
你是不是这类人也很容易区别，就像围棋二十岁不称国手终身无望一样，你应该在工作三、四年以后，也就是说二十七岁左右就会发现自已工作中指手划脚的时间比亲自开发的时间要多了，而且大多数这类人在这个年龄手下应该有“兵”了，相反的，如果你快30岁了还天天埋头于电脑前编程序和画板子，或者30多岁了你还没升到部门经理（虽然你总是觉得自已很有希望），基本上可以确定你不是这类人。好了，如果你确定你是这类人，那么你唯一的想法就是尽快爬上中层和高层，因为有时候人生偶然性太大，不占住坑的萝卜很有可能被人拔出来！
简单建议：天天去你的老板家里面拖地和擦桌子！
其路四：出国或考研
有两个搞开发后出国的朋友，其中一个甚至打工打到了一个小公司总工的位置，数据库和软件方面水平巨牛，但仍感觉心里不踏实，于是将自己工作多年的钱忍痛掏出来，出国费加上机票大概将自已辛苦所攒的银子花完，然后又借了一些钱，在02年身上揣着一万美元跑去了加拿大，在加拿大不停的重复找工作，换工作，然后再找工作的循环，找的工作基本上与计算机无关，不过工资总是在1500加元左右，呵呵，折成人民币与他在国内打工拿的基本上差不多，不过租个地下室就花了300加元，然后吃吃喝喝，再买个电脑上上网这类的，基本每月平均还要倒贴一点。前段时间给我的邮件里说，现在身上花的差不多只有5、6000美元了，准备开个小公司，看看能不能往国内倒腾点东东，做最后一搏。另外一个朋友去澳州，时间稍早一些，先是大概摘了一年多的葡萄，后来总算找了个技术工作，每天的工作是画机械图纸，收入还算不错
将近3000澳元，买了个旧车，也算是过上了资本主义生活。不过前年回来一趟，唯一的感叹就是：在国外拿2000美元的生活，绝对不如在国内拿5000人民币的生活舒服。
也有两个考研的朋友，不过其中一个严格的说不是做开发的出身，偏重于市场方面的工作性质，不过我的朋友里面考研的不多，只好凑两个人说说，一个考研后在北京找了个工作，每个月5、6000元钱，但还是做开发，生活仍然与没考研之前没有任何的改变，前途仍然没见到什么大亮的光，还是搞不清楚以后再干些什么，标准的过一天算一天了。另外一个考研后在大学里面找了个工作，工资虽然比他原来打工少了不少，但毕竟终身有靠，稳定了下来，也算修成了正果，这位哥们心情一放松下来，也开始有时间琢磨着业余时间自已做点什么，好像现在慢慢的也开始有了点眉目。
简单建议：这两条路，对开发人员来说都不算是很好，出国十年前是好事，现在难说，考研能成功转行的概率恐怕也不是很大，多半仍然去搞开发，只不过研究生可以多干几年罢了。
其路五：转行到市场
绞尽脑汁的想想，我所知道的人之中只有两个开发人员去了市场，这两个人都不能说是朋友，认识而已。他们都是主动要求去了市场，结果是这两个人均在市场都是干到一年左右，然后都自已开公司了。呵呵，很奇怪，极高的转行成功率！不过仔细想想，我对这两个人的思路佩服的五体投地。能下决心仍掉每月5、6000元的开发职位，从事一个自已并不熟悉的岗位，每月拿个2000多元＋提成，但提成那是说不清楚的事情，这个决定，只能让人感觉到他们对自已前途清晰的把握和老谋深算的心机。而且他们不去服务不去生产，挖空心思说服领导去市场（市场部门与开发部门通常是一个公司的核心部门，进入其实并不容易），可以说是有着长远的考虑的。有技术了，再与客户交成朋友，马上就会产生很大的机遇应该是正常的事情。
有实力，有心机，也有着很强的决心力，这种人恐怕早在大学毕业时或更早的时候就已经决定了自已的人生之路，他们的每一步路在若干年前早就计划周全，现在看起来：学会技术－＞进入市场－＞寻找商机－＞开公司，一条多么清楚的人生之路。但就像我们上小学中学时，所有人都知道上大学是我们最清楚的人生路一样，最后只有少数人才能真正达到目标（当然，现在扩招的历害是另外一回事，我是说我们那个时候，也就是：“很久很久以前，当我像你那么大的时候”）。
简单建议：你若是这类人，我的建议是：...嗯?....那个你.你，你别走啊，我还有个事想请你赞助一下啊.....
其路六：开公司自已干
呵呵，看到这一条，发现你的眼睛已经圆了，你肯定千百次的想过这个事情吧，咳咳，其实我从事开发的时候也是天天梦想着这种事情。总想着过两年找个机会就自已干，这个梦想一年又一年的折磨着你也给着你希望。看看吧，开发后来开公司的还真的不少，里面有成功的也有很多失败的，通常开公司都是几个人合伙开始的，有做技术的，有做市场的，几个人一拍即合、狼狈为奸，共同策划了这一个大活动。一般说来能让这几个人下决心走出这一步，产品肯定是先进的，甚至是国内独一无二的，市场也是很大的，负责市场的那个哥们通常会拍着胸保证可以卖出去，并悄悄地告诉你他在某主管领导是他小舅子的同学的二叔，肯定没问题。于是你们几个人找地点、注册执照、买了几个破桌子，再攒了两台电脑，每个人又凑了几万银子，公司开张了！
产品很快出来了，市场的哥们也不负重望，有几个客户表示要试用了，一切看起来都是如此的正常，“.......你坐在老板桌前，不停的有人来汇报工作或者找你签字...人进人出中...你又想起公司再穷也不能只有一把椅子的故事.....”你在梦中笑出声来。
是如此的顺利，你们很快就有单子了，很快的单子让你们凑的那点钱不够了，你们很高兴的每个人又增加了投入，拿出钱时你眼泪汪汪的数着钱说：“这就是我那生蛋的母鸡啊”。你们的产品确实不错，市场也经营的很好，客户慢慢的多了起来，单子来的时候一笔接着一笔，你每天都处于兴奋之中，唯一美中不足的是好像客户回款总是会拖一些日子，不过客户给你保证说：过几天，过几天就付给你们，因为回款总是在计划外，所以你们为了资金的流畅运行又凑了一些钱，这个时候你有一些心事了，因为你的存款折上面的数字已经快趋向于零了。“没事，过两个月等回款了一切都OK了，谁干事业不吃点苦呢？”你这么安慰着自已又投入到工作中去，资金总是在回款和生产经营费用之间走着一个窄窄的小木桥，你的账上总是没有太多的钱，扩大了的公司规模和许多意外情况，使你又一次、二次、三次的与合作者们再次投入了自已的资金，当然，后来的钱你可能已经是借的了.....
终于有一天，你的会计再一次告诉你，老板啊，账上又没现金了，吃过多次苦头的你终于下决心开始重视资金的运行了，你裁掉了一些不必要的人手，减少了开发的投入，要求市场人员签单的时候必须予付XX%的款，回扣也必须等收过款后再付，同时也开始对产品的生产成本开始进行控制。
时间一天一天的过去，因为竟争对手的产品也对你的产品进行了仿造，你的产品慢慢变得不再先进，市场人员开始埋怨公司的合同资金方面规定太严格，不好签单，生产成本的下降通常也导至产品毛病的增多，客户也开始埋怨你的服务人员不能及时进行服务。
终于有一天，你重新走进了人才交流中心，以前你是来招人的，现在你拿着自已的简历开始寻找一个工作
......
公司的成功与否，与产品有关，与市场有关，但更重要的是与资金有关，产品与市场都可以通过资金来弥补，而却没有任何东西可以代替
资金，凡是倒下的公司，99%与资金链的断裂有关。在你决定要开公司以前，先估计一下你公司支持一年所需要的资金数额，包括人工费，生产，场地，广告宣传、市场费用、甚至电、水费等等等等，把你所想到的一切加在一起，得出的值就是..慢..如果你没有实际的开过公司的经验，你需要将此数字乘3，然后就是你开公司一年最少需要的费用，呵呵，公司的实际运营所需要的钱是你想像的3倍以上，你要是不信我也没办法。
简单建议：开公司前最重要的是先确立你后续的资金来源！也就是说钱不够了怎么办？－－－因为你投入的钱肯定会不够的。
其路七:第二职业
这类的朋友有不少,他们没有脱离开发工作,但是在业余时间又不停的接项目或者在卖产品,在单位里面他们显得并不出众,比起其它人来说他们属于最不愿意加班的一类.为此他们白天通常工作很勤奋.这类人也许不一定可以挣很多钱,但平均下来他们一年之中通常都可以比同事们多挣个几万元.有时候比上班拿得还多.但令人疑惑的是,这类人在生活中更加注重稳定,基本上没见到他们跳过蹧,即使私下里面已经开了个小公司,他们通常也不会辞职.
你的旁边有没有这类人呢?分辨他们很容易:
--电话很多,而且更愿意来电话时离开办公室找个没人的旮旯通话.神秘兮兮给人一种"这家伙是不是有二奶啊?"的感觉的人，通常是这类人。这类人是女性最佳的选择对象：很顾家，不象那些富人容易花心，而比起一般人来说，他们收入相对要高得多。但总结了一下几位这类的开发朋友：也得出了一个令人沮丧的结论：这种人通常个子不高，体形类似桶状.....
简单建议：这好像是开发人员最佳的出路了，但比较丰厚的收入通常让这类人不愿意去冒风险....到现在为止我所认识的这类人还没有一个真正算是成功的。
好了，虽然偶的经历远远说不上丰富，也没有什么成功之处可以自满的，但或许因为比其它朋友痴长了几岁，见过的人可能会稍多一些，所
以斗胆写出了以上的一些文字，让您掉牙了。
下面是偶走过开发这条路上总结出来的一点心得，你可以不看，但看了就千万别把嘴咧的太大：
一、不管是给别人打工还是自已干，都要全心全意的工作，因为你所做的任何一点工作都会让自已的人生多一点筹码，这一点最最重要!这样的例子我至少可以举出两起，优秀的开发人员被其它新公司挖走，并给一定的股份，成为新公司的股东的例子。当时与这样的开发人员一个部门同时工作或更早工作的有许多人，他们平时经常偷点懒，能少干点工作就少干点，有时候还笑话那个平时努力工作的人傻，几年过去了，究竟谁比谁傻？
二、多与市场人员交朋友，你接触他们时可能总会觉得他们知识比你少，甚至素质比你低，可能比你还有点黄。但实际上他们比你更懂这个社会！参加到他们这个圈子中去，和他们一起赌赌钱、一起聊聊天、一起洗洗桑拿、一起.....你会通过他们接触到另外一个世界。
三、机会远比钱重要，挣不挣钱在年轻时并不是特别重要！不论是在实际生活中还是在网上或其它地方，如果有机会参与到除本职工作外的一些项目或产品的开发中（包括你的朋友拉你去做点小生意之类的非开发性质的工作），那怕是帮忙的性质，也要积极介入，至少你会交到很多的朋友，这样你的人生会多出很多的机会。
一个政府项目总结
近几天刚刚交付验收了一个政府的软件项目，在这个项目的开发过程中遇到了不少困难，包括技术上的障碍和一些实际的人为上的问题。一个项目之所以能成功，能让客户满意，领导放心的原因可能大多都差不多，大多都是老生长谈的那几条。但是一个项目失败的原因却各有各的不同。下面再根据自己的体会写一些项目总结，一为了总结不足，积累经验，二为了以后项目中避免犯同样的错误。
一.要和客户有足够有效的沟通
和客户的沟通要贯穿整个项目开发的始终，从立项调研，需求获取到最后的验收测试，后期维护。
1.要尽量多的主动跟客户沟通
客户一般工作都很忙，所以要通过多种方式和客户保持沟通，电子邮件，电话，座谈，调查，会议等。最初的需求尽量保证有几次所有与项目相关的部门和人员都能参加的讨论会，把他们的各自的工作都描述一下，尽量不要遗漏，都罗列出来，因为这是原始需求。这往往不容易做到，因为政府部门很难抽出时间把各部门人员集中在一起来做这些事情的，但是我们必须得这样要求他们，要求他们把这个看成一项工作来抓，因为前期工作做不充分，后面的开发会不会很成功。在对某个功能或者需求不能确定的情况下，最好能整理成列表文档发给客户，让客户以电子版的形式重新描述一下发过来，尽量不要经常打电话骚扰客户，要集中把要了解东西发给客户，以便他们集中精力来处理你问的问题。
2.要尽量保证有效的沟通
每次沟通要有一定的目的性，把沟通交流的结果用文档的形式保存下来；需求制订出来要得到客户的确认，在经过几次反复之后会得到一个相对比较稳定的需求，虽然客户的需求不可能一直不变，这也是很多人搞项目头疼的地方，但是我认为客户的需求实际上是很少改变的，改变的是你对客户需求的理解。对客户的每一个要求都要重视，尤其是客户后来提到的一些改动建议，要让他们以书面的形式发过来，必要的时候要求负责人盖章签字，我们不能为了下面的下面的一个小办事员随便打个电话就对程序做出大的改动。再改动比较大的情况下，我们可以要求客户对合同的变更追加费用，前提是把需求做为合同的附件加进去，防治最后验收的时候造成争执。
3.和客户沟通要找准对象
一般企业或者政府都有专门负责信息的人员，而且最好要求客户那边找一个人专门负责这个项目。这样找对方了解需求的时候就不会出现不知道找谁的情况，客户那边有专人负责会带来很多好处，这个项目就是因为客户那边负责这个项目的人员经常更换而为我们项目的开发造成了很多的不变。
二.提高开发效率和保证项目质量
政府的项目一般都是开始的时候不着急，你催他们准备资料他们也不着急，但是一旦他们把资料准备全了，都交给你了就着急了，要求对方在很短的时间内保证质量的把项目交付。所以如何提高开发效率和保证项目质量是确保项目成功的关键。
1.保证良好充分的测试
当然软件测试的范畴很大，但是为了赶进度我们往往不能不保证进行所有的软件测试。软件的测试也是遍布整个项目开发周期的，我了解了一下TDD，TDD的思想很好，很适合开发中小型的项目，实施起来也很方便，但是不能纯粹的用敏捷开发的理论，必要的文档还是需要的。我认为代码模块的单元测试，开发最后阶段的集成测试和部署后的整体功能测试和用户验收测试是必不可少的。项目进度再紧张也要进行单元测试，只要保证单元测试能通过，以后代码可以慢慢重构。集成测试保证项目各个模块能良好的协作共同完成复杂的任务，这点不能保证的话，展示给客户的最终功能就不能保证。而功能测试和用户验收测试是纯粹的黑盒测试，自己内部人员先对照原始客户的需求进行功能测试，列出BUG列表，经过几次反复修改后给客户一个可以进行验收测试的系统。
2.保证相对必要的文档以及保证文档的可用性
每个模块的文档要独立起来，要实现的目标，测试的结果，模块所用的数据库的结构，存储过程，设计思路，调用的接口等这些是必须的。我也不建议面面俱到的文档，但必要的需求文档，模块文档，测试文档是必须的，我们的项目小的不足以让我们去学习庞大的RUP什么的。
3.迭代开发
刚开始可以根据客户的需求弄出一个蓝图来，交给客户看，以便让客户能尽量早的知道最终的开发出来的系统是什么样子的，这个蓝图要尽量直观，一般在需求整理完毕后一周就能出来，这也是指导以后开发工作的东西，要完整的包含所有的域模型，便于开发人员对问题域的理解。然后把优先级最高的一系列功能完整后出一个DEMO版给客户，要让客户尽量早的发现正在制作的项目和用户想要的结果的之间的偏离和差距，告诉你后以便你尽早的调整，别等你的正式版出来后用户发现这个功能你做的不对，你就傻了，那时候要改动的地方就太多了。然后再弄完善一下给用户个beta版，这时候就已经接近最终版本了，可能还有一些小BUG。最后把小BUG完善修复一下给客户正式版1.0让客户验收。至于二期项目以后再说，先把一期项目的余款结了再说，对吧。
4.制订开发规范
开发规范订的太死会限制程序员，每个开发人员都会有一些习惯，但是为了协作，制订一个相对通用的规范是有必要的。包括文档的规范，数据库设计规范，编码规范以及各种命名规则。尽量用一些业界通用的规范，网上都有，我CSDN的博客上也整理了一些，MSDN的类库开发人员指南里面也有一些。尽管某些规范很有争议，我感觉你也得选择其中一种来做为你的项目开发规范。
5.建立开发基础
保证机器和软件的可用，尽量大的内存，尽量快的处理器，操作系统，开发工具都要到位，该想到的就得想到，还要给开发人员一个相对安静舒适的环境，最好能很方便的喝到冰箱里的可乐，而且能在累的时候有绿色的植物看。再一个就是建立一个开发基础结构，这个也颇有争议，几乎每个公司都有自己的系统类库，开发框架以及配套的代码生成工具，这都很好，在开始可以对员工做适当的培训，让他们都能体验自底向上设计的好处，都能用的上这个架构，你可以在架构中要求开发人员以指定的方式实现某些通用的任务，比如说日志记录和错误处理等，而不是让他们使用自己习惯的方式去处理问题，因为.NET的灵活性让实现一个任务有很多中方案和手段。
小节：虽然这个帖子没有讨论具体技术，而且都是一些空话套话，并且这些空话套话可能别人也都说的不带说了，但我感觉还是有必要自己总结一下的。
http://onlytiancai.cnblogs.com/archive/2005/11/03/218335.html
昨天我在程序中添加了一个监听器，
net.risesoft.ContextListener
在修改程序时发现web.xml总是报错，最后Google一下后发现文件内的元素是次序。
现将web.xml规则经过整理总结如下：
1 定义头和根元素
部署描述符文件就像所有XML文件一样，必须以一个XML头开始。这个头声明可以使用的XML版本并给出文件的字符编码。
DOCYTPE声明必须立即出现在此头之后。这个声明告诉服务器适用的servlet规范的版本（如2.2或2.3）并指定管理此文件其余部分内容的语法的DTD(Document Type Definition，文档类型定义)。
所有部署描述符文件的顶层（根）元素为web-app。请注意，XML元素不像HTML，他们是大小写敏感的。因此，web-App和WEB-APP都是不合法的，web-app必须用小写。
2 部署描述符文件内的元素次序
XML 元素不仅是大小写敏感的，而且它们还对出现在其他元素中的次序敏感。例如，XML头必须是文件中的第一项，DOCTYPE声明必须是第二项，而web- app元素必须是第三项。在web-app元素内，元素的次序也很重要。服务器不一定强制要求这种次序，但它们允许（实际上有些服务器就是这样做的）完全拒绝执行含有次序不正确的元素的Web应用。这表示使用非标准元素次序的web.xml文件是不可移植的。
下面的列表给出了所有可直接出现在web-app元素内的合法元素所必需的次序。例如，此列表说明servlet元素必须出现在所有servlet-mapping元素之前。请注意，所有这些元素都是可选的。因此，可以省略掉某一元素，但不能把它放于不正确的位置。
l icon icon元素指出IDE和GUI工具用来表示Web应用的一个和两个图像文件的位置。
l display-name display-name元素提供GUI工具可能会用来标记这个特定的Web应用的一个名称。
l description description元素给出与此有关的说明性文本。
l context-param context-param元素声明应用范围内的初始化参数。
l filter 过滤器元素将一个名字与一个实现javax.servlet.Filter接口的类相关联。
l filter-mapping 一旦命名了一个过滤器，就要利用filter-mapping元素把它与一个或多个servlet或JSP页面相关联。
l listener servlet API的版本2.3增加了对事件监听程序的支持，事件监听程序在建立、修改和删除会话或servlet环境时得到通知。Listener元素指出事件监听程序类。
l servlet 在向servlet或JSP页面制定初始化参数或定制URL时，必须首先命名servlet或JSP页面。Servlet元素就是用来完成此项任务的。
l servlet-mapping 服务器一般为servlet提供一个缺省的URL：
http://host/webAppPrefix/servlet/ServletName。但是，常常会更改这个URL，以便servlet可以访问初始化参数或更容易地处理相对URL。在更改缺省URL时，使用servlet-mapping元素。l session-config 如果某个会话在一定时间内未被访问，服务器可以抛弃它以节省内存。可通过使用HttpSession的setMaxInactiveInterval方法明确设置单个会话对象的超时值，或者可利用session-config元素制定缺省超时值。
l mime-mapping 如果Web应用具有想到特殊的文件，希望能保证给他们分配特定的MIME类型，则mime-mapping元素提供这种保证。
l welcom-file-list welcome-file-list元素指示服务器在收到引用一个目录名而不是文件名的URL时，使用哪个文件。
l error-page error-page元素使得在返回特定HTTP状态代码时，或者特定类型的异常被抛出时，能够制定将要显示的页面。
l taglib taglib元素对标记库描述符文件（Tag Libraryu Descriptor file）指定别名。此功能使你能够更改TLD文件的位置，而不用编辑使用这些文件的JSP页面。
l resource-env-ref resource-env-ref元素声明与资源相关的一个管理对象。
l resource-ref resource-ref元素声明一个资源工厂使用的外部资源。
l security-constraint security-constraint元素制定应该保护的URL。它与login-config元素联合使用
l login-config 用login-config元素来指定服务器应该怎样给试图访问受保护页面的用户授权。它与sercurity-constraint元素联合使用。
l security-role security-role元素给出安全角色的一个列表，这些角色将出现在servlet元素内的security-role-ref元素的role-name子元素中。分别地声明角色可使高级IDE处理安全信息更为容易。
l env-entry env-entry元素声明Web应用的环境项。
l ejb-ref ejb-ref元素声明一个EJB的主目录的引用。
l ejb-local-ref ejb-local-ref元素声明一个EJB的本地主目录的应用。
3 分配名称和定制的UL
在web.xml中完成的一个最常见的任务是对servlet或JSP页面给出名称和定制的URL。用servlet元素分配名称，使用servlet-mapping元素将定制的URL与刚分配的名称相关联。
3.1 分配名称
为了提供初始化参数，对servlet或JSP页面定义一个定制URL或分配一个安全角色，必须首先给servlet或JSP页面一个名称。可通过 servlet元素分配一个名称。最常见的格式包括servlet-name和servlet-class子元素（在web-app元素内），如下所示：
Test
moreservlets.TestServlet
这表示位于WEB-INF/classes/moreservlets/TestServlet的servlet已经得到了注册名Test。给 servlet一个名称具有两个主要的含义。首先，初始化参数、定制的URL模式以及其他定制通过此注册名而不是类名引用此servlet。其次,可在 URL而不是类名中使用此名称。因此，利用刚才给出的定义，URL
http://host/webAppPrefix/servlet/Test 可用于
http://host/webAppPrefix/servlet/moreservlets.TestServlet 的场所。
请记住：XML元素不仅是大小写敏感的，而且定义它们的次序也很重要。例如，web-app元素内所有servlet元素必须位于所有servlet- mapping元素（下一小节介绍）之前，而且还要位于5.6节和5.11节讨论的与过滤器或文档相关的元素（如果有的话）之前。类似地，servlet 的servlet-name子元素也必须出现在servlet-class之前。5.2节"部署描述符文件内的元素次序"将详细介绍这种必需的次序。
例如，程序清单5-1给出了一个名为TestServlet的简单servlet，它驻留在moreservlets程序包中。因为此servlet是扎根在一个名为deployDemo的目录中的Web应用的组成部分，所以TestServlet.class放在deployDemo/WEB- INF/classes/moreservlets中。程序清单5-2给出将放置在deployDemo/WEB-INF/内的web.xml文件的一部分。此web.xml文件使用servlet-name和servlet-class元素将名称Test与TestServlet.class相关联。图 5-1和图5-2分别显示利用缺省URL和注册名调用TestServlet时的结果。
程序清单5-1 TestServlet.java
package moreservlets;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Simple servlet used to illustrate servlet naming
* and custom URLs.
*
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String uri = request.getRequestURI();
out.println(ServletUtilities.headWithTitle("Test Servlet") +
"\n" +
"
URI: " + uri + "
\n" +
"");
}
}
程序清单5-2 web.xml（说明servlet名称的摘录）
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"
http://java.sun.com/dtd/web-app_2_3.dtd">
Test
moreservlets.TestServlet
3.2 定义定制的URL
大多数服务器具有一个缺省的serlvet URL：
http://host/webAppPrefix/servlet/packageName.ServletName。虽然在开发中使用这个URL很方便，但是我们常常会希望另一个URL用于部署。例如，可能会需要一个出现在Web应用顶层的URL（如，http: //host/webAppPrefix/Anyname），并且在此URL中没有servlet项。位于顶层的URL简化了相对URL的使用。此外，对许多开发人员来说，顶层URL看上去比更长更麻烦的缺省URL更简短。
事实上，有时需要使用定制的URL。比如，你可能想关闭缺省URL映射，以便更好地强制实施安全限制或防止用户意外地访问无初始化参数的servlet。如果你禁止了缺省的URL，那么你怎样访问servlet呢？这时只有使用定制的URL了。
为了分配一个定制的URL，可使用servlet-mapping元素及其servlet-name和url-pattern子元素。Servlet- name元素提供了一个任意名称，可利用此名称引用相应的servlet；url-pattern描述了相对于Web应用的根目录的URL。url- pattern元素的值必须以斜杠（/）起始。
下面给出一个简单的web.xml摘录，它允许使用URL
http://host/webAppPrefix/UrlTest而不是http://host/webAppPrefix/servlet/Test或http: //host/webAppPrefix/servlet/moreservlets.TestServlet。请注意，仍然需要XML头、 DOCTYPE声明以及web-app封闭元素。此外，可回忆一下，XML元素出现地次序不是随意的。特别是，需要把所有servlet元素放在所有 servlet-mapping元素之前。
Test
moreservlets.TestServlet
Test
/UrlTest
URL模式还可以包含通配符。例如，下面的小程序指示服务器发送所有以Web应用的URL前缀开始，以..asp结束的请求到名为BashMS的servlet。
BashMS
msUtils.ASPTranslator
BashMS
/*.asp
3.3 命名JSP页面
因为JSP页面要转换成sevlet，自然希望就像命名servlet一样命名JSP页面。毕竟，JSP页面可能会从初始化参数、安全设置或定制的URL中受益，正如普通的serlvet那样。虽然JSP页面的后台实际上是servlet这句话是正确的，但存在一个关键的猜疑：即，你不知道JSP页面的实际类名（因为系统自己挑选这个名字）。因此，为了命名JSP页面，可将jsp-file元素替换为servlet-calss元素，如下所示：
Test
/TestPage.jsp
命名JSP页面的原因与命名servlet的原因完全相同：即为了提供一个与定制设置（如，初始化参数和安全设置）一起使用的名称，并且，以便能更改激活 JSP页面的URL（比方说，以便多个URL通过相同页面得以处理，或者从URL中去掉.jsp扩展名）。但是，在设置初始化参数时，应该注意，JSP页面是利用jspInit方法，而不是init方法读取初始化参数的。
例如，程序清单5-3给出一个名为TestPage.jsp的简单JSP页面，它的工作只是打印出用来激活它的URL的本地部分。TestPage.jsp放置在deployDemo应用的顶层。程序清单5-4给出了用来分配一个注册名PageName，然后将此注册名与
http://host/webAppPrefix/UrlTest2/anything 形式的URL相关联的web.xml文件（即，deployDemo/WEB-INF/web.xml）的一部分。
程序清单5-3 TestPage.jsp
URI: <%= request.getRequestURI() %>
程序清单5-4 web.xml（说明JSP页命名的摘录）
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"
http://java.sun.com/dtd/web-app_2_3.dtd">
PageName
/TestPage.jsp
PageName
/UrlTest2/*
4 禁止激活器servlet
对servlet 或JSP页面建立定制URL的一个原因是，这样做可以注册从 init（servlet）或jspInit（JSP页面）方法中读取得初始化参数。但是，初始化参数只在是利用定制URL模式或注册名访问 servlet或JSP页面时可以使用，用缺省URL
http://host/webAppPrefix/servlet/ServletName 访问时不能使用。因此，你可能会希望关闭缺省URL，这样就不会有人意外地调用初始化servlet了。这个过程有时称为禁止激活器servlet，因为多数服务器具有一个用缺省的servlet URL注册的标准servlet，并激活缺省的URL应用的实际servlet。
有两种禁止此缺省URL的主要方法：
l 在每个Web应用中重新映射/servlet/模式。
l 全局关闭激活器servlet。
重要的是应该注意到，虽然重新映射每个Web应用中的/servlet/模式比彻底禁止激活servlet所做的工作更多，但重新映射可以用一种完全可移植的方式来完成。相反，全局禁止激活器servlet完全是针对具体机器的，事实上有的服务器（如ServletExec）没有这样的选择。下面的讨论对每个Web应用重新映射/servlet/ URL模式的策略。后面提供在Tomcat中全局禁止激活器servlet的详细内容。
4.1 重新映射/servlet/URL模式
在一个特定的Web应用中禁止以
http://host/webAppPrefix/servlet/ 开始的URL的处理非常简单。所需做的事情就是建立一个错误消息servlet，并使用前一节讨论的url-pattern元素将所有匹配请求转向该 servlet。只要简单地使用：
/servlet/*作为servlet-mapping元素中的模式即可。
例如，程序清单5-5给出了将SorryServlet servlet（程序清单5-6）与所有以
http://host/webAppPrefix/servlet/ 开头的URL相关联的部署描述符文件的一部分。
程序清单5-5 web.xml（说明JSP页命名的摘录）
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"
http://java.sun.com/dtd/web-app_2_3.dtd">
Sorry
moreservlets.SorryServlet
Sorry
/servlet/*
程序清单5-6 SorryServlet.java
package moreservlets;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Simple servlet used to give error messages to
* users who try to access default servlet URLs
* (i.e.,
http://host/webAppPrefix/servlet/ServletName)* in Web applications that have disabled this
* behavior.
*
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class SorryServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String title = "Invoker Servlet Disabled.";
out.println(ServletUtilities.headWithTitle(title) +
"\n" +
"
" + title + "
\n" +
"Sorry, access to servlets by means of\n" +
"URLs that begin with\n" +
"
http://host/webAppPrefix/servlet/\n" +
"has been disabled.\n" +
"");
}
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
doGet(request, response);
}
}
4.2 全局禁止激活器：Tomcat
Tomcat 4中用来关闭缺省URL的方法与Tomcat 3中所用的很不相同。下面介绍这两种方法：
1．禁止激活器： Tomcat 4
Tomcat 4用与前面相同的方法关闭激活器servlet，即利用web.xml中的url-mapping元素进行关闭。不同之处在于Tomcat使用了放在 install_dir/conf中的一个服务器专用的全局web.xml文件，而前面使用的是存放在每个Web应用的WEB-INF目录中的标准 web.xml文件。
因此，为了在Tomcat 4中关闭激活器servlet，只需在install_dir/conf/web.xml中简单地注释出/servlet/* URL映射项即可，如下所示：
再次提醒，应该注意这个项是位于存放在install_dir/conf的Tomcat专用的web.xml文件中的，此文件不是存放在每个Web应用的WEB-INF目录中的标准web.xml。
2．禁止激活器：Tomcat3
在Apache Tomcat的版本3中，通过在install_dir/conf/server.xml中注释出InvokerInterceptor项全局禁止缺省 servlet URL。例如，下面是禁止使用缺省servlet URL的server.xml文件的一部分。
5 初始化和预装载servlet与JSP页面
这里讨论控制servlet和JSP页面的启动行为的方法。特别是，说明了怎样分配初始化参数以及怎样更改服务器生存期中装载servlet和JSP页面的时刻。
5.1 分配servlet初始化参数
利用init-param元素向servlet提供初始化参数，init-param元素具有param-name和param-value子元素。例如，在下面的例子中，如果initServlet servlet是利用它的注册名（InitTest）访问的，它将能够从其方法中调用getServletConfig(). getInitParameter("param1")获得"Value 1"，调用getServletConfig().getInitParameter("param2")获得"2"。
InitTest
moreservlets.InitServlet
param1
value1
param2
2
在涉及初始化参数时，有几点需要注意：
l 返回值。GetInitParameter的返回值总是一个String。因此，在前一个例子中，可对param2使用Integer.parseInt获得一个int。
l JSP中的初始化。JSP页面使用jspInit而不是init。JSP页面还需要使用jsp-file元素代替servlet-class。
l 缺省URL。初始化参数只在通过它们的注册名或与它们注册名相关的定制URL模式访问Servlet时可以使用。因此，在这个例子中，param1和 param2初始化参数将能够在使用URL
http://host/webAppPrefix/servlet/InitTest 时可用，但在使用URL
http://host/webAppPrefix/servlet/myPackage.InitServlet 时不能使用。
例如，程序清单5-7给出一个名为InitServlet的简单servlet，它使用init方法设置firstName和emailAddress字段。程序清单5-8给出分配名称InitTest给servlet的web.xml文件。
程序清单5-7 InitServlet.java
package moreservlets;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Simple servlet used to illustrate servlet
* initialization parameters.
*
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class InitServlet extends HttpServlet {
private String firstName, emailAddress;
public void init() {
ServletConfig config = getServletConfig();
firstName = config.getInitParameter("firstName");
emailAddress = config.getInitParameter("emailAddress");
}
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String uri = request.getRequestURI();
out.println(ServletUtilities.headWithTitle("Init Servlet") +
"\n" +
"
Init Parameters:
\n" +
"
\n" +
"
- First name: " + firstName + "\n" +
"
- Email address: " + emailAddress + "\n" +
"
\n" +
"");
}
}
程序清单5-8 web.xml（说明初始化参数的摘录）
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"
http://java.sun.com/dtd/web-app_2_3.dtd">
InitTest
moreservlets.InitServlet
firstName
Larry
emailAddress
Ellison@Microsoft.com
5.2 分配JSP初始化参数
给JSP页面提供初始化参数在三个方面不同于给servlet提供初始化参数。
1）使用jsp-file而不是servlet-class。因此，WEB-INF/web.xml文件的servlet元素如下所示：
PageName
/RealPage.jsp
...
...
...
2) 几乎总是分配一个明确的URL模式。对servlet，一般相应地使用以
http://host/webAppPrefix/servlet/ 开始的缺省URL。只需记住，使用注册名而不是原名称即可。这对于JSP页面在技术上也是合法的。例如，在上面给出的例子中，可用URL
http://host/webAppPrefix/servlet/PageName 访问RealPage.jsp的对初始化参数具有访问权的版本。但在用于JSP页面时，许多用户似乎不喜欢应用常规的servlet的URL。此外，如果 JSP页面位于服务器为其提供了目录清单的目录中（如，一个既没有index.html也没有index.jsp文件的目录），则用户可能会连接到此 JSP页面，单击它，从而意外地激活未初始化的页面。因此，好的办法是使用url-pattern（5.3节）将JSP页面的原URL与注册的 servlet名相关联。这样，客户机可使用JSP页面的普通名称，但仍然激活定制的版本。例如，给定来自项目1的servlet定义，可使用下面的 servlet-mapping定义：
PageName
/RealPage.jsp
3）JSP页使用jspInit而不是init。自动从JSP页面建立的servlet或许已经使用了inti方法。因此，使用JSP声明提供一个init方法是不合法的，必须制定jspInit方法。
为了说明初始化JSP页面的过程，程序清单5-9给出了一个名为InitPage.jsp的JSP页面，它包含一个jspInit方法且放置于 deployDemo Web应用层次结构的顶层。一般，
http://host/deployDemo/InitPage.jsp 形式的URL将激活此页面的不具有初始化参数访问权的版本，从而将对firstName和emailAddress变量显示null。但是， web.xml文件（程序清单5-10）分配了一个注册名，然后将该注册名与URL模式/InitPage.jsp相关联。
程序清单5-9 InitPage.jsp
Init Parameters:
- First name: <%= firstName %>
- Email address: <%= emailAddress %>
<%!
private String firstName, emailAddress;
public void jspInit() {
ServletConfig config = getServletConfig();
firstName = config.getInitParameter("firstName");
emailAddress = config.getInitParameter("emailAddress");
}
%>
程序清单5-10 web.xml（说明JSP页面的init参数的摘录）
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"
http://java.sun.com/dtd/web-app_2_3.dtd">
InitPage
/InitPage.jsp
firstName
Bill
emailAddress
gates@oracle.com
InitPage
/InitPage.jsp
5.3 提供应用范围内的初始化参数
一般，对单个地servlet或JSP页面分配初始化参数。指定的servlet或JSP页面利用ServletConfig的 getInitParameter方法读取这些参数。但是，在某些情形下，希望提供可由任意servlet或JSP页面借助ServletContext 的getInitParameter方法读取的系统范围内的初始化参数。
可利用context-param元素声明这些系统范围内的初始化值。context-param元素应该包含param-name、param-value以及可选的description子元素，如下所示：
support-email
blackhole@mycompany.com
可回忆一下，为了保证可移植性，web.xml内的元素必须以正确的次序声明。但这里应该注意，context-param元素必须出现任意与文档有关的元素（icon、display-name或description）之后及filter、filter-mapping、listener或 servlet元素之前。
5.4 在服务器启动时装载servlet
假如servlet或JSP页面有一个要花很长时间执行的init （servlet）或jspInit（JSP）方法。例如，假如init或jspInit方法从某个数据库或ResourceBundle查找产量。这种情况下，在第一个客户机请求时装载servlet的缺省行为将对第一个客户机产生较长时间的延迟。因此，可利用servlet的load-on- startup元素规定服务器在第一次启动时装载servlet。下面是一个例子。
…
…
可以为此元素体提供一个整数而不是使用一个空的load-on-startup。想法是服务器应该在装载较大数目的servlet或JSP页面之前装载较少数目的servlet或JSP页面。例如，下面的servlet项（放置在Web应用的WEB-INF目录下的web.xml文件中的web-app元素内）将指示服务器首先装载和初始化SearchServlet，然后装载和初始化由位于Web应用的result目录中的index.jsp文件产生的 servlet。
Search
myPackage.SearchServlet
1
Results
/results/index.jsp
2
6 声明过滤器
servlet版本2.3引入了过滤器的概念。虽然所有支持servlet API版本2.3的服务器都支持过滤器，但为了使用与过滤器有关的元素，必须在web.xml中使用版本2.3的DTD。
过滤器可截取和修改进入一个servlet或JSP页面的请求或从一个servlet或JSP页面发出的相应。在执行一个servlet或JSP页面之前，必须执行第一个相关的过滤器的doFilter方法。在该过滤器对其FilterChain对象调用doFilter时，执行链中的下一个过滤器。如果没有其他过滤器，servlet或JSP页面被执行。过滤器具有对到来的ServletRequest对象的全部访问权，因此，它们可以查看客户机名、查找到来的cookie等。为了访问servlet或JSP页面的输出，过滤器可将响应对象包裹在一个替身对象（stand-in object）中，比方说把输出累加到一个缓冲区。在调用FilterChain对象的doFilter方法之后，过滤器可检查缓冲区，如有必要，就对它进行修改，然后传送到客户机。
例如，程序清单5-11帝国难以了一个简单的过滤器，只要访问相关的servlet或JSP页面，它就截取请求并在标准输出上打印一个报告（开发过程中在桌面系统上运行时，大多数服务器都可以使用这个过滤器）。
程序清单5-11 ReportFilter.java
package moreservlets;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;
/** Simple filter that prints a report on the standard output
* whenever the associated servlet or JSP page is accessed.
*
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class ReportFilter implements Filter {
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws ServletException, IOException {
HttpServletRequest req = (HttpServletRequest)request;
System.out.println(req.getRemoteHost() +
" tried to access " +
req.getRequestURL() +
" on " + new Date() + ".");
chain.doFilter(request,response);
}
public void init(FilterConfig config)
throws ServletException {
}
public void destroy() {}
}
一旦建立了一个过滤器，可以在web.xml中利用filter元素以及filter-name（任意名称）、file-class（完全限定的类名）和（可选的）init-params子元素声明它。请注意，元素在web.xml的web-app元素中出现的次序不是任意的；允许服务器（但不是必需的）强制所需的次序，并且实际中有些服务器也是这样做的。但这里要注意，所有filter元素必须出现在任意filter-mapping元素之前， filter-mapping元素又必须出现在所有servlet或servlet-mapping元素之前。
例如，给定上述的ReportFilter类，可在web.xml中作出下面的filter声明。它把名称Reporter与实际的类ReportFilter（位于moreservlets程序包中）相关联。
Reporter
moresevlets.ReportFilter
一旦命名了一个过滤器，可利用filter-mapping元素把它与一个或多个servlet或JSP页面相关联。关于此项工作有两种选择。
首先，可使用filter-name和servlet-name子元素把此过滤器与一个特定的servlet名（此servlet名必须稍后在相同的 web.xml文件中使用servlet元素声明）关联。例如，下面的程序片断指示系统只要利用一个定制的URL访问名为SomeServletName 的servlet或JSP页面，就运行名为Reporter的过滤器。
Reporter
SomeServletName
其次，可利用filter-name和url-pattern子元素将过滤器与一组servlet、JSP页面或静态内容相关联。例如，相面的程序片段指示系统只要访问Web应用中的任意URL，就运行名为Reporter的过滤器。
Reporter
/*
例如，程序清单5-12给出了将ReportFilter过滤器与名为PageName的servlet相关联的web.xml文件的一部分。名字 PageName依次又与一个名为TestPage.jsp的JSP页面以及以模式http: //host/webAppPrefix/UrlTest2/ 开头的URL相关联。TestPage.jsp的源代码已经JSP页面命名的谈论在前面的3节"分配名称和定制的URL"中给出。事实上，程序清单5- 12中的servlet和servlet-name项从该节原封不动地拿过来的。给定这些web.xml项，可看到下面的标准输出形式的调试报告（换行是为了容易阅读）。
audit.irs.gov tried to access
http://mycompany.com/deployDemo/UrlTest2/business/tax-plan.html
on Tue Dec 25 13:12:29 EDT 2001.
程序清单5-12 Web.xml（说明filter用法的摘录）
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
Reporter
moresevlets.ReportFilter
Reporter
PageName
PageName
/RealPage.jsp
PageName
/UrlTest2/*
7 指定欢迎页
假如用户提供了一个像http: //host/webAppPrefix/directoryName/ 这样的包含一个目录名但没有包含文件名的URL，会发生什么事情呢？用户能得到一个目录表？一个错误？还是标准文件的内容？如果得到标准文件内容，是 index.html、index.jsp、default.html、default.htm或别的什么东西呢？
Welcome-file-list 元素及其辅助的welcome-file元素解决了这个模糊的问题。例如，下面的web.xml项指出，如果一个URL给出一个目录名但未给出文件名，服务器应该首先试用index.jsp，然后再试用index.html。如果两者都没有找到，则结果有赖于所用的服务器（如一个目录列表）。
index.jsp
index.html
虽然许多服务器缺省遵循这种行为，但不一定必须这样。因此，明确地使用welcom-file-list保证可移植性是一种良好的习惯。
8 指定处理错误的页面
现在我了解到，你在开发servlet和JSP页面时从不会犯错误，而且你的所有页面是那样的清晰，一般的程序员都不会被它们的搞糊涂。但是，是人总会犯错误的，用户可能会提供不合规定的参数，使用不正确的URL或者不能提供必需的表单字段值。除此之外，其它开发人员可能不那么细心，他们应该有些工具来克服自己的不足。
error-page元素就是用来克服这些问题的。它有两个可能的子元素，分别是：error-code和exception- type。第一个子元素error-code指出在给定的HTTP错误代码出现时使用的URL。第二个子元素excpetion-type指出在出现某个给定的Java异常但未捕捉到时使用的URL。error-code和exception-type都利用location元素指出相应的URL。此 URL必须以/开始。location所指出的位置处的页面可通过查找HttpServletRequest对象的两个专门的属性来访问关于错误的信息，这两个属性分别是：javax.servlet.error.status_code和javax.servlet.error.message。
可回忆一下，在web.xml内以正确的次序声明web-app的子元素很重要。这里只要记住，error-page出现在web.xml文件的末尾附近，servlet、servlet-name和welcome-file-list之后即可。
8.1 error-code元素
为了更好地了解error-code元素的值，可考虑一下如果不正确地输入文件名，大多数站点会作出什么反映。这样做一般会出现一个404错误信息，它表示不能找到该文件，但几乎没提供更多有用的信息。另一方面，可以试一下在www.microsoft.com、www.ibm.com 处或者特别是在www.bea.com 处输出未知的文件名。这是会得出有用的消息，这些消息提供可选择的位置，以便查找感兴趣的页面。提供这样有用的错误页面对于Web应用来说是很有价值得。事实上rm-error-page子元素）。由form-login-page给出的HTML表单必须具有一个j_security_check的 ACTION属性、一个名为j_username的用户名文本字段以及一个名为j_password的口令字段。
例如，程序清单5-19指示服务器使用基于表单的验证。Web应用的顶层目录中的一个名为login.jsp的页面将收集用户名和口令，并且失败的登陆将由相同目录中名为login-error.jsp的页面报告。
程序清单5-19 web.xml（说明login-config的摘录）
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
...
FORM
/login.jsp
/login-error.jsp
9.2 限制对Web资源的访问
现在，可以指示服务器使用何种验证方法了。"了不起，"你说道，"除非我能指定一个来收到保护的 URL，否则没有多大用处。"没错。指出这些URL并说明他们应该得到何种保护正是security-constriaint元素的用途。此元素在 web.xml中应该出现在login-config的紧前面。它包含是个可能的子元素，分别是：web-resource-collection、 auth-constraint、user-data-constraint和display-name。下面各小节对它们进行介绍。
l web-resource-collection
此元素确定应该保护的资源。所有security-constraint元素都必须包含至少一个web-resource-collection项。此元素由一个给出任意标识名称的web-resource-name元素、一个确定应该保护的URL的url-pattern元素、一个指出此保护所适用的 HTTP命令（GET、POST等，缺省为所有方法）的http-method元素和一个提供资料的可选description元素组成。例如，下面的 Web-resource-collection项（在security-constratint元素内）指出Web应用的proprietary目录中所有文档应该受到保护。
Proprietary
/propritary/*
重要的是应该注意到，url-pattern仅适用于直接访问这些资源的客户机。特别是，它不适合于通过MVC体系结构利用 RequestDispatcher来访问的页面，或者不适合于利用类似jsp:forward的手段来访问的页面。这种不匀称如果利用得当的话很有好处。例如，servlet可利用MVC体系结构查找数据，把它放到bean中，发送请求到从bean中提取数据的JSP页面并显示它。我们希望保证决不直接访问受保护的JSP页面，而只是通过建立该页面将使用的bean的servlet来访问它。url-pattern和auth-contraint元素可通过声明不允许任何用户直接访问JSP页面来提供这种保证。但是，这种不匀称的行为可能让开发人员放松警惕，使他们偶然对应受保护的资源提供不受限制的访问。
l auth-constraint
尽管web-resource-collention元素质出了哪些URL应该受到保护，但是auth-constraint元素却指出哪些用户应该具有受保护资源的访问权。此元素应该包含一个或多个标识具有访问权限的用户类别role- name元素，以及包含（可选）一个描述角色的description元素。例如，下面web.xml中的security-constraint元素部门规定只有指定为Administrator或Big Kahuna（或两者）的用户具有指定资源的访问权。
...
administrator
kahuna
重要的是认识到，到此为止，这个过程的可移植部分结束了。服务器怎样确定哪些用户处于任何角色以及它怎样存放用户的口令，完全有赖于具体的系统。
例如，Tomcat使用install_dir/conf/tomcat-users.xml将用户名与角色名和口令相关联，正如下面例子中所示，它指出用户joe（口令bigshot）和jane（口令enaj）属于administrator和kahuna角色。
l user-data-constraint
这个可选的元素指出在访问相关资源时使用任何传输层保护。它必须包含一个transport-guarantee子元素（合法值为NONE、 INTEGRAL或CONFIDENTIAL），并且可选地包含一个description元素。transport-guarantee为NONE值将对所用的通讯协议不加限制。INTEGRAL值表示数据必须以一种防止截取它的人阅读它的方式传送。虽然原理上（并且在未来的HTTP版本中），在 INTEGRAL和CONFIDENTIAL之间可能会有差别，但在当前实践中，他们都只是简单地要求用SSL。例如，下面指示服务器只允许对相关资源做 HTTPS连接：
CONFIDENTIAL
l display-name
security-constraint的这个很少使用的子元素给予可能由GUI工具使用的安全约束项一个名称。
9.3 分配角色名
迄今为止，讨论已经集中到完全由容器（服务器）处理的安全问题之上了。但servlet以及JSP页面也能够处理它们自己的安全问题。
例如，容器可能允许用户从bigwig或bigcheese角色访问一个显示主管人员额外紧贴的页面，但只允许bigwig用户修改此页面的参数。完成这种更细致的控制的一种常见方法是调用HttpServletRequset的isUserInRole方法，并据此修改访问。
Servlet的 security-role-ref子元素提供出现在服务器专用口令文件中的安全角色名的一个别名。例如，假如编写了一个调用 request.isUserInRole（"boss"）的servlet，但后来该servlet被用在了一个其口令文件调用角色manager而不是boss的服务器中。下面的程序段使该servlet能够使用这两个名称中的任何一个。
boss
manager
也可以在web-app内利用security-role元素提供将出现在role-name元素中的所有安全角色的一个全局列表。分别地生命角色使高级IDE容易处理安全信息。
10 控制会话超时
如果某个会话在一定的时间内未被访问，服务器可把它扔掉以节约内存。可利用HttpSession的setMaxInactiveInterval方法直接设置个别会话对象的超时值。如果不采用这种方法，则缺省的超时值由具体的服务器决定。但可利用session-config和session- timeout元素来给出一个适用于所有服务器的明确的超时值。超时值的单位为分钟，因此，下面的例子设置缺省会话超时值为三个小时（180分钟）。
180
11 Web应用的文档化
越来越多的开发环境开始提供servlet和JSP的直接支持。例子有Borland Jbuilder Enterprise Edition、Macromedia UltraDev、Allaire JRun Studio（写此文时，已被Macromedia收购）以及IBM VisuaAge for Java等。
大量的web.xml元素不仅是为服务器设计的，而且还是为可视开发环境设计的。它们包括icon、display-name和discription等。
可回忆一下，在web.xml内以适当地次序声明web-app子元素很重要。不过，这里只要记住icon、display-name和description是web.xml的web-app元素内的前三个合法元素即可。
l icon
icon元素指出GUI工具可用来代表Web应用的一个和两个图像文件。可利用small-icon元素指定一幅16 x 16的GIF或JPEG图像，用large-icon元素指定一幅32 x 32的图像。下面举一个例子：
/images/small-book.gif
/images/tome.jpg
l display-name
display-name元素提供GUI工具可能会用来标记此Web应用的一个名称。下面是个例子。
Rare Books
l description
description元素提供解释性文本，如下所示：
This Web application represents the store developed for
rare-books.com, an online bookstore specializing in rare
and limited-edition books.
12 关联文件与MIME类型
服务器一般都具有一种让Web站点管理员将文件扩展名与媒体相关联的方法。例如，将会自动给予名为mom.jpg的文件一个image/jpeg的MIME 类型。但是，假如你的Web应用具有几个不寻常的文件，你希望保证它们在发送到客户机时分配为某种MIME类型。mime-mapping元素（具有 extension和mime-type子元素）可提供这种保证。例如，下面的代码指示服务器将application/x-fubar的MIME类型分配给所有以.foo结尾的文件。
foo
application/x-fubar
或许，你的Web应用希望重载（override）标准的映射。例如，下面的代码将告诉服务器在发送到客户机时指定.ps文件作为纯文本（text/plain）而不是作为PostScript（application/postscript）。
ps
application/postscript
13 定位TLD
JSP taglib元素具有一个必要的uri属性，它给出一个TLD（Tag Library Descriptor）文件相对于Web应用的根的位置。TLD文件的实际名称在发布新的标签库版本时可能会改变，但我们希望避免更改所有现有JSP页面。此外，可能还希望使用保持taglib元素的简练性的一个简短的uri。这就是部署描述符文件的taglib元素派用场的所在了。Taglib包含两个子元素：taglib-uri和taglib-location。taglib-uri元素应该与用于JSP taglib元素的uri属性的东西相匹配。Taglib-location元素给出TLD文件的实际位置。例如，假如你将文件chart-tags- 1.3beta.tld放在WebApp/WEB-INF/tlds中。现在，假如web.xml在web-app元素内包含下列内容。
/charts.tld
/WEB-INF/tlds/chart-tags-1.3beta.tld
给出这个说明后，JSP页面可通过下面的简化形式使用标签库。
<%@ taglib uri="/charts.tld" prefix="somePrefix" %>
14 指定应用事件监听程序
应用事件监听器程序是建立或修改servlet环境或会话对象时通知的类。它们是servlet规范的版本2.3中的新内容。这里只简单地说明用来向Web应用注册一个监听程序的web.xml的用法。
注册一个监听程序涉及在web.xml的web-app元素内放置一个listener元素。在listener元素内，listener-class元素列出监听程序的完整的限定类名，如下所示：
package.ListenerClass
虽然listener元素的结构很简单，但请不要忘记，必须正确地给出web-app元素内的子元素的次序。listener元素位于所有的servlet 元素之前以及所有filter-mapping元素之后。此外，因为应用生存期监听程序是serlvet规范的2.3版本中的新内容，所以必须使用 web.xml DTD的2.3版本，而不是2.2版本。
例如，程序清单5-20给出一个名为ContextReporter的简单的监听程序，只要Web应用的Servlet-Context建立（如装载Web应用）或消除（如服务器关闭）时，它就在标准输出上显示一条消息。程序清单5-21给出此监听程序注册所需要的web.xml文件的一部分。
程序清单5-20 ContextReporterjava
package moreservlets;
import javax.servlet.*;
import java.util.*;
/** Simple listener that prints a report on the standard output
* when the ServletContext is created or destroyed.
*
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class ContextReporter implements ServletContextListener {
public void contextInitialized(ServletContextEvent event) {
System.out.println("Context created on " +
new Date() + ".");
}
public void contextDestroyed(ServletContextEvent event) {
System.out.println("Context destroyed on " +
new Date() + ".");
}
}
程序清单5-21 web.xml（声明一个监听程序的摘录）
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
…
package.ListenerClass
...
15 J2EE元素
本节描述用作J2EE环境组成部分的Web应用的web.xml元素。这里将提供一个简明的介绍，详细内容可以参阅http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf的Java 2 Plantform Enterprise Edition版本1.3规范的第5章。
l distributable
distributable 元素指出，Web应用是以这样的方式编程的：即，支持集群的服务器可安全地在多个服务器上分布Web应用。例如，一个可分布的应用必须只使用 Serializable对象作为其HttpSession对象的属性，而且必须避免用实例变量（字段）来实现持续性。distributable元素直接出现在discription元素之后，并且不包含子元素或数据，它只是一个如下的标志。
l resource-env-ref
resource -env-ref元素声明一个与某个资源有关的管理对象。此元素由一个可选的description元素、一个resource-env-ref- name元素（一个相对于java:comp/env环境的JNDI名）以及一个resource-env-type元素（指定资源类型的完全限定的类），如下所示：
jms/StockQueue
javax.jms.Queue
l env-entry
env -entry元素声明Web应用的环境项。它由一个可选的description元素、一个env-entry-name元素（一个相对于java: comp/env环境JNDI名）、一个env-entry-value元素（项值）以及一个env-entry-type元素（java.lang程序包中一个类型的完全限定类名，java.lang.Boolean、java.lang.String等）组成。下面是一个例子：
minAmout
100.00
minAmout
l ejb-ref
ejb -ref元素声明对一个EJB的主目录的应用。它由一个可选的description元素、一个ejb-ref-name元素（相对于java: comp/env的EJB应用）、一个ejb-ref-type元素（bean的类型，Entity或Session）、一个home元素（bean的主目录接口的完全限定名）、一个remote元素（bean的远程接口的完全限定名）以及一个可选的ejb-link元素（当前bean链接的另一个 bean的名称）组成。
l ejb-local-ref
ejb-local-ref元素声明一个EJB的本地主目录的引用。除了用local-home代替home外，此元素具有与ejb-ref元素相同的属性并以相同的方式使用。
很多的时侯，做Oracle DBA的我们，当应用管理员向我们通告现在应用很慢、数据库很慢的时侯，我们到数据库时做几个示例的Select也发现同样的问题时，有些时侯我们会无从下手，因为我们认为数据库的各种命种率都是满足Oracle文档的建议。实际上如今的优化己经向优化等待(waits)转型了，实际中性能优化最根本的出现点也都集中在IO，这是影响性能最主要的方面，由系统中的等待去发现Oracle库中的不足、操作系统某些资源利用的不合理是一个比较好的办法，下面把我的一点实践经验与大家分享一下，本文测重于Unix环境。
一、通过操作系统的一些工具检查系统的状态，比如CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲这也可能不是一个正常的状态，因为cpu可能正等待IO的完成。除此之外我们还应观注那些占用系统资源(cpu、内存)的进程。
1、如何检查操作系统是否存在IO的问题？使用的工具有sar,这是一个比较通用的工具。
Rp1#Sar -u 2 10
即每隔2秒检察一次，共执行20次，当然这些都由你决定了。
示例返回：
HP-UX hpn2 B.11.00 U 9000/800 08/05/03
18:26:32 %usr %sys %wio %idle
18:26:34 80 9 12 0
18:26:36 78 11 11 0
18:26:38 78 9 13 1
18:26:40 81 10 9 1
18:26:42 75 10 14 0
18:26:44 76 8 15 0
18:26:46 80 9 10 1
18:26:48 78 11 11 0
18:26:50 79 10 10 0
18:26:52 81 10 9 0
Average 79 10 11 0
其中的%usr指的是用户进程使用的cpu资源的百分比，%sys指的是系统资源使用cpu资源的百分比，%wio指的是等待io完成的百分比，这是值得我们观注的一项，%idle即空闲的百分比。如果wio列的值很大，如在35%以上，说明你的系统的IO存在瓶颈，你的CPU花费了很大的时间去等待IO的完成。Idle很小说明系统CPU很忙。像我的这个示例，可以看到wio平均值为11说明io没什么特别的问题，而我的idle值为零，说明我的cpu已经满负荷运行了。
当你的系统存在IO的问题，可以从以下几个方面解决
＊联系相应的操作系统的技术支持对这方面进行优化，比如hp-ux在划定卷组时的条带化等方面。
＊查找Oracle中不合理的sql语句，对其进行优化
＊对Oracle中访问量频繁的表除合理建索引外，再就是把这些表分表空间存放以免访问上产生热点，再有就是对表合理分区。
2、关注一下内存。
常用的工具便是vmstat，对于hp-unix来说可以用glance,Aix来说可以用topas,当你发现vmstat中pi列非零，memory中的free列的值很小，glance,topas中内存的利用率多于80%时，这时说明你的内存方面应该调节一下了，方法大体有以下几项。
＊划给Oracle使用的内存不要超过系统内存的1/2,一般保在系统内存的40%为益。
为系统增加内存
＊如果你的连接特别多，可以使用MTS的方式
＊打全补丁，防止内存漏洞。
3、如何找到点用系用资源特别大的Oracle的session及其执行的语句。
Hp-unix可以用glance,top
IBM AIX可以用topas
此外可以使用ps的命令。
通过这些程序我们可以找到点用系统资源特别大的这些进程的进程号，我们就可以通过以下的sql语句发现这个pid正在执行哪个sql，这个sql最好在pl/sql developer,toad等软件中执行, 把<>中的spid换成你的spid就可以了。
SELECT a.username,
a.machine,
a.program,
a.sid,
a.serial#,
a.status,
c.piece,
c.sql_text
FROM v$session a,
v$process b,
v$sqltext c
WHERE b.spid=
AND b.addr=a.paddr
AND a.sql_address=c.address(+)
ORDER BY c.piece
我们就可以把得到的这个sql分析一下，看一下它的执行计划是否走索引，对其优化避免全表扫描，以减少IO等待，从而加快语句的执行速度。
提示：我在做优化sql时，经常碰到使用in的语句，这时我们一定要用exists把它给换掉，因为Oracle在处理In时是按Or的方式做的，即使使用了索引也会很慢。
比如：
SELECT col1,col2,col3 FROM table1 a
WHERE a.col1 not in (SELECT col1 FROM table2)
可以换成：
SELECT col1,col2,col3 FROM table1 a
WHERE not exists
(SELECT 'x' FROM table2 b
WHERE a.col1=b.col1)
4、另一个有用的脚本：查找前十条性能差的sql.
SELECT * FROM
(
SELECT PARSING_USER_ID
EXECUTIONS,
SORTS,
COMMAND_TYPE,
DISK_READS,
sql_text
FROM v$sqlarea
ORDER BY disk_reads DESC
)
WHERE ROWNUM<10 ;
二、迅速发现Oracle Server的性能问题的成因，我们可以求助于v$session_wait这个视图，看系统的这些session在等什么，使用了多少的IO。以下是我提供的参考脚本：
脚本说明：查看占io较大的正在运行的session
SELECT se.sid,
se.serial#,
pr.SPID,
se.username,
se.status,
se.terminal,
se.program,
se.MODULE,
se.sql_address,
st.event,
st.p1text,
si.physical_reads,
si.block_changes
FROM v$session se,
v$session_wait st,
v$sess_io si,
v$process pr
WHERE st.sid=se.sid
AND st.sid=si.sid
AND se.PADDR=pr.ADDR
AND se.sid>6
AND st.wait_time=0
AND st.event NOT LIKE '%SQL%'
ORDER BY physical_reads DESC
对检索出的结果的几点说明：
1、我是按每个正在等待的session已经发生的物理读排的序，因为它与实际的IO相关。
2、你可以看一下这些等待的进程都在忙什么，语句是否合理？
Select sql_address from v$session where sid= ;
Select * from v$sqltext where address= ;
执行以上两个语句便可以得到这个session的语句。
你也以用alter system kill session 'sid,serial#';把这个session杀掉。
3、应观注一下event这列，这是我们调优的关键一列，下面对常出现的event做以简要的说明：
a、buffer busy waits，free buffer waits这两个参数所标识是dbwr是否够用的问题，与IO很大相关的，当v$session_wait中的free buffer wait的条目很小或没有的时侯，说明你的系统的dbwr进程决对够用，不用调整；free buffer wait的条目很多，你的系统感觉起来一定很慢，这时说明你的dbwr已经不够用了，它产生的wio已经成为你的数据库性能的瓶颈，这时的解决办法如下：
a.1增加写进程，同时要调整db_block_lru_latches参数
示例：修改或添加如下两个参数
db_writer_processes=4
db_block_lru_latches=8
a、2开异步IO，IBM这方面简单得多，hp则麻烦一些，可以与Hp工程师联系。
b、db file sequential read，指的是顺序读，即全表扫描，这也是我们应该尽量减少的部分，解决方法就是使用索引、sql调优，同时可以增大db_file_multiblock_read_count这个参数。
c、db file scattered read,这个参数指的是通过索引来读取，同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。
d、latch free,与栓相关的了，需要专门调节。
e、其他参数可以不特别观注。
结篇：匆忙之中写下了这篇文章，希望能抛砖引玉，能为你的Oracle调优实践带来帮助。
任何事情都有它的源头，要解决问题，也得从源头开始，影响ORACLE性能的源头非常多，主要包括如下方面：
数据库的硬件配置：CPU、内存、网络条件
1. CPU：在任何机器中CPU的数据处理能力往往是衡量计算机性能的一个标志，并且ORACLE是一个提供并行能力的数据库系统，在CPU方面的要求就更高了，如果运行队列数目超过了CPU处理的数目，性能就会下降，我们要解决的问题就是要适当增加CPU的数量了，当然我们还可以将需要许多资源的进程KILL掉；
2. 内存：衡量机器性能的另外一个指标就是内存的多少了，在ORACLE中内存和我们在建数据库中的交换区进行数据的交换，读数据时，磁盘I/O必须等待物理I/O操作完成，在出现ORACLE的内存瓶颈时，我们第一个要考虑的是增加内存，由于I/O的响应时间是影响ORACLE性能的主要参数，我将在这方面进行详细的讲解
3. 网络条件：NET*SQL负责数据在网络上的来往，大量的SQL会令网络速度变慢。比如10M的网卡和100的网卡就对NET*SQL有非常明显的影响，还有交换机、集线器等等网络设备的性能对网络的影响很明显，建议在任何网络中不要试图用3个集线器来将网段互联。
Ø OS参数的设置
下表给出了OS的参数设置及说明，DBA可以根据实际需要对这些参数进行设置
|
内核参数名 |
说明 |
|
bufpages |
对buffer空间不按静态分配，采用动态分配，使bufpages值随nbuf一起对buffer空间进行动态分配。 |
|
create_fastlinks |
对HFS文件系统允许快速符号链接， |
|
dbc_max_pct |
加大最大动态buffer空间所占物理内存的百分比，以满足应用系统的读写命中率的需要。 |
|
dbc_min_pct |
设置最小动态buffer空间所占物理内存的百分比 |
|
desfree |
提高开始交换操作的最低空闲内存下限，保障系统的稳定性，防止出现不可预见的系统崩溃（Crash）。 |
|
fs_async |
允许进行磁盘异步操作，提高CPU和磁盘的利用率 |
|
lotsfree |
提高系统解除换页操作的空闲内存的上限值，保证应用程序有足够的可用内存空间。 |
|
maxdsiz |
针对系统数据量大的特点，加大最大数据段的大小，保证应用的需要。（32位） |
|
maxdsiz_64bit |
maximum process data segment size for 64_bit |
|
Maxssiz |
加大最大堆栈段的大小。（32_bit） |
|
maxssiz_64bit |
加大最大堆栈段的大小（64_bit） |
|
Maxtsiz |
提高最大代码段大小，满足应用要求 |
|
maxtsiz_64bit |
原值过大，应调小 |
|
Minfree |
提高停止交换操作的自由内存的上限 |
|
Shmem |
允许进行内存共享，以提高内存的利用率。 |
|
Shmmax |
设置最大共享内存段的大小，完全满足目前的需要。 |
|
Timeslice |
由于系统的瓶颈主要反映在磁盘I/O上，因此 降低时间片的大小，一方面可避免因磁盘I/O不畅造成CPU的等待，从而提高了CPU的综合利用率。另一方面减少了进程的阻塞量。 |
|
unlockable_mem |
提高了不可锁内存的大小，使可用于换页和交换的内存空间扩大,用以满足系统对内存管理的要求。 |
用户SQL质量
以上讲的都是硬件方面的东西，在条件有限的条件下，我们可以调整应用程序的SQL质量：
1. 不要进行全表扫描（Full Table Scan）：全表扫描导致大量的I/O
2. 尽量建好和使用好索引：建索引也是有讲究的，在建索引时，也不是索引越多越好，当一个表的索引达到4个以上时，ORACLE的性能可能还是改善不了，因为OLTP系统每表超过5个索引即会降低性能，而且在一个sql 中， Oracle 从不能使用超过 5个索引；当我们用到GROUP BY和ORDER BY时,ORACLE就会自动对数据进行排序,而ORACLE在INIT.ORA中决定了sort_area_size区的大小,当排序不能在我们给定的排序区完成时,ORACLE就会在磁盘中进行排序,也就是我们讲的临时表空间中排序, 过多的磁盘排序将会令 free buffer waits 的值变高,而这个区间并不只是用于排序的,对于开发人员我提出如下忠告:
1)、select,update,delete 语句中的子查询应当有规律地查找少于20%的表行.如果一个语句查找的行数超过总行数的20%,它将不能通过使用索引获得性能上的提高.
2）、索引可能产生碎片,因为记录从表中删除时,相应也从表的索引中删除.表释放的空间可以再用,而索引释放的空间却不能再用.频繁进行删除操作的被索引的表,应当阶段性地重建索引,以避免在索引中造成空间碎片,影响性能.在许可的条件下,也可以阶段性地truncate表,truncate命令删除表中所有记录,也删除索引碎片.
3）、在使用索引时一定要按索引对应字段的顺序进行引用。
4）、用（+）比用NOT IN更有效率。
Ø 降低ORACLE的竞争：
先讲几个ORACLE的几个参数，这几个参数关系到ORACLE的竞争：
1）、freelists 和 freelist 组：他们负责ORACLE的处理表和索引的空间管理；
2）、pctfree 及 pctused：该参数决定了freelists 和 freelist 组的行为，pctfree 和pctused 参数的唯一目的就是为了控制块如何在 freelists 中进出
设置好pctfree 及 pctused对块在freelists的移走和读取很重要。
Ø 其他参数的设置
1）、包括SGA区（系统全局区）：系统全局区（SGA）是一个分配给Oracle 的包含一个 Oracle 实例的数据库的控制信息内存段。
主要包括数据库高速缓存(the database buffer cache)，
重演日志缓存（the redo log buffer），
共享池（the shared pool），
数据字典缓存（the data dictionary cache）以及其它各方面的信息
2）、db_block_buffers（数据高速缓冲区）访问过的数据都放在这一片内存区域，该参数越大，Oracle在内存中找到相同数据的可能性就越大，也即加快了查询速度。
3）、share_pool_size （SQL共享缓冲池）：该参数是库高速缓存和数据字典的高速缓存。
4）、Log_buffer （重演日志缓冲区）
5）、sort_area_size（排序区）
6）、processes （同时连接的进程数）
7）、db_block_size （数据库块大小）：Oracle默认块为2KB，太小了，因为如果我们有一个8KB的数据，则2KB块的数据库要读4次盘，才能读完，而8KB块的数据库只要1次就读完了，大大减少了I/O操作。数据库安装完成后，就不能再改变db_block_size的值了，只能重新建立数据库并且建库时，要选择手工安装数据库。
8）、open_links （同时打开的链接数）
9）、dml_locks
10）、open_cursors （打开光标数）
11）、dbwr_io_slaves （后台写进程数）
摘要: web.xml 配置
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"><web-app>...
阅读全文
Bruce Tate , 总裁, J2Life, LLC
轻量级容器可以动态地使系统主要组件之间的耦合变松散。不同的容器包含相同的设计模式，但却具有根本不同的哲学。本文帮助您在下列三种轻量级容器之间作出最佳选择：Spring Framework、HiveMind 和 PicoContainer。
2002 年在科罗拉多的一次旅行中，我完美地感受了阿肯色河。在三段不同的漂流中，这条河展示了令人惊异的多样性。柔美的布朗峡谷有着开阔的急流，翻滚着巨大的波浪。Royal Gorge 别具特色的悬崖峭壁引导着巨大而笔直的峡谷之下的水力，在这条直线上发生一点小闪失都会受到长途游泳的惩罚。Numbers 具有精密的落差，需要人们在范围狭窄的圆石花园里精确操纵。在一条河里，我有了三次极不相同的体验。
在我的上一篇文章“轻量级开发的成功秘诀，第 3 部分：Spring 露出水面”中，我们学习了轻量级容器的基本原理。本文将向您展示三种最流行的容器：
这三种容器都源于依赖注入，但每种容器都具有极不相同的特征。当我介绍每种容器的高级描述时，您将看到正在运行的每种框架，以及可以应用每种框架的环境。
核心哲学
这三种容器都接受 POJO (plain old Java object)，都具有对象生命周期的钩子（所以它们可以在创建或销毁 bean 时调用您的代码），都执行依赖注入。您可能认为这些主旋律将导致相似的容器，但事实并非如此。尽管植入每种容器的代码可能相似，但容器本身反映了不同的能力、风格和整体哲学。总而言之，每种容器的作者都忠于他们的哲学。
Spring Framework
作为开放源码框架的 Geneva，Spring Framework 为数百个 Java 2 Platform, Enterprise Edition (J2EE) API 和开放源码框架提供了轻量级容器和胶水代码 (glue code)。Spring 有一个最重要的前景：让 J2EE 更易使用。读完一些示例和书籍之后，您将看到一些常见的主题：
- Spring 支持三种依赖注入——setter、构造函数 和 方法 注入——但总的来说，最流行的模型是 setter 注入。
- 在灵活性和简单性之间，Spring 的 XML 风格配置更重视灵活性。您可以做任何事情，但对于初学者来说，配置文件是晦涩难懂的。
- Spring 的创始人认为，容器只是整体框架的一小部分。Spring 的大部分价值来源于支持该框架的数千行胶水代码。它易于插入任何系统中。
- Spring 框架是三种容器实现中最完美的。一般来说，优秀的文档都是完美编写的。
- Spring 具有自动连线 (autowire) 方式，但大多数示例都没有使用它。我并不十分了解这个决策，但有时候，能够看到明确列出的依赖关系是不错的。
- Spring 提供了完整的 AOP 框架，使得更容易附加服务。您可以使用 Spring 自己的框架或依赖丰富的 AspectJ 集成（参阅 参考资料）。
如果要用一个短语来形容 Spring，我会说让企业更强。
HiveMind
Howard Lewis Ship 是 Jakarta Tapestry Web 框架的创建者，他还创建了 HiveMind。作为一个容器，HiveMind 是灵巧、干净且易于使用的。与其他许多较好的开放源码框架一样，Ship 创建 HiveMind 是为了让它帮助解决现实问题。但是，HiveMind 向传统的轻量级容器添加了两个创新：
- 最重要的 HiveMind 创新是模块。据 Ship 所说，Eclipse 插件激发了他的 HiveMind 模块的灵感。
- HiveMind 强制您编写接口。（与所有轻量级容器一样，它不提供接口，而由您自己提供接口。）
- HiveMind 是用户友好的，它提供称为 HiveDoc 的文档工具，友好简明的 XML 配置，以及行准确的错误报告。
- HiveMind 用户通常优先选择 setter 注入，但该容器还支持构造函数注入。
如果用一个短语来形容 HiveMind 的话，我会说它是概念正确 的。
PicoContainer
到目前为止，PicoContainer 最重要的特征是它的尺寸。它没有提供许多附加物，但它具有完整的依赖注入容器。PicoContainer 还具有一些惟一特性：
- PicoContainer 很小，所以它没有拦截器、AOP 或相似类型的服务，而选择了让其他框架创建这些服务。
- PicoContainer 支持 Java 配置技术，而不支持 XML 配置技术，这与其他容器一样。
- PicoContainer 流行的使用模型是构造函数注入，但它也支持 setter 注入。
- PicoContainer 没有提供许多文档，而且一些现有文档是不完整的，但您不会太需要。
- PicoContainer 具有一个自动连线方式，它很不错。
- PicoContainer 的发展似乎有点停滞。
如果用一个短语来形容 PicoContainer 的话，我会选择理论完美，但不如 Spring 或 HiveMind 实用。
编程模型
现在我将向您展示社区中流行的编程示例，以帮助您更好地理解容器的作者希望您如何使用它们。我使用 PicoContainer 中的 Kiss 示例来展示 autowiring 和 Java 技术风格的配置，使用 HiveMind 加法器示例来展示模块能力，使用 Spring PetClinic 应用程序来展示 Hibernate 集成。
Kiss 示例 (PicoContainer)
在这三个容器中，PicoContainer 具有最简单的编程模型。要查看 Kiss 示例，可从 PicoContainer.org 下载它。安装该示例，浏览到 docs\Two+minute+tutorial.htm，然后您会看到两个组件：
清单 1. 两个 Kiss 组件
public class Boy {
public void kiss(Object kisser) {
System.out.println("I was kissed by " + kisser);
}
}
public class Girl {
Boy boy;
public Girl(Boy boy) {
this.boy = boy;
}
public void kissSomeone() {
boy.kiss(this);
}
}
|
这两个类是自解释的。Girl 对 Boy 有依赖关系。该依赖关系将通过构造函数被注入。先实例化一个容器：
MutablePicoContainer pico = new DefaultPicoContainer();
|
然后注册两个组件：
pico.registerComponentImplementation(Boy.class);
pico.registerComponentImplementation(Girl.class);
|
稍后您可以向 PicoContainer 请求一个对象，然后操作它：
Girl girl = (Girl) pico.getComponentInstance(Girl.class);
girl.kissSomeone();
|
这样就差不多了。编程模型是优雅的，基于构造函数的风格意味着您无需包括无参构造函数。对本例中的 Girl 调用这种函数将会使该对象处于不一致的状态，因为 kiss 方法将抛出异常。
加法器示例 (HiveMind)
现在，让我们看一下 HiveMind 的编程示例。从 Apache Jakarta Project 下载 HiveMind，然后查看加法器示例。您会看到接口和实现。（记住：HiveMind 强制编写接口。）
清单 2. 加法器示例接口和实现
public interface Adder
{
public double add(double arg0, double arg1);
}
public class AdderImpl implements Adder
{
public double add(double arg0, double arg1)
{
return arg0 + arg1;
}
}
|
将该服务暴露在 XML 文件中，如下所示：
清单 3. 将该服务暴露在 XML 文件中
然后，其他应用程序就可以使用该服务了，如下所示：
清单 4. 其他应用程序可以使用该服务
Registry registry = RegistryBuilder.constructDefaultRegistry();
Adder adder = (Adder) registry.getService("examples.Adder",
Adder.class);
... adder.add(arg0, arg1)
|
注意，HiveMind 的模块让您可以将多个服务组合到一起。如果您需要向容器中的服务添加功能，可以使用拦截器：
清单 5. 使用拦截器添加功能
PetClinic 应用程序 (Spring)
Spring 处理事情的方法有些不同。因为 Spring 框架不带有简单的应用程序，我从我的书籍 Spring: A Developer's Notebook 中选择了一个。您可以从 O'Reilly Media 获取该示例代码。解压示例 4，它展示了一个用于 RentaBike 商店的带有属性的 CommandLineView 对象，该对象最终成为该应用程序的数据访问对象。
清单 6. CommandLineView 对象
public class CommandLineView {
private RentABike rentaBike;
public CommandLineView() {}
public void setRentABike(RentABike rentaBike) {this.rentaBike = rentaBike;}
public RentABike getRentaBike() { return this.rentaBike; }
...
}
|
RentaBike 是具有您希望在自行车商店对象中看到的各种方法的接口：
清单 7. 接口方法
public interface RentABike {
List getBikes();
Bike getBike(String serialNo);
void setStoreName(String name);
String getStoreName();
}
|
没有显示 ArrayListBikeStore，它是 BikeStore 接口的存根实现。注意，Spring 允许编写接口，但不强制编写接口。下面是描述该应用程序中 bean 的 XML 配置文件：
清单 8. 描述应用程序 bean 的 XML 配置文件
该上下文中有两个 bean。commandLineView bean 依赖于 rentaBike bean。该应用程序通过为 rentaBike 属性指定 rentaBike 名称，显式解析该依赖关系。注意，PicoContainer 自动连接这种显式关系，Spring 也可以，但大多数用户不使用它的自动连线选项。Spring 还允许您通过拦截器或 AOP 向外观的任何方法添加服务。
比较
既然已经看到每种容器的哲学，下面是对每种环境的无形特性的详细比较，比如市场份额、整体质量（fit and finish）和整体特性列表。毕竟，即使编程模型是完美的，但如果没有文档，或者由于缺乏社区而您必须自己支持它，那么它也不会成为一个好容器。
活动社区
Spring 有一个充满活力的社区，和一个支持该框架的称为 Interface21 的职业服务公司。这很重要，因为您知道您可以获得良好的支持，公司才有动力来支持 Spring 框架。我在社区的经历简直太美好了。Spring 贡献者、创始人和用户都以杰出的内容填满了留言板。
HiveMind 框架是一个 Apache Jakarta 项目，所以有着扎实的基础。它有一个正在成长的萌芽社区。该框架的创始人 Howard Lewis Ship 是独立顾问、优秀导师和不屈不挠的提倡者。但是，要利用 HiveMind 的质量帮助或者查找其 Web 站点之外的内容仍然十分困难。尽管如此，它的在线帮助似乎不错，而且社区似乎正在成长。Hibernate 获得了有趣的胜利，它被选中——或者更应该说，Ship 被选中——组成 TheServerSide.com 的新基础设施，TheServerSide.com 是最重要的 Java 技术社区之一。
PicoContainer 也是一个 Apache Jakarta 项目，它似乎发展缓慢。截止本文撰稿，PicoContainer 的最后一次主要代码发行是在 2004 年 11 月。您看不到太多有关 PicoContainer 的新文章，这有点惭愧，因为我喜欢 PicoContainer 的一些哲学。事实上，我不太确定有没有三种开放源码轻量级容器的空间，尤其是最近第四种轻量级容器项目 Avalon 关闭之后。
就每个社区生成的活动而言，Spring 无疑是优胜者。Interface21 的支持、奇思妙想的论坛、活跃的邮件列表以及社区的跟踪记录都是无与伦比的。
整体质量
社区的大小和实力通常驱动开放源码项目的整体质量。充满活力的社区需要更好的文档和示例，而且它们会参与完成结尾的详细信息。
Spring 团队编写了可与我见过的一些比较好的商业产品相媲美的文档。如果这还不够的话，您还可以找到至少五本主要 Spring 书籍和其他许多包含 Spring 内容的出版物。（我自己曾撰写过两本有关 Spring 的书籍，其中一本书中包括 Jolt-winning Better, Faster, Lighter Java 一章，另一本是快速入门书籍 Spring: A Developer's Notebook）。错误消息是专业性和描述性的。与第三方框架和 API 的集成是所有 Java 技术框架中最好的。包装是经过深思熟虑的，不过略有多余。（它帮助我开始把一些比较小的项目划分成模块。）示例是优秀且有指导意义的。
与 Tapestry 一样，HiveMind 也具有好的整体质量。Ship 自己以那些让 HiveMind 变得简单易用的特性而自豪，比如行准确的错误报告；友好简明的 XML 语法；良好的文档工具 HiveDoc。与用于低级详细信息的 JavaDoc 文档结合使用，您可以更好地描述您的应用程序（HiveMind 模块）的高级特性，从而完善它们之间的依赖关系。
PicoContainer 编程模型感觉自然，但文档不完整（许多方法标记看起来过时好几个月了），而且没有许多使用该容器的真实世界示例。有时候，我会觉得自己在独自穿过鬼魂出没的破屋。
但使用 PicoContainer 确实有一个主要优点。因为您配置现实世界的对象时，会得到一些编译时错误检查。实际上，该容器太小太轻了，以至于除了基本配置之外，没有什么能出错。PicoContainer 做了一项合理的工作。
特性
我不想过多地讨论特性。如果您正在寻找许多胶水代码来减少您的开放源码收藏夹的集成或某特定 J2EE API，Spring 无疑是最佳选择。HiveMind 不尝试参与竞争。相反，它与 Spring 的服务兼容。PicoContainer 不构建而且也不尝试构建附加物，而是选择让开放源码项目为其提供服务。到目前为止，它的效果不太好。
哪一个最好？
目前，只有一个真正的答案。HiveMind 具有有趣的创新，PicoContainer 具有易于使用的模型（理论上），但社区似乎已经投票选择了 Spring Framework。随着时间的推移，新的容器可能会成长，HiveMind 可能不断获得市场份额，但目前，Spring 是您的最佳选择。
如果您愿意冒一些险，而使用不太成熟或不太流行的容器，您可能决定实现 HiveMind（如果需要模块级别的配置）或 PicoContainer（如果想要微小的容器）。如果需要许多胶水代码来集成持久引擎、事务处理策略和安全性等方面，Spring 具有最完整的组件堆。但请记住：您可以在 HiveMind 容器中使用 Spring 组件。
参考资料
学习
原文：
http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight4/
在JSP中我们经常要调用服务器端的一些dos命令，已达到一些特殊的效果，但同时调用服务器端的dos命令也存在着一些安全隐患，因此需要慎重使用。
以下以一个例子来说明用jsp执行dos的过程，比如在服务器端每天都会自动生成一个目录（目录名称为当天的日期），再此目录下会生成一些当天的新闻文件，管理员会把这些文件几个月作一次备份，备份完后在把这些文件删除。
如果在服务器上，我们可以在dos下直接执行c:\j2sdk\jar cf d:\bak\200502.jar d:\news\20050101 命令， 然后再把20050101目录删除即可。
在JSP中我们应当这么来写
<%
//执行dos命令
String commandstr = "c:/j2sdk/jar cf d:/bak/200502.jar d:/news/20050101";
Process p ;
try {
p = Runtime.getRuntime().exec(commandstr);
//等待刚刚执行的命令的结束
while (true){
if(p.waitFor() == 0) break;
}
} catch (Exception e) {
out.println(e.toString());
}
//删除已经打包的文件及其目录
File f = new File("d:/news/20020101");
String[] allFiles = f.list();
for (int i = 0; i < allFiles.length; i++) {
File delF = new File("d:/news/20050101/"+allFiles[i]);
delF.delete();
}
File delD = new File("d:/news/20050101");
delD.delete();
%>
在jsp中以下代码必须执行，如果没有该代码，则由于删除文件的速度快于打包的速度，因此当压缩包还没有打包完成，一些文件已经被删除，加入下面的代码，会在此一直做循环，一直p.waitFor()（这个方法的说明是：等待子进程的结束，如果已经结束，一般返回0）返回0为止才会接着执行后面的代码
while (true){
if(p.waitFor() == 0) break;
}
先还是看一段程序后，再一一讲解其内容吧
public class ReadMail
{
//初始化主机
String host=”smtp.163.com”;
String nuserName=”邮箱的用户名”;
String pwd=”用户密码”;
Session session;
Public void readMail()
{
Properties props=new Properties();
props.put(“mail.transport.protocol”,”smtp”);
props.put(“mail.smtp.host”,””+host+””);
props.put(“mail.smtp.port”,”25”);
session=Session.getDefaultInstance(props);
//获取Store对象，使用pop3协议也可以使用IMAP
Stroe store=session.getStore(“pop3”);
//连接到邮件服务器
store.connect(host,username,password);
//获取该用Floder对，并以只读方式打开
Folder folder=store.getFolder(“INBOX”);
Folder.open(Folder.READ_ONLY);
//检索所有邮件，按需填充
Message msg[]=folder.getMessage();
//遍历每一个邮件
BufferedReader reader=new BufferedReader(new InputStreamReader(System.in));
For(int i=0,n=msg.length;I<n;I++)
{
//打印每个邮件的发件人和主题
System.out.println(I+”:”+msg[i].getFrom()[0]+”\t”+msg[i].getSubject());
//显示消息内容
msg[i].writeTo(System.out);
}
floder.close(false);
store.close();
}
}
现在对程序一一讲解吧！
Store是一个抽象类，它模拟了消息存储器（或称为消息数据库）及其内部目录（Folder）访问协议，以存储和读取消息，由其子类提供具体实现。客户程序可以通过获取一个Store对象来访问消息存储器，以绝大多数的存储器要求用户在访问前提供认证信息，connect方法执行了该认证过程。与Transport类似，也可以指定Store使用协议。邮件是读取邮件所以用pop3协议来读取。
具体如：Store store=new Store(“pop3”);
然后认证:store.connect(host,username,pwd)
javax.mail.Folder类，它是一个抽象类，用于分级组织邮件，其子类提供针对具本协议的实现。存储在目录内的消息被顺序计数（从1开始到消息总数），该顺序被称为邮箱顺序，邮件顺序的改变消息的序列号，这种情况仅发生在客户程序调用Expunge方法擦除目录内设置了Flags.Flag.DELETED标志位的消息时。执行擦除操作后，目录内消息将重新编号。客户程序可以通过消息序列号和直接通过相应的Message对象引用目录中的对象，由于消息序列号会在会话中很可能会改变，因此应尽可能保存Message对象来引用对象。
连接stroe之后，接一来就可以获取一个文件夹（Folder）。该文件夹必须先使用open()方法打开，然后才能读取里面的消息。
Folder folder=store.getDefaultFolder();
//或Folder folder=store.getFolder(“inbox”);
folder.open(Folder.READ_WRITE);
Message message[]=folder.getMessages();
Open()方法指定了要打开的文件及打开方试（如Folder.READ_WRITE）。Inbox是pop3惟一可以使用的文件夹。如果使用IMAP，还可以使用其它的文件夹。读取了Message之后，就可以用getContent()获得内容，或者用writeTo()将内容写入输出流。GetContent()方法只能得到消息内容，而writeTo()输出却包含消息头.
如下两种方试
System.out.println(((MimeMessage)msg).getContent());
Msg.writeTo(System.out);
读完邮件后要关闭与Folder和Store的连接
folder.close(false);
stroe.close();