這篇文章主要講解了“怎么進(jìn)行Java EE性能測試與調(diào)優(yōu)”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么進(jìn)行Java EE性能測試與調(diào)優(yōu)”吧！

專注于為中小企業(yè)提供網(wǎng)站制作、成都網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)達(dá)茂旗免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了上1000家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

性能測試的目標(biāo)

性能測試不同于功能測試，不是對與錯(cuò)的檢驗(yàn)，而是快與慢的衡量。在進(jìn)行真正的性能測試之前要先搞清楚目標(biāo)：

1. 在確定的硬件條件下，可以支持的并發(fā)數(shù)越大越好，響應(yīng)時(shí)間越快越好。具體需要達(dá)到的并發(fā)數(shù)是多大，要求的響應(yīng)時(shí)間是多快，由產(chǎn)品經(jīng)理來提出。

2. 在確定的硬件條件下，測試得到***并發(fā)數(shù)和相應(yīng)的響應(yīng)時(shí)間之后。如果增加硬件投入，可以得到怎樣的性能提升回報(bào)？ （系統(tǒng)擴(kuò)展性和伸縮性測試，Scalability）

這里的硬件條件包括：cpu，memery，I/O，network bandwidth。

性能測試中的基準(zhǔn)測試 Benchmarking

與功能測試相似，性能測試也要設(shè)計(jì)測試用例，不同的是在正式開始你的業(yè)務(wù)測試用例之前你要先進(jìn)行一下基準(zhǔn)測試。為什么呢？其實(shí)就是先要量一下你的硬件的能力，不然，如果你的測試結(jié)果不好，你怎么知道是硬件慢還是你的軟件的問題。這些硬件測試包括：

1. 網(wǎng)絡(luò)帶寬測試， 你可以通過copy大文件的方式測試你的網(wǎng)絡(luò)的***帶寬是多少。

2. cpu，你可以利用比較復(fù)雜的算法來衡量cpu的快慢

3. memery，這個(gè)不用測試，你知道m(xù)emery的大小

4. IO， 也可以通過copy大文件來測試

這些基準(zhǔn)測試用例在后面的調(diào)優(yōu)過程中，還可以用來衡量你修改之后真的變好了嗎。

設(shè)計(jì)你的業(yè)務(wù)測試用例

比較理想的測試用例就是要盡可能模仿真實(shí)世界的情況，這往往做不到，尤其是對于新產(chǎn)品來說。你可以先錄制一些用戶最常用，最典型的case作為起點(diǎn)。

另外，對于并發(fā)的概念需要搞清楚。并發(fā)用戶，通常是指同時(shí)在線的用戶，這些用戶可以能在用你的系統(tǒng)的不同的功能，注意并不是說大家都在做同一件事情。對某一個(gè)事務(wù)并發(fā)請求是指某一個(gè)request的并發(fā)調(diào)用。

對于后一種并發(fā)，你往往需要計(jì)算在用戶量***的時(shí)候，大概大家都集中的在干哪一件事情，這個(gè)請求一定要夠快才好。

設(shè)計(jì)好這兩種測試用例以后，在后面的調(diào)優(yōu)過程中，他們就成了衡量你的改進(jìn)的成效的衡量的標(biāo)尺。

性能調(diào)優(yōu)

性能調(diào)優(yōu)要從底層開始，基本上要從OS開始，到JVM，Cache，Buffer Pool， SQL，DB Schema， 算法。

一次不要改的太多，改一點(diǎn)，測一下，這可是個(gè)慢功夫，需要有耐心。

在執(zhí)行測試的時(shí)候還要注意，要遵循相同的過程，系統(tǒng)需要在重啟之后先熱身再開始真正的測試，不然你會(huì)發(fā)現(xiàn)你的測試結(jié)果很不一樣，琢磨不定。

還有，要注意你的客戶端的能力，比如JMeter，很需要內(nèi)存，別因?yàn)榭蛻舳瞬恍?，誤以為是你的系統(tǒng)的問題，那就太烏龍了。

在測試調(diào)優(yōu)的時(shí)候，需要借助一些監(jiān)控工具比如JConsole，來監(jiān)控系統(tǒng)的狀況，找到系統(tǒng)的瓶頸，所謂瓶頸，就是最慢的那個(gè)部分，也常表現(xiàn)為100%被占滿。比如你的內(nèi)存或者cpu被用盡了。如果cpu和內(nèi)存還沒有用盡，說明他們在等某個(gè)資源。這時(shí)候需要用profile工具去尋找，比如JProfile，YourKit。

利用性能監(jiān)控日志

