在《Java TM Platform Performance》一書中，定義了如下五個(gè)方面來作為評(píng)判性能的標(biāo)準(zhǔn)：

1) 運(yùn)算的性能——哪一個(gè)算法的執(zhí)行性能最好？

2) 內(nèi)存的分配——程序運(yùn)行時(shí)需要耗費(fèi)多少內(nèi)存？

3) 啟動(dòng)的時(shí)間——程序啟動(dòng)需要多長(zhǎng)時(shí)間？這在Web項(xiàng)目中的影響不大，但要注意部分程序需要部署或運(yùn)行在客戶端時(shí)的情形（比如applet程序）。

4) 程序的可伸縮性——在壓力負(fù)載的情況下，程序的性能如何？

5) 性能的感知——用戶在什么情況下會(huì)覺得程序的性能不好？

以上五個(gè)方面，在具體的使用場(chǎng)景可以有選擇的去評(píng)判。至于這五方面的性能調(diào)優(yōu)，在后續(xù)的章節(jié)中將會(huì)陸續(xù)的給以相應(yīng)的性能調(diào)優(yōu)策略。

調(diào)優(yōu)的規(guī)則

我們只需要關(guān)心對(duì)我們程序有影響，可以察覺到的性能問題，而不是每一個(gè)類中的每一個(gè)方法我們都需要想方設(shè)法的提高性能。如果程序的性能沒有達(dá)到我們所期望的要求，我們才需要考慮如何優(yōu)化性能。同樣的，晦澀的代碼雖然提高了程序的性能，但同時(shí)可能帶給我們的是維護(hù)的噩夢(mèng)。我們需要折中的考慮以上兩種情況，使得程序的代碼是優(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)化后可能會(huì)引入新的bug；

2) 優(yōu)化代碼趨向于使代碼更難理解和維護(hù)；

3) 在一個(gè)平臺(tái)上優(yōu)化的代碼，在另一個(gè)平臺(tái)上可能更糟；

4) 花費(fèi)很多時(shí)間在代碼的優(yōu)化上，提高了很少的性能，卻導(dǎo)致了晦澀的代碼。 確實(shí)，在優(yōu)化前，我們必須認(rèn)真的考慮是否值得去優(yōu)化。

調(diào)優(yōu)的步驟

一般我們提高應(yīng)用程序的性能劃分為以下幾個(gè)步驟：

1) 明確應(yīng)用程序的性能指標(biāo)，怎樣才符合期望的性能需求；

2) 在目標(biāo)平臺(tái)進(jìn)行測(cè)試；

3) 如果性能已經(jīng)達(dá)到性能指標(biāo)，Stop；

4) 查找性能瓶頸；

5) 修改性能瓶頸；

6) 返回到第2步。

編輯推薦

java認(rèn)證考試基礎(chǔ)串講資料匯總

JAVA認(rèn)證考試報(bào)考指南 / 更多JAVA考試資料

（責(zé)任編輯：xy）

共2頁,當(dāng)前第1頁  第一頁  前一頁  下一頁