本篇內(nèi)容介紹了“怎么用Java制定性能調(diào)優(yōu)策略”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)主要從事網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)雞東,十余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792

測試 - 分析 - 調(diào)優(yōu)

性能測試攻略

性能測試是提前能發(fā)現(xiàn)性能瓶頸，保障系統(tǒng)性能穩(wěn)定的必要措施。

1.微基準(zhǔn)性能測試

微基準(zhǔn)性能測試可以精確定位到某個(gè)模塊或者某個(gè)方法的性能問題，特別適合做一個(gè)功能模塊或者一個(gè)方法在不同實(shí)現(xiàn)方式下的性能對比。例如，對比一個(gè)方法使用同步實(shí)現(xiàn)和非同步實(shí)現(xiàn)的性能。

2.宏基準(zhǔn)性能測試

宏基準(zhǔn)性能測試是一個(gè)綜合測試，需要考慮到測試環(huán)境、測試場景和測試目標(biāo)。

首先看測試環(huán)境，我們需要模擬線上的真實(shí)環(huán)境。

然后看測試場景。我們需要確定在測試某個(gè)接口時(shí)，是否有其他業(yè)務(wù)接口同時(shí)也在平行運(yùn)行，造成干擾。如果有，請重視，因?yàn)槟阋坏┖鲆暳诉@種干擾，測試結(jié)果就會出現(xiàn)偏差。

最后看測試目標(biāo)。我們的性能測試是要有目標(biāo)的，這里可以通過吞吐量以及響應(yīng)時(shí)間來衡量系統(tǒng)是否達(dá)標(biāo)。不達(dá)標(biāo)，就進(jìn)行優(yōu)化；達(dá)標(biāo)就繼續(xù)加大測試的并發(fā)數(shù)，探底接口的 TPS(最大每秒事務(wù)處理量)，這樣做，可以深入了解到接口的性能。除了測試接口的吞吐量和響應(yīng)時(shí)間以外，我們還需要循環(huán)測試可能導(dǎo)致性能問題的接口，觀察各個(gè)服務(wù)器的 CPU 、內(nèi)存以及 I/O 使用率的變化。

以上就是兩種測試方法的詳解。其中值得注意的是，性能測試存在干擾因子，會使測試結(jié)果不準(zhǔn)確。所以，我們在做性能測試時(shí)，還要注意一些問題。

1、熱身問題

當(dāng)我們做性能測試時(shí)，我們的系統(tǒng)會運(yùn)行得越來越快，后面的訪問速度要比我們第一次訪問的速度快上幾倍。這是怎么回事呢？

在 Java 編程語言和環(huán)境中，.Java 文件編譯成為 .class 文件后，機(jī)器還是無法直接運(yùn)行 .class 文件中的字節(jié)碼，需要通過解釋器將字節(jié)碼轉(zhuǎn)換成本地機(jī)器碼才能運(yùn)行。為了節(jié)約內(nèi)存和執(zhí)行效率，代碼最初被執(zhí)行時(shí)，解釋器會率先執(zhí)行這段代碼。

隨著代碼被執(zhí)行的次數(shù)增多，當(dāng)虛擬機(jī)發(fā)現(xiàn)某個(gè)方法或代碼塊運(yùn)行得特別頻繁時(shí)，就會把這些代碼認(rèn)定為熱點(diǎn)代碼。為了提高熱點(diǎn)代碼的執(zhí)行效率，在運(yùn)行時(shí)，虛擬機(jī)將會通過即時(shí)編譯器，把這些代碼編譯成與本地平臺相關(guān)的機(jī)器碼，并進(jìn)行各層次的優(yōu)化，然后儲存在內(nèi)存中，之后每次運(yùn)行代碼時(shí)，直接從內(nèi)存匯總獲取即可。

所以在剛開始運(yùn)行的階段，虛擬機(jī)會花費(fèi)很長的時(shí)間來全面優(yōu)化代碼，后面就能以最高性能執(zhí)行了。

這就是熱身過程，如果在進(jìn)行性能測試時(shí)，熱身時(shí)間過長，就會導(dǎo)致第一次訪問速度過慢，你就可以考慮先優(yōu)化，再進(jìn)行測試

2、性能測試結(jié)果不穩(wěn)定

我們在做性能測試時(shí)發(fā)現(xiàn)，每次測試處理的數(shù)據(jù)集都是一樣的，但測試結(jié)果卻有差異。這是因?yàn)闇y試時(shí)，伴隨著很多不穩(wěn)定因?yàn)?，比如機(jī)器其他進(jìn)程的影響、網(wǎng)絡(luò)波動(dòng)以及每個(gè)階段 JVM 垃圾回收的不同等等。