因?yàn)樾阅艿膯栴}不是很容易重現(xiàn)，當(dāng)product環(huán)境中遇到性能問題的時(shí)候，如果是數(shù)據(jù)的問題，也許當(dāng)你把product 數(shù)據(jù)copy到你的測試環(huán)境中，就能重現(xiàn)比較慢點(diǎn)查詢，加以改進(jìn)。但是如果是并發(fā)用戶或者網(wǎng)絡(luò)等運(yùn)行時(shí)環(huán)境的問題，你就很難重現(xiàn)。這時(shí)，如果你能通過日志看到那些關(guān)鍵的響應(yīng)慢的方法，也許可以幫助你快點(diǎn)找到問題所在。下面的代碼可以幫你做到這一點(diǎn)，僅供參考：

import org.slf4j.Logger;          public class TraceUtil {         final Logger logger;         final long threshold = 1000;         private long begin;         private long offtime = 0;         private String threadInfo;         private String targetId;              public TraceUtil(Logger logger, Thread thread, String targetId, long begin) {             this.logger = logger;             this.threadInfo = thread.getId() + "-" + thread.toString();             this.targetId = targetId;             this.begin = begin;         }              public void trace(String targetEvent) {             long duration = System.currentTimeMillis() - begin;             long increment = duration - offtime;             offtime = duration;             float percentage = (float) increment / (float) duration * 100;             if (duration > threshold && percentage > 20) {                 logger.error(                         "Response time is too large: [{}], {}/{} ({}), {}, {}",                         new String[] { threadInfo + "", increment + "",                                 duration + "", percentage + "%", targetEvent,                                 targetId });             }              }          }

利用JVM的MXBean找到blocked的點(diǎn)

當(dāng)你發(fā)現(xiàn)JVM占用的cpu很高，而且響應(yīng)時(shí)間比較慢，很可能是被IO或者網(wǎng)絡(luò)等慢速設(shè)備拖住了。也有可能是你的方法中某個(gè)同步點(diǎn)（同步方法或者對象）成為性能的瓶頸。這時(shí)候你可以利用JVM提供的monitor API來監(jiān)控：

<%@ page import="java.lang.management.*, java.util.*" %>       <%!           Map cpuTimes = new HashMap();           Map cpuTimeFetch = new HashMap();       %>              <%       out.println("Threads Monitoring");       long cpus = Runtime.getRuntime().availableProcessors();       ThreadMXBean threads = ManagementFactory.getThreadMXBean();       threads.setThreadContentionMonitoringEnabled(true);       long now = System.currentTimeMillis();       ThreadInfo[] t = threads.dumpAllThreads(false, false);       for (int i = 0; i < t.length; i++) {           long id = t[i].getThreadId();           Long idObj = new Long(id);           long current = 0;           if (cpuTimes.get(idObj) != null) {               long prev = ((Long) cpuTimes.get(idObj)).longValue();               current = threads.getThreadCpuTime(t[i].getThreadId());               long catchTime = ((Long) cpuTimeFetch.get(idObj)).longValue();               double percent = (double)(current - prev) / (double)((now - catchTime) * cpus * 1000);               if (percent > 0 && prev > 0) {      out.println("
" + t[i].getThreadName()+"#"+t[i].getThreadId() + " Time: " + percent + " (" + prev + ", " + current + ") ");      String locked = t[i].getLockInfo()==null?"":t[i].getLockInfo().getClassName();      out.println(" Blocked: (" + t[i].getBlockedTime() + ", " + t[i].getBlockedCount() + ", " + locked + ")
");      }          }           cpuTimes.put(idObj, new Long(current));             cpuTimeFetch.put(idObj, new Long(now));       }       %>

同步是性能的一大瓶頸

通過監(jiān)控發(fā)現(xiàn)，大量線程block在一個(gè)同步方法上，這樣cpu也使不上勁。當(dāng)你發(fā)現(xiàn)性能上不去，IO和網(wǎng)絡(luò)等慢速設(shè)備也不是問題的時(shí)候，你就得檢查一下是否在某個(gè)關(guān)鍵點(diǎn)上使用了同步（synchronizae）。有時(shí)候也許是你應(yīng)用的第三方的jar里面的某個(gè)方法是同步的，這種情況下，你就很難找到問題所在。只能在編寫代碼的時(shí)候看一下你引用的方法是否是同步的。

感謝各位的閱讀，以上就是“怎么進(jìn)行Java EE性能測試與調(diào)優(yōu)”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對怎么進(jìn)行Java EE性能測試與調(diào)優(yōu)這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！