在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"> |
但是要注意,一般一個package內配置一個,如果配置多個,就無法預測結果了.
注意上面的配置,第一個result的name屬性被省略了,webwork會認為它是"SUCCESS".
WebWork帶的例子里面就有default-action-ref的配置,可以參考.
在性能調優(yōu)之前,我們首先來了解一下性能是什么?關于性能,我想每個學習過 Java 的人都能列出幾點,甚至可以夸夸其談。在《 Java TM Platform Performance 》一書中,定義了如下五個方面來作為評判性能的標準:
1) ????? 運算的性能——哪一個算法的執(zhí)行性能最好?
2) ????? 內存的分配——程序運行時需要耗費多少內存?
3) ????? 啟動的時間——程序啟動需要多長時間?這在 Web 項目中的影響不大,但要注意部分程序需要部署或運行在客戶端時的情形(比如 applet 程序)。
4) ????? 程序的可伸縮性——在壓力負載的情況下,程序的性能如何?
5) ????? 性能的感知——用戶在什么情況下會覺得程序的性能不好?
以上五個方面,在具體的使用場景可以有選擇的去評判。至于這五方面的性能調優(yōu),在后續(xù)的章節(jié)中將會陸續(xù)的給以相應的性能調優(yōu)策略。
我們只需要關心對我們程序有影響,可以察覺到的性能問題,而不是每一個類中的每一個方法我們都需要想方設法的提高性能。如果程序的性能沒有達到我們所期望的要求,我們才需要考慮如何優(yōu)化性能。同樣的,晦澀的代碼雖然提高了程序的性能,但同時可能帶給我們的是維護的噩夢。我們需要折中的考慮以上兩種情況,使得程序的代碼是優(yōu)美的,并且運行的足夠快,達到客戶所期望的性能要求。
優(yōu)化代碼甚至會導致不良的結果, Donald Knuth (一位比較牛比較有影響的人物,具體是誰,我也忘了,誰知道,可以告訴我一下,謝謝!)曾說過,“ Premature optimization is the root of all evil” 。在開始性能調優(yōu)前,需要先指出不優(yōu)化代碼的一些理由。
1) ????? 如果優(yōu)化的代碼已經正常工作,優(yōu)化后可能會引入新的 bug ;
2) ????? 優(yōu)化代碼趨向于使代碼更難理解和維護;
3) ????? 在一個平臺上優(yōu)化的代碼,在另一個平臺上可能更糟;
4) ????? 花費很多時間在代碼的優(yōu)化上,提高了很少的性能,卻導致了晦澀的代碼。
確實,在優(yōu)化前,我們必須認真的考慮是否值得去優(yōu)化。
一般我們提高應用程序的性能劃分為以下幾個步驟:
1) ????? 明確應用程序的性能指標,怎樣才符合期望的性能需求;
2) ????? 在目標平臺進行測試;
3) ????? 如果性能已經達到性能指標, Stop ;
4) ????? 查找性能瓶頸;
5) ????? 修改性能瓶頸;
6) ????? 返回到第 2 步。
不同版本的 JDK ,甚至不同廠家的 JDK 可能都存在著很大的差異,對于性能優(yōu)化的程度不同。一般來說,盡可能選擇最新發(fā)布的穩(wěn)定的 JDK 版本。最新的穩(wěn)定的 JDK 版本相對以前的 JDK 版本都會做一些 bug 的修改和性能的優(yōu)化工作。
垃圾收集就是自動釋放不再被程序所使用的對象的過程。當一個對象不再被程序所引用時,它所引用的堆空間可以被回收,以便被后續(xù)的新對象所使用。垃圾收集器必須能夠斷定哪些對象是不再被引用的,并且能夠把它們所占據(jù)的堆空間釋放出來。如果對象不再被使用,但還有被程序所引用,這時是不能被垃圾收集器所回收的,此時就是所謂的“內存泄漏”。監(jiān)控應用程序是否發(fā)生了內存泄漏,有一個非常優(yōu)秀的監(jiān)控工具推薦給大家—— Quest 公司的 JProbe 工具,使用它來觀察程序運行期的內存變化,并可產生內存快照,從而分析并定位內存泄漏的確切位置,可以精確定位到源碼內。這個工具的使用我在后續(xù)的章節(jié)中還會做具體介紹。
Java 堆是指在程序運行時分配給對象生存的空間。通過 -mx/-Xmx 和 -ms/-Xms 來設置起始堆的大小和最大堆的大小。根據(jù)自己 JDK 的版本和廠家決定使用 -mx 和 -ms 或 -Xmx 和 -Xms 。 Java 堆大小決定了垃圾回收的頻度和速度, Java 堆越大,垃圾回收的頻度越低,速度越慢。同理, Java 堆越小,垃圾回收的頻度越高,速度越快。要想設置比較理想的參數(shù),還是需要了解一些基礎知識的。
Java 堆的最大值不能太大,這樣會造成系統(tǒng)內存被頻繁的交換和分頁。所以最大內存必須低于物理內存減去其他應用程序和進程需要的內存。而且堆設置的太大,造成垃圾回收的時間過長,這樣將得不償失,極大的影響程序的性能。以下是一些經常使用的參數(shù)設置:
1) ????? 設置 -Xms 等于 -XmX 的值;
2) ????? 估計內存中存活對象所占的空間的大小,設置 -Xms 等于此值, -Xmx 四倍于此值;
3) ????? 設置 -Xms 等于 -Xmx 的 1/2 大小;
4) ????? 設置 -Xms 介于 -Xmx 的 1/10 到 1/4 之間;
5) ????? 使用默認的設置。
大家需要根據(jù)自己的運行程序的具體使用場景,來確定最適合自己的參數(shù)設置。
除了 -Xms 和 -Xmx 兩個最重要的參數(shù)外,還有很多可能會用到的參數(shù),這些參數(shù)通常強烈的依賴于垃圾收集的算法,所以可能因為 JDK 的版本和廠家而有所不同。但這些參數(shù)一般在 Web 開發(fā)中用的比較少,我就不做詳細介紹了。在實際的應用中注意設置 -Xms 和 -Xmx 使其盡可能的優(yōu)化應用程序就行了。對于性能要求很高的程序,就需要自己再多研究研究 Java 虛擬機和垃圾收集算法的機制了。可以看看曹曉鋼翻譯的《深入 Java 虛擬機》一書。?