我們可以通過多次測試，將測試結(jié)果求平均，或者統(tǒng)計(jì)一個(gè)曲線圖，只要保證我們的平均值是在合理范圍之內(nèi)，而且波動(dòng)不是很大，這種情況下，性能測試就是通過的。

3、多 JVM 情況下的影響

如果我們的服務(wù)器有多個(gè) Java 應(yīng)用服務(wù)，部署在不同的 Tomcat 下，這就意味著我們的服務(wù)器會有多個(gè) JVM。任意一個(gè) JVM 都擁有整個(gè)系統(tǒng)的資源使用權(quán)。如果一臺機(jī)器上只部署單獨(dú)的一個(gè) JVM ，在做性能測試時(shí)，測試結(jié)果很好，或者你調(diào)優(yōu)的效果很好，但在一臺機(jī)器多個(gè) JVM 的情況下就不一定了。所以我們應(yīng)該盡量避免線上環(huán)境中一臺機(jī)器部署多個(gè) JVM 的情況。

合理分析結(jié)果，制定調(diào)優(yōu)策略

我們在完成性能測試之后，需要輸出一份性能測試報(bào)告，幫我們分析系統(tǒng)性能測試的情況。其中測試結(jié)果需要包含測試接口的平均、最大和最小吞吐量，響應(yīng)時(shí)間，服務(wù)器的 CPU、內(nèi)存、I/O、網(wǎng)絡(luò) IO 使用率，JVM 的 GC 頻率等。

通過觀察這些調(diào)優(yōu)標(biāo)準(zhǔn)，可以發(fā)現(xiàn)性能瓶頸，我們再通過自下而上的方式分析查找問題。首先從操作系統(tǒng)層面，查看系統(tǒng)的 CPU、內(nèi)存、I/O、網(wǎng)絡(luò)的使用率是否存在異常，再通過命令查找異常日志，最后通過分析日志，找到導(dǎo)致瓶頸的原因；還可以從 Java 應(yīng)用的 JVM 層面，查看 JVM 的垃圾回收頻率以及內(nèi)存分配情況是否存在異常，分析日志，找到導(dǎo)致瓶頸的原因。

如果系統(tǒng)和 JVM 層面都沒有出現(xiàn)異常情況，我們可以查看應(yīng)用服務(wù)業(yè)務(wù)層是否存在性能瓶頸，例如 Java 編程的問題、讀寫數(shù)據(jù)瓶頸等等。

分析查找問題是一個(gè)復(fù)雜而又細(xì)致的過程，某個(gè)性能問題可能是一個(gè)原因?qū)е碌?，也可能是幾個(gè)原因共同導(dǎo)致的結(jié)果。我們分析查找問題可以采用自下而上的方式，而我們解決系統(tǒng)性能問題，則可以采用自上而下的方式逐級優(yōu)化。下面我來介紹下從應(yīng)用層到操作系統(tǒng)層的幾種調(diào)優(yōu)策略。

1、優(yōu)化代碼

應(yīng)用層的問題代碼往往會因?yàn)楹谋M系統(tǒng)資源而暴露出來。例如，我們某段代碼導(dǎo)致內(nèi)存溢出，往往是將 JVM 中的內(nèi)存用完了，這個(gè)時(shí)候系統(tǒng)的內(nèi)存資源消耗殆盡了，同時(shí)也會引發(fā)JVM 頻繁地發(fā)生垃圾回收，導(dǎo)致 CPU 100% 以上居高不下，這個(gè)時(shí)候又消耗了系統(tǒng)的CPU 資源。

還有一些是非問題代碼導(dǎo)致的性能問題，這種往往是比較難發(fā)現(xiàn)的，需要依靠我們的經(jīng)驗(yàn)來優(yōu)化。例如，我們經(jīng)常使用的 LinkedList 集合，如果使用 for 循環(huán)遍歷該容器，將大大降低讀的效率，但這種效率的降低很難導(dǎo)致系統(tǒng)性能參數(shù)異常。

這時(shí)有經(jīng)驗(yàn)的同學(xué)，就會改用 Iterator （迭代器）迭代循環(huán)該集合，這是因?yàn)?LinkedList是鏈表實(shí)現(xiàn)的，如果使用 for 循環(huán)獲取元素，在每次循環(huán)獲取元素時(shí)，都會去遍歷一次List，這樣會降低讀的效率。

2、優(yōu)化設(shè)計(jì)

