在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的配置,可以參考.
在性能調優之前,我們首先來了解一下性能是什么?關于性能,我想每個學習過 Java 的人都能列出幾點,甚至可以夸夸其談。在《 Java TM Platform Performance 》一書中,定義了如下五個方面來作為評判性能的標準:
1) ????? 運算的性能——哪一個算法的執行性能最好?
2) ????? 內存的分配——程序運行時需要耗費多少內存?
3) ????? 啟動的時間——程序啟動需要多長時間?這在 Web 項目中的影響不大,但要注意部分程序需要部署或運行在客戶端時的情形(比如 applet 程序)。
4) ????? 程序的可伸縮性——在壓力負載的情況下,程序的性能如何?
5) ????? 性能的感知——用戶在什么情況下會覺得程序的性能不好?
以上五個方面,在具體的使用場景可以有選擇的去評判。至于這五方面的性能調優,在后續的章節中將會陸續的給以相應的性能調優策略。
我們只需要關心對我們程序有影響,可以察覺到的性能問題,而不是每一個類中的每一個方法我們都需要想方設法的提高性能。如果程序的性能沒有達到我們所期望的要求,我們才需要考慮如何優化性能。同樣的,晦澀的代碼雖然提高了程序的性能,但同時可能帶給我們的是維護的噩夢。我們需要折中的考慮以上兩種情況,使得程序的代碼是優美的,并且運行的足夠快,達到客戶所期望的性能要求。
優化代碼甚至會導致不良的結果, Donald Knuth (一位比較牛比較有影響的人物,具體是誰,我也忘了,誰知道,可以告訴我一下,謝謝!)曾說過,“ Premature optimization is the root of all evil” 。在開始性能調優前,需要先指出不優化代碼的一些理由。
1) ????? 如果優化的代碼已經正常工作,優化后可能會引入新的 bug ;
2) ????? 優化代碼趨向于使代碼更難理解和維護;
3) ????? 在一個平臺上優化的代碼,在另一個平臺上可能更糟;
4) ????? 花費很多時間在代碼的優化上,提高了很少的性能,卻導致了晦澀的代碼。
確實,在優化前,我們必須認真的考慮是否值得去優化。
一般我們提高應用程序的性能劃分為以下幾個步驟:
1) ????? 明確應用程序的性能指標,怎樣才符合期望的性能需求;
2) ????? 在目標平臺進行測試;
3) ????? 如果性能已經達到性能指標, Stop ;
4) ????? 查找性能瓶頸;
5) ????? 修改性能瓶頸;
6) ????? 返回到第 2 步。
不同版本的 JDK ,甚至不同廠家的 JDK 可能都存在著很大的差異,對于性能優化的程度不同。一般來說,盡可能選擇最新發布的穩定的 JDK 版本。最新的穩定的 JDK 版本相對以前的 JDK 版本都會做一些 bug 的修改和性能的優化工作。
垃圾收集就是自動釋放不再被程序所使用的對象的過程。當一個對象不再被程序所引用時,它所引用的堆空間可以被回收,以便被后續的新對象所使用。垃圾收集器必須能夠斷定哪些對象是不再被引用的,并且能夠把它們所占據的堆空間釋放出來。如果對象不再被使用,但還有被程序所引用,這時是不能被垃圾收集器所回收的,此時就是所謂的“內存泄漏”。監控應用程序是否發生了內存泄漏,有一個非常優秀的監控工具推薦給大家—— 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 虛擬機》一書。?
????????????????????????????????????????????????????????????? 高手談做程序員的基本原則
????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 引用來源:金蝶中間件公司CTO袁紅崗
??????不知不覺做軟件已經做了十年,有成功的喜悅,也有失敗的痛苦,但總不敢稱自己是高手,因為和我心目中真正的高手們比起來,還差的太遠。世界上并沒有成為高手的捷徑,但一些基本原則是可以遵循的。
1. 扎實的基礎。數據結構、離散數學、編譯原理,這些是所有計算機科學的基礎,如果不掌握他們,很難寫出高水平的程序。據我的觀察,學計算機專業的人比學其他專業的人更能寫出高質量的軟件。程序人人都會寫,但當你發現寫到一定程度很難再提高的時候,就應該想想是不是要回過頭來學學這些最基本的理論。不要一開始就去學OOP,即使你再精通OOP,遇到一些基本算法的時候可能也會束手無策。
2. 豐富的想象力。不要拘泥于固定的思維方式,遇到問題的時候要多想幾種解決問題的方案,試試別人從沒想過的方法。豐富的想象力是建立在豐富的知識的基礎上,除計算機以外,多涉獵其他的學科,比如天文、物理、數學等等。另外,多看科幻電影也是一個很好的途徑。
3. 最簡單的是最好的。這也許是所有科學都遵循的一條準則,如此復雜的質能互換原理在愛因斯坦眼里不過是一個簡單得不能再簡單的公式:E=mc2。簡單的方法更容易被人理解,更容易實現,也更容易維護。遇到問題時要優先考慮最簡單的方案,只有簡單方案不能滿足要求時再考慮復雜的方案。
4. 不鉆牛角尖。當你遇到障礙的時候,不妨暫時遠離電腦,看看窗外的風景,聽聽輕音樂,和朋友聊聊天。當我遇到難題的時候會去玩游戲,而且是那種極暴力的打斗類游戲,當負責游戲的那部分大腦細胞極度亢奮的時候,負責編程的那部分大腦細胞就得到了充分的休息。當重新開始工作的時候,我會發現那些難題現在竟然可以迎刃而解。
5. 對答案的渴求。人類自然科學的發展史就是一個渴求得到答案的過程,即使只能知道答案的一小部分也值得我們去付出。只要你堅定信念,一定要找到問題的答案,你才會付出精力去探索,即使最后沒有得到答案,在過程中你也會學到很多東西。
6. 多與別人交流。三人行必有我師,也許在一次和別人不經意的談話中,就可以迸出靈感的火花。多上上網,看看別人對同一問題的看法,會給你很大的啟發。
7. 良好的編程風格。注意養成良好的習慣,代碼的縮進編排,變量的命名規則要始終保持一致。大家都知道如何排除代碼中錯誤,卻往往忽視了對注釋的排錯。注釋是程序的一個重要組成部分,它可以使你的代碼更容易理解,而如果代碼已經清楚地表達了你的思想,就不必再加注釋了,如果注釋和代碼不一致,那就更加糟糕。
8. 韌性和毅力。這也許是"高手"和一般程序員最大的區別。高手們并不是天才,他們是在無數個日日夜夜中磨練出來的。成功能給我們帶來無比的喜悅,但過程卻是無比的枯燥乏味。你不妨做個測試,找個10000以內的素數表,把它們全都抄下來,然后再檢查三遍,如果能夠不間斷地完成這一工作,你就可以滿足這一條。
這些是我這幾年程序員生涯的一點體會,希望能夠給大家有所幫助。
[1]好好規劃自己的路,不要跟著感覺走!根據個人的理想決策安排,絕大部分人并不指望成為什么院士或教授,而是希望活得滋潤一些,爽一些。那么,就需要慎重安排自己的軌跡。從哪個行業入手,逐漸對該行業深入了解,不要頻繁跳槽,特別是不要為了一點工資而轉移陣地,從長遠看,這點錢根本不算什么,當你對一個行業有那么幾年的體會,以后錢根本不是問題。頻繁地動蕩不是上策,最后你對哪個行業都沒有摸透,永遠是新手!該例子主要實現了jstl 下拉菜單的功能,由于jstl中沒有else功能,下面同時體現了如何在jstl實現if? else的功能。
<%
java.util.List list = new java.util.ArrayList();
list.add("");
list.add("限時");
list.add("特提");
list.add("平急");
request.setAttribute("list", list);
//用數組也可以實現
//String[] str = {"","限時","特提","特急"};
//request.setAttribute("list",str);
%>
<select size="1" name="jjcd" value="" style="width: 91; height: 18">
? <c:forEach var="item" items="${list}">
??<c:choose>
??<c:when test="${item eq '特提'}">
??<option selected>特提</option>
??</c:when>
??<c:otherwise>
???<option><c:out value="${item}"/></option>
??</c:otherwise>
??</c:choose>
? </c:forEach>
</select>
另一種實現下拉菜單的方法:
?? <select name="jjcd">
??<c:forEach var="item" items="${list}">
???<option <c:if test="${item eq '特提'}">selected</c:if> value="<c:out value="${item}"/>">
???<c:out value="${item}"/></option>
??</c:forEach>
?? </select>