在WebWork 2.2.1中,在配置文件xwork.xml中新增加了了一個元素: default-action-ref,其實(shí)這個配置非常簡單,但是很多人不知道,所以簡單介紹一下.
如果你在xwork.xml里面配置了default-action-ref,那么當(dāng)xwork中沒有找到對應(yīng)的action時,默認(rèn)就會調(diào)用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內(nèi)配置一個,如果配置多個,就無法預(yù)測結(jié)果了.
注意上面的配置,第一個result的name屬性被省略了,webwork會認(rèn)為它是"SUCCESS".
WebWork帶的例子里面就有default-action-ref的配置,可以參考.
在性能調(diào)優(yōu)之前,我們首先來了解一下性能是什么?關(guān)于性能,我想每個學(xué)習(xí)過 Java 的人都能列出幾點(diǎn),甚至可以夸夸其談。在《 Java TM Platform Performance 》一書中,定義了如下五個方面來作為評判性能的標(biāo)準(zhǔn):
1) ????? 運(yùn)算的性能——哪一個算法的執(zhí)行性能最好?
2) ????? 內(nèi)存的分配——程序運(yùn)行時需要耗費(fèi)多少內(nèi)存?
3) ????? 啟動的時間——程序啟動需要多長時間?這在 Web 項(xiàng)目中的影響不大,但要注意部分程序需要部署或運(yùn)行在客戶端時的情形(比如 applet 程序)。
4) ????? 程序的可伸縮性——在壓力負(fù)載的情況下,程序的性能如何?
5) ????? 性能的感知——用戶在什么情況下會覺得程序的性能不好?
以上五個方面,在具體的使用場景可以有選擇的去評判。至于這五方面的性能調(diào)優(yōu),在后續(xù)的章節(jié)中將會陸續(xù)的給以相應(yīng)的性能調(diào)優(yōu)策略。
我們只需要關(guān)心對我們程序有影響,可以察覺到的性能問題,而不是每一個類中的每一個方法我們都需要想方設(shè)法的提高性能。如果程序的性能沒有達(dá)到我們所期望的要求,我們才需要考慮如何優(yōu)化性能。同樣的,晦澀的代碼雖然提高了程序的性能,但同時可能帶給我們的是維護(hù)的噩夢。我們需要折中的考慮以上兩種情況,使得程序的代碼是優(yōu)美的,并且運(yùn)行的足夠快,達(dá)到客戶所期望的性能要求。
優(yōu)化代碼甚至?xí)?dǎo)致不良的結(jié)果, Donald Knuth (一位比較牛比較有影響的人物,具體是誰,我也忘了,誰知道,可以告訴我一下,謝謝!)曾說過,“ Premature optimization is the root of all evil” 。在開始性能調(diào)優(yōu)前,需要先指出不優(yōu)化代碼的一些理由。
1) ????? 如果優(yōu)化的代碼已經(jīng)正常工作,優(yōu)化后可能會引入新的 bug ;
2) ????? 優(yōu)化代碼趨向于使代碼更難理解和維護(hù);
3) ????? 在一個平臺上優(yōu)化的代碼,在另一個平臺上可能更糟;
4) ????? 花費(fèi)很多時間在代碼的優(yōu)化上,提高了很少的性能,卻導(dǎo)致了晦澀的代碼。
確實(shí),在優(yōu)化前,我們必須認(rèn)真的考慮是否值得去優(yōu)化。
一般我們提高應(yīng)用程序的性能劃分為以下幾個步驟:
1) ????? 明確應(yīng)用程序的性能指標(biāo),怎樣才符合期望的性能需求;
2) ????? 在目標(biāo)平臺進(jìn)行測試;
3) ????? 如果性能已經(jīng)達(dá)到性能指標(biāo), Stop ;
4) ????? 查找性能瓶頸;
5) ????? 修改性能瓶頸;
6) ????? 返回到第 2 步。
不同版本的 JDK ,甚至不同廠家的 JDK 可能都存在著很大的差異,對于性能優(yōu)化的程度不同。一般來說,盡可能選擇最新發(fā)布的穩(wěn)定的 JDK 版本。最新的穩(wěn)定的 JDK 版本相對以前的 JDK 版本都會做一些 bug 的修改和性能的優(yōu)化工作。
垃圾收集就是自動釋放不再被程序所使用的對象的過程。當(dāng)一個對象不再被程序所引用時,它所引用的堆空間可以被回收,以便被后續(xù)的新對象所使用。垃圾收集器必須能夠斷定哪些對象是不再被引用的,并且能夠把它們所占據(jù)的堆空間釋放出來。如果對象不再被使用,但還有被程序所引用,這時是不能被垃圾收集器所回收的,此時就是所謂的“內(nèi)存泄漏”。監(jiān)控應(yīng)用程序是否發(fā)生了內(nèi)存泄漏,有一個非常優(yōu)秀的監(jiān)控工具推薦給大家—— Quest 公司的 JProbe 工具,使用它來觀察程序運(yùn)行期的內(nèi)存變化,并可產(chǎn)生內(nèi)存快照,從而分析并定位內(nèi)存泄漏的確切位置,可以精確定位到源碼內(nèi)。這個工具的使用我在后續(xù)的章節(jié)中還會做具體介紹。
Java 堆是指在程序運(yùn)行時分配給對象生存的空間。通過 -mx/-Xmx 和 -ms/-Xms 來設(shè)置起始堆的大小和最大堆的大小。根據(jù)自己 JDK 的版本和廠家決定使用 -mx 和 -ms 或 -Xmx 和 -Xms 。 Java 堆大小決定了垃圾回收的頻度和速度, Java 堆越大,垃圾回收的頻度越低,速度越慢。同理, Java 堆越小,垃圾回收的頻度越高,速度越快。要想設(shè)置比較理想的參數(shù),還是需要了解一些基礎(chǔ)知識的。
Java 堆的最大值不能太大,這樣會造成系統(tǒng)內(nèi)存被頻繁的交換和分頁。所以最大內(nèi)存必須低于物理內(nèi)存減去其他應(yīng)用程序和進(jìn)程需要的內(nèi)存。而且堆設(shè)置的太大,造成垃圾回收的時間過長,這樣將得不償失,極大的影響程序的性能。以下是一些經(jīng)常使用的參數(shù)設(shè)置:
1) ????? 設(shè)置 -Xms 等于 -XmX 的值;
2) ????? 估計(jì)內(nèi)存中存活對象所占的空間的大小,設(shè)置 -Xms 等于此值, -Xmx 四倍于此值;
3) ????? 設(shè)置 -Xms 等于 -Xmx 的 1/2 大小;
4) ????? 設(shè)置 -Xms 介于 -Xmx 的 1/10 到 1/4 之間;
5) ????? 使用默認(rèn)的設(shè)置。
大家需要根據(jù)自己的運(yùn)行程序的具體使用場景,來確定最適合自己的參數(shù)設(shè)置。
除了 -Xms 和 -Xmx 兩個最重要的參數(shù)外,還有很多可能會用到的參數(shù),這些參數(shù)通常強(qiáng)烈的依賴于垃圾收集的算法,所以可能因?yàn)?/span> JDK 的版本和廠家而有所不同。但這些參數(shù)一般在 Web 開發(fā)中用的比較少,我就不做詳細(xì)介紹了。在實(shí)際的應(yīng)用中注意設(shè)置 -Xms 和 -Xmx 使其盡可能的優(yōu)化應(yīng)用程序就行了。對于性能要求很高的程序,就需要自己再多研究研究 Java 虛擬機(jī)和垃圾收集算法的機(jī)制了??梢钥纯床軙凿摲g的《深入 Java 虛擬機(jī)》一書。?
????????????????????????????????????????????????????????????? 高手談做程序員的基本原則
????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 引用來源:金蝶中間件公司CTO袁紅崗
??????不知不覺做軟件已經(jīng)做了十年,有成功的喜悅,也有失敗的痛苦,但總不敢稱自己是高手,因?yàn)楹臀倚哪恐姓嬲母呤謧儽绕饋?,還差的太遠(yuǎn)。世界上并沒有成為高手的捷徑,但一些基本原則是可以遵循的。
1. 扎實(shí)的基礎(chǔ)。數(shù)據(jù)結(jié)構(gòu)、離散數(shù)學(xué)、編譯原理,這些是所有計(jì)算機(jī)科學(xué)的基礎(chǔ),如果不掌握他們,很難寫出高水平的程序。據(jù)我的觀察,學(xué)計(jì)算機(jī)專業(yè)的人比學(xué)其他專業(yè)的人更能寫出高質(zhì)量的軟件。程序人人都會寫,但當(dāng)你發(fā)現(xiàn)寫到一定程度很難再提高的時候,就應(yīng)該想想是不是要回過頭來學(xué)學(xué)這些最基本的理論。不要一開始就去學(xué)OOP,即使你再精通OOP,遇到一些基本算法的時候可能也會束手無策。
2. 豐富的想象力。不要拘泥于固定的思維方式,遇到問題的時候要多想幾種解決問題的方案,試試別人從沒想過的方法。豐富的想象力是建立在豐富的知識的基礎(chǔ)上,除計(jì)算機(jī)以外,多涉獵其他的學(xué)科,比如天文、物理、數(shù)學(xué)等等。另外,多看科幻電影也是一個很好的途徑。
3. 最簡單的是最好的。這也許是所有科學(xué)都遵循的一條準(zhǔn)則,如此復(fù)雜的質(zhì)能互換原理在愛因斯坦眼里不過是一個簡單得不能再簡單的公式:E=mc2。簡單的方法更容易被人理解,更容易實(shí)現(xiàn),也更容易維護(hù)。遇到問題時要優(yōu)先考慮最簡單的方案,只有簡單方案不能滿足要求時再考慮復(fù)雜的方案。
4. 不鉆牛角尖。當(dāng)你遇到障礙的時候,不妨?xí)簳r遠(yuǎn)離電腦,看看窗外的風(fēng)景,聽聽輕音樂,和朋友聊聊天。當(dāng)我遇到難題的時候會去玩游戲,而且是那種極暴力的打斗類游戲,當(dāng)負(fù)責(zé)游戲的那部分大腦細(xì)胞極度亢奮的時候,負(fù)責(zé)編程的那部分大腦細(xì)胞就得到了充分的休息。當(dāng)重新開始工作的時候,我會發(fā)現(xiàn)那些難題現(xiàn)在竟然可以迎刃而解。
5. 對答案的渴求。人類自然科學(xué)的發(fā)展史就是一個渴求得到答案的過程,即使只能知道答案的一小部分也值得我們?nèi)ジ冻?。只要你?jiān)定信念,一定要找到問題的答案,你才會付出精力去探索,即使最后沒有得到答案,在過程中你也會學(xué)到很多東西。
6. 多與別人交流。三人行必有我?guī)?,也許在一次和別人不經(jīng)意的談話中,就可以迸出靈感的火花。多上上網(wǎng),看看別人對同一問題的看法,會給你很大的啟發(fā)。
7. 良好的編程風(fēng)格。注意養(yǎng)成良好的習(xí)慣,代碼的縮進(jìn)編排,變量的命名規(guī)則要始終保持一致。大家都知道如何排除代碼中錯誤,卻往往忽視了對注釋的排錯。注釋是程序的一個重要組成部分,它可以使你的代碼更容易理解,而如果代碼已經(jīng)清楚地表達(dá)了你的思想,就不必再加注釋了,如果注釋和代碼不一致,那就更加糟糕。
8. 韌性和毅力。這也許是"高手"和一般程序員最大的區(qū)別。高手們并不是天才,他們是在無數(shù)個日日夜夜中磨練出來的。成功能給我們帶來無比的喜悅,但過程卻是無比的枯燥乏味。你不妨做個測試,找個10000以內(nèi)的素數(shù)表,把它們?nèi)汲聛恚缓笤贆z查三遍,如果能夠不間斷地完成這一工作,你就可以滿足這一條。
這些是我這幾年程序員生涯的一點(diǎn)體會,希望能夠給大家有所幫助。