随笔-8  评论-19  文章-2  trackbacks-0
  2007年3月19日

在WebWork 2.2.1中,在配置文件xwork.xml中新增加了了一个元素: default-action-ref,其实这个配置非常简单,但是很多人不知道,所以简单介绍一下.

如果你在xwork.xml里面配置了default-action-ref,那么当xwork中没有找到对应的action时,默认就会调用default-action-ref指定的action.

官方的wiki文档参考这里: http://wiki.opensymphony.com/display/WW/Action+configuration

配置代码如下:

 

												<package name="myPackage" ....>
            ...
            <default-action-ref name="simpleViewResultAction">
            <!--
            An example of a default action that is just a simple class
            that has 3 fields: successUrl, errorUrl, and inputUrl.  This action
            parses the request url to set the result values.  In the normal case
            it just renders velocity results of the same name as the requested url.
            -->
            <action name="simpleViewResultAction" class="SimpleViewResultAction">
            <result type="velocity">${successUrl}</result>
            
<result name="error" type="velocity">${errorUrl}</result>
            <result name="input" type="velocity">${inputUrl}</result>
            
</action>
... </package>

但是要注意,一般一个package内配置一个,如果配置多个,就无法预测结果了.

注意上面的配置,第一个result的name属性被省略了,webwork会认为它是"SUCCESS".

WebWork带的例子里面就有default-action-ref的配置,可以参考.

posted @ 2007-06-21 14:39 jie_java 阅读(1212) | 评论 (0)编辑 收藏

基本知识

1.1 性能是什么

在性能调优之前,我们首先来了解一下性能是什么?关于性能,我想每个学习过 Java 的人都能列出几点,甚至可以夸夸其谈。在《 Java TM Platform Performance 》一书中,定义了如下五个方面来作为评判性能的标准:

1)       运算的性能——哪一个算法的执行性能最好?

2)       内存的分配——程序运行时需要耗费多少内存?

3)       启动的时间——程序启动需要多长时间?这在 Web 项目中的影响不大,但要注意部分程序需要部署或运行在客户端时的情形(比如 applet 程序)。

4)       程序的可伸缩性——在压力负载的情况下,程序的性能如何?

5)       性能的感知——用户在什么情况下会觉得程序的性能不好?

以上五个方面,在具体的使用场景可以有选择的去评判。至于这五方面的性能调优,在后续的章节中将会陆续的给以相应的性能调优策略。

1.2 调优的规则

我们只需要关心对我们程序有影响,可以察觉到的性能问题,而不是每一个类中的每一个方法我们都需要想方设法的提高性能。如果程序的性能没有达到我们所期望的要求,我们才需要考虑如何优化性能。同样的,晦涩的代码虽然提高了程序的性能,但同时可能带给我们的是维护的噩梦。我们需要折中的考虑以上两种情况,使得程序的代码是优美的,并且运行的足够快,达到客户所期望的性能要求。

优化代码甚至会导致不良的结果, Donald Knuth (一位比较牛比较有影响的人物,具体是谁,我也忘了,谁知道,可以告诉我一下,谢谢!)曾说过,“ Premature optimization is the root of all evil” 。在开始性能调优前,需要先指出不优化代码的一些理由。

1)       如果优化的代码已经正常工作,优化后可能会引入新的 bug

2)       优化代码趋向于使代码更难理解和维护;

3)       在一个平台上优化的代码,在另一个平台上可能更糟;

4)       花费很多时间在代码的优化上,提高了很少的性能,却导致了晦涩的代码。

确实,在优化前,我们必须认真的考虑是否值得去优化。

1.3 调优的步骤

一般我们提高应用程序的性能划分为以下几个步骤:

1)       明确应用程序的性能指标,怎样才符合期望的性能需求;

2)       在目标平台进行测试;

3)       如果性能已经达到性能指标, Stop

4)       查找性能瓶颈;

5)       修改性能瓶颈;

6)       返回到第 2 步。

JDK 调优

2.1 选择合适的 JDK 版本

不同版本的 JDK ,甚至不同厂家的 JDK 可能都存在着很大的差异,对于性能优化的程度不同。一般来说,尽可能选择最新发布的稳定的 JDK 版本。最新的稳定的 JDK 版本相对以前的 JDK 版本都会做一些 bug 的修改和性能的优化工作。

2.2 垃圾收集 Java 堆的优化

垃圾收集就是自动释放不再被程序所使用的对象的过程。当一个对象不再被程序所引用时,它所引用的堆空间可以被回收,以便被后续的新对象所使用。垃圾收集器必须能够断定哪些对象是不再被引用的,并且能够把它们所占据的堆空间释放出来。如果对象不再被使用,但还有被程序所引用,这时是不能被垃圾收集器所回收的,此时就是所谓的“内存泄漏”。监控应用程序是否发生了内存泄漏,有一个非常优秀的监控工具推荐给大家—— Quest 公司的 JProbe 工具,使用它来观察程序运行期的内存变化,并可产生内存快照,从而分析并定位内存泄漏的确切位置,可以精确定位到源码内。这个工具的使用我在后续的章节中还会做具体介绍。

Java 堆是指在程序运行时分配给对象生存的空间。通过 -mx/-Xmx -ms/-Xms 来设置起始堆的大小和最大堆的大小。根据自己 JDK 的版本和厂家决定使用 -mx -ms -Xmx -Xms Java 堆大小决定了垃圾回收的频度和速度, Java 堆越大,垃圾回收的频度越低,速度越慢。同理, Java 堆越小,垃圾回收的频度越高,速度越快。要想设置比较理想的参数,还是需要了解一些基础知识的。

Java 堆的最大值不能太大,这样会造成系统内存被频繁的交换和分页。所以最大内存必须低于物理内存减去其他应用程序和进程需要的内存。而且堆设置的太大,造成垃圾回收的时间过长,这样将得不偿失,极大的影响程序的性能。以下是一些经常使用的参数设置:

1)       设置 -Xms 等于 -XmX 的值;

2)       估计内存中存活对象所占的空间的大小,设置 -Xms 等于此值, -Xmx 四倍于此值;

3)       设置 -Xms 等于 -Xmx 1/2 大小;

4)       设置 -Xms 介于 -Xmx 1/10 1/4 之间;

5)       使用默认的设置。

大家需要根据自己的运行程序的具体使用场景,来确定最适合自己的参数设置。

除了 -Xms -Xmx 两个最重要的参数外,还有很多可能会用到的参数,这些参数通常强烈的依赖于垃圾收集的算法,所以可能因为 JDK 的版本和厂家而有所不同。但这些参数一般在 Web 开发中用的比较少,我就不做详细介绍了。在实际的应用中注意设置 -Xms -Xmx 使其尽可能的优化应用程序就行了。对于性能要求很高的程序,就需要自己再多研究研究 Java 虚拟机和垃圾收集算法的机制了。可以看看曹晓钢翻译的《深入 Java 虚拟机》一书。 


 
posted @ 2007-03-19 10:12 jie_java 阅读(334) | 评论 (0)编辑 收藏