11 個簡單的 Java 性能調(diào)優(yōu)技巧
來源：原創(chuàng) 時間：2017-11-09 瀏覽：0 次大多數(shù)開發(fā)人員天經(jīng)地義地以為功用優(yōu)化很雜亂，需求許多的經(jīng)歷和常識。好吧，不能說這是徹底過錯的。優(yōu)化運用程序以取得最佳功用不是一件簡略的作業(yè)?？墒?，這并不意味著如果你不具備這些常識，就不能做任何作業(yè)。這里有11個易于遵從的主張和最佳實踐能夠協(xié)助你創(chuàng)立一個功用杰出的運用程序。
java-logo-6
大部分主張是針對Java的。但也有若干主張是與言語無關的，能夠運用于一切運用程序和編程言語。在評論專門針對Java的功用調(diào)優(yōu)技巧之前，讓我們先來看看通用技巧。
1.在你知道必要之前不要優(yōu)化
這可能是最重要的功用調(diào)整技巧之一。你應該遵從常見的最佳實踐做法并測驗高效地完成用例?？墒?，這并不意味著在你證明必要之前，你應該替換任何規(guī)范庫或構建雜亂的優(yōu)化。
在大多數(shù)狀況下，過早優(yōu)化不光會占用許多時刻，并且會使代碼變得難以閱覽和保護。更糟糕的是，這些優(yōu)化一般不會帶來任何優(yōu)點，因為你花費許多時刻來優(yōu)化的是運用程序的非要害部分。
那么，你怎么證明你需求優(yōu)化一些東西呢？
首要，你需求界說運用程序代碼的速度得多快，例如，為一切API調(diào)用指定最大呼應時刻，或許指定在特定時刻規(guī)模內(nèi)要導入的記載數(shù)量。在完結這些之后，你就能夠丈量運用程序的哪些部分太慢需求改進。然后，接著看第二個技巧。
2.運用剖析器查找真實的瓶頸
在你遵從第一個主張并斷定了運用程序的某些部分需求改進后，那么從哪里開端呢？
你能夠用兩種辦法來處理問題：
查看你的代碼，并從看起來可疑或許你覺得可能會發(fā)作問題的部分開端。
或許運用剖析器并獲取有關代碼每個部分的行為和功用的詳細信息。
期望不需求我解說為什么應該一直遵從第二種辦法的原因。
很明顯，根據(jù)剖析器的辦法能夠讓你更好地了解代碼的功用影響，并使你能夠?qū)Ｐ挠谧钜Φ牟糠帧Ｈ绻阍\用過剖析器，那么你必定記住從前你是多么驚奇于一下就找到了代碼的哪些部分發(fā)作了功用問題。老實說，我第一次的猜想不止一次地導致我走錯了方向。
3.為整個運用程序創(chuàng)立功用測驗套件
這是另一個通用技巧，能夠協(xié)助你防止在將功用改進布置到生產(chǎn)后常常會發(fā)作的許多意外問題。你應該總是界說一個測驗整個運用程序的功用測驗套件，并在功用改進之前和之后運轉(zhuǎn)它。
這些額定的測驗運轉(zhuǎn)將協(xié)助你辨認更改的功用和功用副作用，并保證不會導致弊大于利的更新。如果你作業(yè)于被運用程序若干不同部分運用的組件，如數(shù)據(jù)庫或緩存，那么這一點就特別重要。
4.首要處理最大的瓶頸
在創(chuàng)立測驗套件并運用剖析器剖析運用程序之后，你能夠列出一系列需求處理以進步功用的問題。這很好，但它仍然不能答復你應該從哪里開端的問題。你能夠?qū)Ｐ挠谒傩в媱?，或從最重要的問題開端。
速效計劃一開端可能會很有吸引力，因為你能夠很快顯現(xiàn)第一個作用。但有時，可能需求你壓服其他團隊成員或辦理層以為功用剖析是值得的——因為暫時看不到作用。
但總的來說，我主張首要處理最重要的功用問題。這將為你供給最大的功用改進，并且可能再也不需求去處理其間一些為了滿意功用需求的問題。
常見的功用調(diào)整技巧到此結束。下面讓我們細心看看一些特定于Java的技巧。
5.運用StringBuilder以編程辦法銜接String
有許多不同的選項來銜接Java中的String。例如，你能夠運用簡略的+或+ =，以及StringBuffer或StringBuilder。
那么，你應該挑選哪種辦法？
答案取決于銜接String的代碼。如果你是以編程辦法增加新內(nèi)容到String中，例如在for循環(huán)中，那么你應該運用StringBuilder。它很簡略運用，并供給比StringBuffer更好的功用。但請記住，與StringBuffer比較，StringBuilder不是線程安全的，可能不適合一切用例。
你只需求實例化一個新的StringBuilder并調(diào)用append辦法來向String中增加一個新的部分。在你增加了一切的部分之后，你就能夠調(diào)用toString()辦法來檢索銜接的String。
下面的代碼片段顯現(xiàn)了一個簡略的比如。在每次迭代期間，這個循環(huán)將i轉(zhuǎn)換為一個String，并將它與一個空格一同增加到StringBuilder sb中。所以，最終，這段代碼將在日志文件中寫入“This is a test0 1 2 3 4 5 6 7 8 9”。
StringBuilder sb = newStringBuilder(“This is a test”);
for (int i=0; i<10; i++) {
sb.append(i);
sb.append(”“);
}
log.info(sb.toString());
正如在代碼片段中看到的那樣，你能夠?qū)tring的第一個元素供給給結構辦法。這將創(chuàng)立一個新的StringBuilder，新的StringBuilder包括供給的String和16個額定字符的容量。當你向StringBuilder增加更多字符時，JVM將動態(tài)增加StringBuilder的巨細。
如果你現(xiàn)已知道你的String將包括多少個字符，則能夠?qū)⒃摂?shù)字供給給不同的結構辦法以實例化具有界說容量的StringBuilder。這進一步進步了功率，因為它不需求動態(tài)擴展其容量。
6.運用+銜接一個語句中的String
當你用Java完成你的第一個運用程序時，可能有人通知過你不該該用+來銜接String。如果你是在運用程序邏輯中銜接字符串，這是正確的。字符串是不可變的，每個字符串的銜接成果都存儲在一個新的String目標中。這需求額定的內(nèi)存，會減慢你的運用程序，特別是如果你在一個循環(huán)內(nèi)銜接多個字符串的話。
在這些狀況下，你應該遵從技巧5并運用StringBuilder。
可是，如果你僅僅將字符串分紅多行來改進代碼的可讀性，那狀況就不一樣了。
Query q = em.createQuery(“SELECTa.id, a.firstName, a.lastName ”
+ “FROMAuthor a ”
+ “WHEREa.id = :id”);
在這些狀況下，你應該用一個簡略的+來銜接你的字符串。Java編譯器會對此優(yōu)化并在編譯時履行銜接。所以，在運轉(zhuǎn)時，你的代碼將只運用1個String，不需求銜接。
7.盡可能運用基元
防止任何開支并進步運用程序功用的另一個簡潔而快速的辦法是運用根本類型而不是其包裝類。所以，最好運用int來替代Integer，運用double來替代Double。這答應JVM將值存儲在倉庫而不是堆中以削減內(nèi)存耗費，并作出更有用的處理。
8.試著防止BigInteger和BigDecimal
已然我們在評論數(shù)據(jù)類型，那么我們也快速閱讀一下BigInteger和BigDecimal吧。特別是后者因其精確性而遭到我們的歡迎?？墒沁@是有價值的。
BigInteger和BigDecimal比簡略的long或double需求更多的內(nèi)存，并且會明顯減慢一切核算。所以，你如果需求額定的精度，或許數(shù)字將超越long的規(guī)模，那么最好三思而后行。這可能是你需求更改以處理功用問題的僅有辦法，特別是在完成數(shù)學算法的時分。
9.首要查看當時日志等級
這個主張應該是清楚明了的，但不幸的是，許多程序員在寫代碼的時分都會大多會疏忽它。在你創(chuàng)立調(diào)試音訊之前，一直應該首要查看當時日志等級。不然，你可能會創(chuàng)立一個之后會被疏忽的日志音訊字符串。
這里有兩個不和比如。
// don’t do this
log.debug(“User [” + userName + “] called method X with [” + i + “]”);
// or this
log.debug(String.format(“User [%s] called method X with [%d]”, userName, i));
在上面兩種狀況中，你都將履行創(chuàng)立日志音訊一切必需的過程，在不知道日志結構是否將運用日志音訊的前提下。因而在創(chuàng)立調(diào)試音訊之前，最好先查看當時的日志等級。
// do this
if (log.isDebugEnabled()){
log.debug(“User [” + userName + “] called method Xwith [” + i + “]”);
}
10.運用Apache Commons StringUtils.Replace而不是String.replace
一般來說，String.replace辦法作業(yè)正常，功率很高，特別是在運用Java 9的狀況下?？墒?，如果你的運用程序需求許多的替換操作，并且沒有更新到最新的Java版別，那么我們?nèi)匀挥斜匾檎腋旌透杏玫奶娲贰?/span>
有一個備選答案是Apache Commons Lang的StringUtils.replace辦法。正如Lukas Eder在他最近的一篇博客文章中所描繪的，StringUtils.replace辦法遠勝Java 8的String.replace辦法。
并且它只需求很小的改動。即增加Apache Commons Lang項目的Maven依靠項到運用程序pom.xml中，并將String.replace辦法的一切調(diào)用替換為StringUtils.replace辦法。
// replace this
test.replace(“test”,“simple test”);
// with this
StringUtils.replace(test, “test”,“simple test”);
11.緩存貴重的資源，如數(shù)據(jù)庫銜接
緩存是防止重復履行貴重或常用代碼片段的盛行處理計劃?？偟乃悸泛芎喡裕褐貜瓦\用這些資源比重復創(chuàng)立新的資源要廉價。
一個典型的比如是緩存池中的數(shù)據(jù)庫銜接。新銜接的創(chuàng)立需求時刻，如果你重用現(xiàn)有銜接，則能夠防止這種狀況。
你還能夠在Java言語自身找到其他比如。例如，Integer類的valueOf辦法緩存了-128到127之間的值。你可能會說創(chuàng)立一個新的Integer并不是太貴重，可是因為它常常被運用，以至于緩存最常用的值也能夠供給功用優(yōu)勢。
可是，當你考慮緩存時，請記住緩存完成也會發(fā)作開支。你需求花費額定的內(nèi)存來存儲可重用資源，因而你可能需求辦理緩存以使資源可拜訪，以及刪去過期的資源。
所以，在開端緩存任何資源之前，請保證施行緩存是值得的，也就是說有必要足夠多地運用它們。
總結
正如你所看到的，有時不需求太多作業(yè)就能夠進步運用程序的功用。本文中的大部分主張只需求你稍作盡力就能夠?qū)⑺鼈冞\用于你的代碼。
可是，最重要的仍是那些與是什么編程言語無關的技巧：
在你知道必要之前不要優(yōu)化
運用剖析器查找真實的瓶頸
首要處理最大的瓶頸