面向?qū)ο笥泻芏嘣O(shè)計(jì)模式，可以幫助我們優(yōu)化業(yè)務(wù)層以及中間件層的代碼設(shè)計(jì)。優(yōu)化后，不僅可以精簡代碼，還能提高整體性能。例如，單例模式在頻繁調(diào)用創(chuàng)建對象的場景中，可以共享一個(gè)創(chuàng)建對象，這樣可以減少頻繁地創(chuàng)建和銷毀對象所帶來的性能消耗。

3、優(yōu)化算法

好的算法可以幫助我們大大地提升系統(tǒng)性能。例如，在不同的場景中，使用合適的查找算法可以降低時(shí)間復(fù)雜度。

4、時(shí)間換空間

有時(shí)候系統(tǒng)對查詢時(shí)的速度并沒有很高的要求，反而對存儲空間要求苛刻，這個(gè)時(shí)候我們可以考慮用時(shí)間來換取空間。

例如，我在 03 講就會詳解的用 String 對象的 intern 方法，可以將重復(fù)率比較高的數(shù)據(jù)集存儲在常量池，重復(fù)使用一個(gè)相同的對象，這樣可以大大節(jié)省內(nèi)存存儲空間。但由于常量池使用的是 HashMap 數(shù)據(jù)結(jié)構(gòu)類型，如果我們存儲數(shù)據(jù)過多，查詢的性能就會下降。所以在這種對存儲容量要求比較苛刻，而對查詢速度不作要求的場景，我們就可以考慮用時(shí)間換空

5、空間換時(shí)間

這種方法是使用存儲空間來提升訪問速度?，F(xiàn)在很多系統(tǒng)都是使用的 MySQL 數(shù)據(jù)庫，較為常見的分表分庫是典型的使用空間換時(shí)間的案例。

因?yàn)?MySQL 單表在存儲千萬數(shù)據(jù)以上時(shí)，讀寫性能會明顯下降，這個(gè)時(shí)候我們需要將表數(shù)據(jù)通過某個(gè)字段 Hash 值或者其他方式分拆，系統(tǒng)查詢數(shù)據(jù)時(shí)，會根據(jù)條件的 Hash 值判斷找到對應(yīng)的表，因?yàn)楸頂?shù)據(jù)量減小了，查詢性能也就提升了。

6、參數(shù)調(diào)優(yōu)

以上都是業(yè)務(wù)層代碼的優(yōu)化，除此之外，JVM、Web 容器以及操作系統(tǒng)的優(yōu)化也是非常關(guān)鍵的。

根據(jù)自己的業(yè)務(wù)場景，合理地設(shè)置 JVM 的內(nèi)存空間以及垃圾回收算法可以提升系統(tǒng)性能。例如，如果我們業(yè)務(wù)中會創(chuàng)建大量的大對象，我們可以通過設(shè)置，將這些大對象直接放進(jìn)老年代。這樣可以減少年輕代頻繁發(fā)生小的垃圾回收（Minor GC），減少 CPU 占用時(shí)間，提升系統(tǒng)性能。

Web 容器線程池的設(shè)置以及 Linux 操作系統(tǒng)的內(nèi)核參數(shù)設(shè)置不合理也有可能導(dǎo)致系統(tǒng)性能瓶頸，根據(jù)自己的業(yè)務(wù)場景優(yōu)化這兩部分，可以提升系統(tǒng)性能。

兜底策略，確保系統(tǒng)穩(wěn)定性

第一，限流，對系統(tǒng)的入口設(shè)置最大訪問限制。這里可以參考性能測試中探底接口的 TPS。同時(shí)采取熔斷措施，友好地返回沒有成功的請求。

第二，實(shí)現(xiàn)智能化橫向擴(kuò)容。智能化橫向擴(kuò)容可以保證當(dāng)訪問量超過某一個(gè)閾值時(shí)，系統(tǒng)可以根據(jù)需求自動(dòng)橫向新增服務(wù)。

第三，提前擴(kuò)容。這種方法通常應(yīng)用于高并發(fā)系統(tǒng)，例如，瞬時(shí)搶購業(yè)務(wù)系統(tǒng)。這是因?yàn)闄M向擴(kuò)容無法滿足大量發(fā)生在瞬間的請求，即使成功了，搶購也結(jié)束了。

目前很多公司使用 Docker 容器來部署應(yīng)用服務(wù)。這是因?yàn)?Docker 容器是使用 Kubernetes 作為容器管理系統(tǒng)，而 Kubernetes 可以實(shí)現(xiàn)智能化橫向擴(kuò)容和提前擴(kuò)容Docker 服務(wù)。

“怎么用Java制定性能調(diào)優(yōu)策略”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！