序言
聲明
因為簡書篇幅限制,151個建議只能分開.這里是 [125-135]
本書來源 @Linux公社 的 <<編寫高質(zhì)量Java代碼的151個習(xí)慣>> 的電子書
作者:秦小波 出版社:北京 機(jī)械工業(yè)出版社 2011.11
如有侵權(quán)請聯(lián)系 @小豬童鞋QQ聊天鏈接 刪除
@編寫高質(zhì)量Java代碼的151個建議(1-40)
@編寫高質(zhì)量Java代碼的151個建議(41-70)
@編寫高質(zhì)量Java代碼的151個建議(71-90)
@編寫高質(zhì)量Java代碼的151個建議(91-110)
@編寫高質(zhì)量Java代碼的151個建議(111-124)
@編寫高質(zhì)量Java代碼的151個建議(125-135)
@編寫高質(zhì)量Java代碼的151個建議(136-151)
致本文讀者:
如果小伙伴發(fā)現(xiàn)有地方有錯誤,請聯(lián)系我 @小豬童鞋QQ聊天鏈接
歡迎小伙伴和各位大佬們一起學(xué)習(xí),可私信也可通過上方QQ鏈接
我的環(huán)境:
eclipse version: 2019-03 (4.11.0) Build id: 20190314-1200
jdk1.8
Lombok.jar 插件 安裝指南看這里 @簡單粗暴節(jié)省JavaBean代碼插件 Lombok.jar
建議125：優(yōu)先選擇線程池
在Java1.5之前捺疼，實現(xiàn)多線程比較麻煩，需要自己啟動線程，并關(guān)注同步資源崇摄，防止出現(xiàn)線程死鎖等問題榜掌，在1.5版本之后引入了并行計算框架税肪，大大簡化了多線程開發(fā)讲坎。我們知道一個線程有五個狀態(tài)：新建狀態(tài)(NEW)关筒、可運行狀態(tài)(Runnable描孟，也叫作運行狀態(tài))驶睦、阻塞狀態(tài)(Blocked)、等待狀態(tài)(Waiting)匿醒、結(jié)束狀態(tài)(Terminated)场航，線程的狀態(tài)只能由新建轉(zhuǎn)變?yōu)榱诉\行狀態(tài)后才能被阻塞或等待，最后終結(jié)廉羔，不可能產(chǎn)生本末倒置的情況溉痢，比如把一個結(jié)束狀態(tài)的線程轉(zhuǎn)變?yōu)樾陆顟B(tài)，則會出現(xiàn)異常，例如如下代碼會拋出異常：
public static void main(String[] args) throws InterruptedException {
// 創(chuàng)建一個線程孩饼，新建狀態(tài)
Thread t = new Thread(new Runnable() {
@Override
public void run() {
System.out.println("線程正在運行");
}
});
// 運行狀態(tài)
t.start();
// 是否是運行狀態(tài)髓削，若不是則等待10毫秒
while (!t.getState().equals(Thread.State.TERMINATED)) {
TimeUnit.MICROSECONDS.sleep(10);
}
// 直接由結(jié)束轉(zhuǎn)變?yōu)樵菩膽B(tài)
t.start();
}
此段程序運行時會報java.lang.IllegalThreadStateException異常，原因就是不能從結(jié)束狀態(tài)直接轉(zhuǎn)變?yōu)檫\行狀態(tài)镀娶，我們知道一個線程的運行時間分為3部分：T1為線程啟動時間立膛，T2為線程的運行時間，T3為線程銷毀時間汽畴，如果一個線程不能被重復(fù)使用旧巾，每次創(chuàng)建一個線程都需要經(jīng)過啟動、運行忍些、銷毀時間鲁猩，這勢必增大系統(tǒng)的響應(yīng)時間，有沒有更好的辦法降低線程的運行時間呢罢坝？
T2是無法避免的廓握，只有通過優(yōu)化代碼來實現(xiàn)降低運行時間。T1和T2都可以通過線程池(Thread Pool)來縮減時間嘁酿，比如在容器(或系統(tǒng))啟動時隙券，創(chuàng)建足夠多的線程，當(dāng)容器(或系統(tǒng))需要時直接從線程池中獲得線程闹司，運算出結(jié)果娱仔，再把線程返回到線程池中___ExecutorService就是實現(xiàn)了線程池的執(zhí)行器，我們來看一個示例代碼：
public static void main(String[] args) throws InterruptedException {
// 2個線程的線程池
ExecutorService es = Executors.newFixedThreadPool(2);
// 多次執(zhí)行線程體
for (int i = 0; i < 4; i++) {
es.submit(new Runnable() {
@Override
public void run() {
System.out.println(Thread.currentThread().getName());
}
});
}
// 關(guān)閉執(zhí)行器
es.shutdown();
}
此段代碼首先創(chuàng)建了一個包含兩個線程的線程池游桩，然后在線程池中多次運行線程體牲迫，輸出運行時的線程名稱，結(jié)果如下：
pool-1-thread-1
pool-1-thread-2
pool-1-thread-1
pool-1-thread-2
本次代碼執(zhí)行了4遍線程體借卧，按照我們之前闡述的" 一個線程不可能從結(jié)束狀態(tài)轉(zhuǎn)變?yōu)榭蛇\行狀態(tài) "盹憎，那為什么此處的2個線程可以反復(fù)使用呢？這就是我們要搞清楚的重點铐刘。
線程池涉及以下幾個名詞：
工作線程(Worker)：線程池中的線程陪每，只有兩個狀態(tài)：可運行狀態(tài)和等待狀態(tài)，沒有任務(wù)時它們處于等待狀態(tài)镰吵，運行時它們循環(huán)的執(zhí)行任務(wù)檩禾。
任務(wù)接口(Task)：這是每個任務(wù)必須實現(xiàn)的接口，以供工作線程調(diào)度器調(diào)度捡遍，它主要規(guī)定了任務(wù)的入口锌订、任務(wù)執(zhí)行完的場景處理，任務(wù)的執(zhí)行狀態(tài)等画株。這里有兩種類型的任務(wù)：具有返回值(異常)的Callable接口任務(wù)和無返回值并兼容舊版本的Runnable接口任務(wù)。
任務(wù)對列(Work Quene)：也叫作工作隊列，用于存放等待處理的任務(wù)谓传，一般是BlockingQuene的實現(xiàn)類蜈项，用來實現(xiàn)任務(wù)的排隊處理。
我們首先從線程池的創(chuàng)建說起续挟，Executors.newFixedThreadPool(2)表示創(chuàng)建一個具有兩個線程的線程池紧卒，源代碼如下：
public class Executors {
//生成一個最大為nThreads的線程池執(zhí)行器
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}
}
這里使用了LinkedBlockingQueue作為隊列任務(wù)管理器，所有等待處理的任務(wù)都會放在該對列中诗祸，需要注意的是跑芳，此隊列是一個阻塞式的單端隊列。線程池建立好了直颅，那就需要線程在其中運行了博个，線程池中的線程是在submit第一次提交任務(wù)時建立的，代碼如下：
public Future<?> submit(Runnable task) {
//檢查任務(wù)是否為null
if (task == null) throw new NullPointerException();
//把Runnable任務(wù)包裝成具有返回值的任務(wù)對象功偿，不過此時并沒有執(zhí)行盆佣，只是包裝
RunnableFuture<Object> ftask = newTaskFor(task, null);
//執(zhí)行此任務(wù)
execute(ftask);
//返回任務(wù)預(yù)期執(zhí)行結(jié)果
return ftask;
}
此處的代碼關(guān)鍵是execute方法，它實現(xiàn)了三個職責(zé)械荷。
創(chuàng)建足夠多的工作線程數(shù)共耍，數(shù)量不超過最大線程數(shù)量，并保持線程處于運行或等待狀態(tài)吨瞎。
把等待處理的任務(wù)放到任務(wù)隊列中
從任務(wù)隊列中取出任務(wù)來執(zhí)行
其中此處的關(guān)鍵是工作線程的創(chuàng)建痹兜，它也是通過new Thread方式創(chuàng)建的一個線程，只是它創(chuàng)建的并不是我們的任務(wù)線程(雖然我們的任務(wù)實現(xiàn)了Runnable接口颤诀，但它只是起了一個標(biāo)志性的作用)字旭，而是經(jīng)過包裝的Worker線程，代碼如下：
private final class Worker implements Runnable {
// 運行一次任務(wù)
private void runTask(Runnable task) {
/* 這里的task才是我們自定義實現(xiàn)Runnable接口的任務(wù) */
task.run();
/* 該方法其它代碼略 */
}
// 工作線程也是線程着绊，必須實現(xiàn)run方法
public void run() {
try {
Runnable task = firstTask;
firstTask = null;
while (task != null || (task = getTask()) != null) {
runTask(task);
task = null;
}
} finally {
workerDone(this);
}
}
// 任務(wù)隊列中獲得任務(wù)
Runnable getTask() {
/* 其它代碼略 */
for (;;) {
return r = workQueue.take();
}
}
}
此處為示意代碼谐算，刪除了大量的判斷條件和鎖資源。execute方法是通過Worker類啟動的一個工作線程归露，執(zhí)行的是我們的第一個任務(wù)洲脂，然后改線程通過getTask方法從任務(wù)隊列中獲取任務(wù)，之后再繼續(xù)執(zhí)行剧包，但問題是任務(wù)隊列是一個BlockingQuene恐锦，是阻塞式的，也就是說如果該隊列的元素為0疆液，則保持等待狀態(tài)一铅，直到有任務(wù)進(jìn)入為止，我們來看LinkedBlockingQuene的take方法堕油，代碼如下：
public E take() throws InterruptedException {
E x;
int c = -1;
final AtomicInteger count = this.count;
final ReentrantLock takeLock = this.takeLock;
takeLock.lockInterruptibly();
try {
try {
// 如果隊列中的元素為0潘飘，則等待
while (count.get() == 0)
notEmpty.await();
} catch (InterruptedException ie) {
notEmpty.signal(); // propagate to a non-interrupted thread
throw ie;
}
// 等待狀態(tài)結(jié)束肮之，彈出頭元素
x = extract();
c = count.getAndDecrement();
// 如果隊列數(shù)量還多于一個，喚醒其它線程
if (c > 1)
notEmpty.signal();
} finally {
takeLock.unlock();
}
if (c == capacity)
signalNotFull();
// 返回頭元素
return x;
}
分析到這里卜录，我們就明白了線程池的創(chuàng)建過程：創(chuàng)建一個阻塞隊列以容納任務(wù)戈擒，在第一次執(zhí)行任務(wù)時創(chuàng)建做夠多的線程(不超過許可線程數(shù))，并處理任務(wù)艰毒，之后每個工作線程自行從任務(wù)對列中獲得任務(wù)筐高，直到任務(wù)隊列中的任務(wù)數(shù)量為0為止，此時丑瞧，線程將處于等待狀態(tài)柑土，一旦有任務(wù)再加入到隊列中，即召喚醒工作線程進(jìn)行處理绊汹，實現(xiàn)線程的可復(fù)用性稽屏。
使用線程池減少的是線程的創(chuàng)建和銷毀時間，這對于多線程應(yīng)用來說非常有幫助灸促，比如我們常用的Servlet容器诫欠，每次請求處理的都是一個線程，如果不采用線程池技術(shù)浴栽，每次請求都會重新創(chuàng)建一個新的線程荒叼，這會導(dǎo)致系統(tǒng)的性能符合加大，響應(yīng)效率下降典鸡，降低了系統(tǒng)的友好性被廓。
建議126：適時選擇不同的線程池來實現(xiàn)
Java的線程池實現(xiàn)從根本上來說只有兩個：ThreadPoolExecutor類和ScheduledThreadPoolExecutor類，這兩個類還是父子關(guān)系萝玷，但是Java為了簡化并行計算嫁乘，還提供了一個Exceutors的靜態(tài)類，它可以直接生成多種不同的線程池執(zhí)行器球碉，比如單線程執(zhí)行器蜓斧、帶緩沖功能的執(zhí)行器等，但歸根結(jié)底還是使用ThreadPoolExecutor類或ScheduledThreadPoolExecutor類的封裝類睁冬。
為了理解這些執(zhí)行器挎春，我們首先來看看ThreadPoolExecutor類，其中它復(fù)雜的構(gòu)造函數(shù)可以很好的理解線程池的作用豆拨，代碼如下：
public class ThreadPoolExecutor extends AbstractExecutorService {
// 最完整的構(gòu)造函數(shù)
public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize,
long keepAliveTime, TimeUnit unit,
BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory,
RejectedExecutionHandler handler) {
// 檢驗輸入條件
if (corePoolSize < 0 || maximumPoolSize <= 0
|| maximumPoolSize < corePoolSize || keepAliveTime < 0)
throw new IllegalArgumentException();
// 檢驗運行環(huán)境
if (workQueue == null || threadFactory == null || handler == null)
throw new NullPointerException();
this.corePoolSize = corePoolSize;
this.maximumPoolSize = maximumPoolSize;
this.workQueue = workQueue;
this.keepAliveTime = unit.toNanos(keepAliveTime);
this.threadFactory = threadFactory;
this.handler = handler;
}
}
這是ThreadPoolExecutor最完整的構(gòu)造函數(shù)直奋，其他的構(gòu)造函數(shù)都是引用該構(gòu)造函數(shù)實現(xiàn)的，我們逐步來解釋這些參數(shù)的含義施禾。
corePoolSize：最小線程數(shù)脚线。線程啟動后，在池中保持線程的最小數(shù)量弥搞。需要說明的是線程數(shù)量是逐步到達(dá)corePoolSize值的邮绿，例如corePoolSize被設(shè)置為10渠旁，而任務(wù)數(shù)量為5，則線程池中最多會啟動5個線程斯碌，而不是一次性的啟動10個線程一死。
maximumPoolSize：最大線程數(shù)量肛度。這是池中最大能容納的最大線程數(shù)量傻唾，如果超出，則使用RejectedExecutionHandler 拒絕策略處理承耿。
keepAliveTime：線程最大生命周期冠骄。這里的生命周期有兩個約束條件，一是該參數(shù)針對的是超過corePoolSize數(shù)量的線程加袋。二是處于非運行狀態(tài)的線程凛辣。這么說吧，如果corePoolSize為10职烧，maximumPoolSize為20扁誓，此時線程池中有15個線程正在運行，一段時間后蚀之，其中有3個線程處于等待狀態(tài)的時間超過了keepAliveTime指定的時間蝗敢，則結(jié)束這3個線程，此時線程池中還有12個線程正在運行足删。
unit：時間單位寿谴。這是keepAliveTime的時間單位，可以是納秒失受、毫秒讶泰、秒、分等選項拂到。
workQuene：任務(wù)隊列痪署。當(dāng)線程池中的線程都處于運行狀態(tài)，而此時任務(wù)數(shù)量繼續(xù)增加兄旬，則需要一個容器來容納這些任務(wù)狼犯，這就是任務(wù)隊列。
threadFactory：線程工廠辖试。定義如何啟動一個線程辜王，可以設(shè)置線程名稱，并且可以確認(rèn)是否是后臺線程等罐孝。
handler：拒絕任務(wù)處理器呐馆。由于超出線程數(shù)量和隊列容量而對繼續(xù)增加的任務(wù)進(jìn)行處理的程序。
線程池的管理是這樣一個過程：首先創(chuàng)建線程池莲兢，然后根據(jù)任務(wù)的數(shù)量逐步將線程增大到corePoolSize數(shù)量汹来，如果此時仍有任務(wù)增加续膳，則放置到workQuene中，直到workQuene爆滿為止收班，然后繼續(xù)增加池中的數(shù)量(增強(qiáng)處理能力)坟岔，最終達(dá)到maximumPoolSize，那如果此時還有任務(wù)增加進(jìn)來呢摔桦？這就需要handler處理了社付，或者丟棄任務(wù)，或者拒絕新任務(wù)邻耕，或者擠占已有任務(wù)等鸥咖。
在任務(wù)隊列和線程池都飽和的情況下，一但有線程處于等待(任務(wù)處理完畢兄世，沒有新任務(wù)增加)狀態(tài)的時間超過keepAliveTime啼辣，則該線程終止，也就說池中的線程數(shù)量會逐漸降低御滩，直至為corePoolSize數(shù)量為止鸥拧。
我們可以把線程池想象為這樣一個場景：在一個生產(chǎn)線上，車間規(guī)定是可以有corePoolSize數(shù)量的工人削解，但是生產(chǎn)線剛建立時富弦，工作不多，不需要那么多的人钠绍。隨著工作數(shù)量的增加舆声，工人數(shù)量也逐漸增加，直至增加到corePoolSize數(shù)量為止柳爽。此時還有任務(wù)增加怎么辦呢媳握？
好辦，任務(wù)排隊磷脯，corePoolSize數(shù)量的工人不停歇的處理任務(wù)蛾找，新增加的任務(wù)按照一定的規(guī)則存放在倉庫中(也就是我們的workQuene中)，一旦任務(wù)增加的速度超過了工人處理的能力赵誓，也就是說倉庫爆滿時打毛，車間就會繼續(xù)招聘工人(也就是擴(kuò)大線程數(shù))，直至工人數(shù)量到達(dá)maximumPoolSize為止俩功，那如果所有的maximumPoolSize工人都在處理任務(wù)時朽砰，而且倉庫也是飽和狀態(tài)惠险，新增任務(wù)該怎么處理呢乃沙？這就會扔一個叫handler的專門機(jī)構(gòu)去處理了猎塞，它要么丟棄這些新增的任務(wù)，要么無視蔓罚，要么替換掉別的任務(wù)椿肩。
過了一段時間后瞻颂，任務(wù)的數(shù)量逐漸減少，導(dǎo)致一部分工人處于待工狀態(tài)郑象，為了減少開支(Java是為了減少系統(tǒng)的資源消耗)贡这，于是開始辭退工人，直至保持corePoolSize數(shù)量的工人為止厂榛，此時即使沒有工作盖矫，也不再辭退工人(池中的線程數(shù)量不再減少)，這也是保證以后再有任務(wù)時能夠快速的處理噪沙。
明白了線程池的概念炼彪，我們再來看看Executors提供的幾個線程創(chuàng)建線程池的便捷方法：
newSingleThreadExecutor：單線程池。顧名思義就是一個池中只有一個線程在運行正歼，該線程永不超時，而且由于是一個線程拷橘，當(dāng)有多個任務(wù)需要處理時局义，會將它們放置到一個無界阻塞隊列中逐個處理，它的實現(xiàn)代碼如下：
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>()));
}
它的使用方法也很簡單冗疮，下面是簡單的示例：
public static void main(String[] args) throws ExecutionException,
InterruptedException {
// 創(chuàng)建單線程執(zhí)行器
ExecutorService es = Executors.newSingleThreadExecutor();
// 執(zhí)行一個任務(wù)
Future<String> future = es.submit(new Callable<String>() {
@Override
public String call() throws Exception {
return "";
}
});
// 獲得任務(wù)執(zhí)行后的返回值
System.out.println("返回值：" + future.get());
// 關(guān)閉執(zhí)行器
es.shutdown();
}
newCachedThreadPool：緩沖功能的線程萄唇。建立了一個線程池，而且線程數(shù)量是沒有限制的(當(dāng)然术幔，不能超過Integer的最大值)另萤，新增一個任務(wù)即有一個線程處理，或者復(fù)用之前空閑的線程诅挑，或者重親啟動一個線程四敞，但是一旦一個線程在60秒內(nèi)一直處于等待狀態(tài)時（也就是一分鐘無事可做），則會被終止拔妥，其源碼如下：
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());
}
這里需要說明的是忿危，任務(wù)隊列使用了同步阻塞隊列，這意味著向隊列中加入一個元素没龙，即可喚醒一個線程(新創(chuàng)建的線程或復(fù)用空閑線程來處理)铺厨，這種隊列已經(jīng)沒有隊列深度的概念了.
newFixedThreadPool：固定線程數(shù)量的線程池。 在初始化時已經(jīng)決定了線程的最大數(shù)量硬纤，若任務(wù)添加的能力超出了線程的處理能力解滓，則建立阻塞隊列容納多余的任務(wù)，其源碼如下：
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}
上面返回的是一個ThreadPoolExecutor筝家，它的corePoolSize和maximumPoolSize是相等的洼裤，也就是說，最大線程數(shù)量為nThreads肛鹏。如果任務(wù)增長的速度非骋莅睿快恩沛，超過了LinkedBlockingQuene的最大容量(Integer的最大值)，那此時會如何處理呢缕减？會按照ThreadPoolExecutor默認(rèn)的拒絕策略(默認(rèn)是DiscardPolicy雷客，直接丟棄)來處理。
以上三種線程池執(zhí)行器都是ThreadPoolExecutor的簡化版桥狡，目的是幫助開發(fā)人員屏蔽過得線程細(xì)節(jié)搅裙，簡化多線程開發(fā)。當(dāng)需要運行異步任務(wù)時裹芝，可以直接通過Executors獲得一個線程池部逮，然后運行任務(wù)，不需要關(guān)注ThreadPoolExecutor的一系列參數(shù)是什么含義嫂易。當(dāng)然兄朋，有時候這三個線程不能滿足要求，此時則可以直接操作ThreadPoolExecutor來實現(xiàn)復(fù)雜的多線程計算怜械÷停可以這樣比喻，newSingleThreadExecutor缕允、newCachedThreadPool峡扩、newFixedThreadPool是線程池的簡化版，而ThreadPoolExecutor則是旗艦版___簡化版容易操作障本，需要了解的知識相對少些教届，方便使用，而旗艦版功能齊全驾霜，適用面廣案训，難以駕馭。
建議127：Lock與synchronized是不一樣的
很多編碼者都會說寄悯，Lock類和synchronized關(guān)鍵字用在代碼塊的并發(fā)性和內(nèi)存上時語義是一樣的萤衰，都是保持代碼塊同時只有一個線程執(zhí)行權(quán)。這樣的說法只說對了一半猜旬，我們以一個任務(wù)提交給多個線程為例脆栋，來看看使用顯示鎖(Lock類)和內(nèi)部鎖(synchronized關(guān)鍵字)有什么不同，首先定義一個任務(wù)：
class Task {
public void doSomething() {
try {
// 每個線程等待2秒鐘洒擦，注意此時線程的狀態(tài)轉(zhuǎn)變?yōu)閃arning狀態(tài)
Thread.sleep(2000);
} catch (Exception e) {
// 異常處理
}
StringBuffer sb = new StringBuffer();
// 線程名稱
sb.append("線程名稱：" + Thread.currentThread().getName());
// 運行時間戳
sb.append(",執(zhí)行時間： " + Calendar.getInstance().get(Calendar.SECOND) + "s");
System.out.println(sb);
}
}
該類模擬了一個執(zhí)行時間比較長的計算椿争，注意這里是模擬方式，在使用sleep方法時線程的狀態(tài)會從運行狀態(tài)轉(zhuǎn)變?yōu)榈却隣顟B(tài)熟嫩。該任務(wù)具備多線程能力時必須實現(xiàn)Runnable接口秦踪，我們分別建立兩種不同的實現(xiàn)機(jī)制，先看顯示鎖實現(xiàn)：
class TaskWithLock extends Task implements Runnable {
// 聲明顯示鎖
private final Lock lock = new ReentrantLock();
@Override
public void run() {
try {
// 開始鎖定
lock.lock();
doSomething();
} finally {
// 釋放鎖
lock.unlock();
}
}
}
這里有一點需要說明，顯示鎖的鎖定和釋放必須放在一個try......finally塊中椅邓，這是為了確保即使出現(xiàn)異常也能正常釋放鎖柠逞，保證其它線程能順利執(zhí)行。
內(nèi)部鎖的處理也非常簡單景馁，代碼如下：
//內(nèi)部鎖任務(wù)
class TaskWithSync extends Task implements Runnable{
@Override
public void run() {
//內(nèi)部鎖
synchronized("A"){
doSomething();
}
}
}
這兩個任務(wù)看著非常相似板壮，應(yīng)該能夠產(chǎn)生相同的結(jié)果吧？我們建立一個模擬場景合住，保證同時有三個線程在運行绰精，代碼如下：
public class Test127 {
public static void main(String[] args) throws Exception {
// 運行顯示任務(wù)
runTasks(TaskWithLock.class);
// 運行內(nèi)部鎖任務(wù)
runTasks(TaskWithSync.class);
}
public static void runTasks(Class<? extends Runnable> clz) throws Exception {
ExecutorService es = Executors.newCachedThreadPool();
System.out.println("***開始執(zhí)行 " + clz.getSimpleName() + " 任務(wù)***");
// 啟動3個線程
for (int i = 0; i < 3; i++) {
es.submit(clz.newInstance());
}
// 等待足夠長的時間，然后關(guān)閉執(zhí)行器
TimeUnit.SECONDS.sleep(10);
System.out.println("---" + clz.getSimpleName() + " 任務(wù)執(zhí)行完畢---\n");
// 關(guān)閉執(zhí)行器
es.shutdown();
}
}
按照一般的理解透葛，Lock和synchronized的處理方式是相同的笨使，輸出應(yīng)該沒有差別，但是很遺憾的是僚害，輸出差別其實很大硫椰。輸出如下：
開始執(zhí)行 TaskWithLock 任務(wù)
線程名稱：pool-1-thread-2,執(zhí)行時間： 55s
線程名稱：pool-1-thread-1,執(zhí)行時間： 55s
線程名稱：pool-1-thread-3,執(zhí)行時間： 55s
---TaskWithLock 任務(wù)執(zhí)行完畢---
開始執(zhí)行 TaskWithSync 任務(wù)
線程名稱：pool-2-thread-1,執(zhí)行時間： 5s
線程名稱：pool-2-thread-3,執(zhí)行時間： 7s
線程名稱：pool-2-thread-2,執(zhí)行時間： 9s
---TaskWithSync 任務(wù)執(zhí)行完畢---
注意看運行的時間戳，顯示鎖是同時運行的贡珊，很顯然pool-1-thread-1線程執(zhí)行到sleep時最爬，其它兩個線程也會運行到這里，一起等待门岔，然后一起輸出，這還具有線程互斥的概念嗎烤送？
而內(nèi)部鎖的輸出則是我們預(yù)期的結(jié)果寒随，pool-2-thread-1線程在運行時其它線程處于等待狀態(tài)，pool-2-threda-1執(zhí)行完畢后帮坚，JVM從等待線程池中隨機(jī)獲的一個線程pool-2-thread-3執(zhí)行妻往，最后執(zhí)行pool-2-thread-2，這正是我們希望的试和。
現(xiàn)在問題來了：Lock鎖為什么不出現(xiàn)互斥情況呢讯泣？
這是因為對于同步資源來說(示例中的代碼塊)顯示鎖是對象級別的鎖，而內(nèi)部鎖是類級別的鎖阅悍，也就說說Lock鎖是跟隨對象的好渠，synchronized鎖是跟隨類的，更簡單的說把Lock定義為多線程類的私有屬性是起不到資源互斥作用的节视，除非是把Lock定義為所有線程的共享變量拳锚。都說代碼是最好的解釋語言，我們來看一個Lock鎖資源的代碼：
public static void main(String[] args) {
// 多個線程共享鎖
final Lock lock = new ReentrantLock();
// 啟動三個線程
for (int i = 0; i < 3; i++) {
new Thread(new Runnable() {
@Override
public void run() {
try {
lock.lock();
// 休眠2秒鐘
Thread.sleep(2000);
System.out.println(Thread.currentThread().getName());
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
}).start();
}
}
執(zhí)行時寻行，會發(fā)現(xiàn)線程名稱Thread-0霍掺、Thread-1、Thread-2會逐漸輸出，也就是一個線程在執(zhí)行時杆烁，其它線程就處于等待狀態(tài)牙丽。注意，這里三個線程運行的實例對象是同一個類兔魂。
除了這一點不同之外烤芦，顯示鎖和內(nèi)部鎖還有什么區(qū)別呢？還有以下4點不同：
Lock支持更細(xì)精度的鎖控制：假設(shè)讀寫鎖分離入热，寫操作時不允許有讀寫操作存在拍棕，而讀操作時讀寫可以并發(fā)執(zhí)行，這一點內(nèi)部鎖就很難實現(xiàn)勺良。顯示鎖的示例代碼如下：
class Foo {
// 可重入的讀寫鎖
private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
// 讀鎖
private final Lock r = rwl.readLock();
// 寫鎖
private final Lock w = rwl.writeLock();
// 多操作绰播，可并發(fā)執(zhí)行
public void read() {
try {
r.lock();
Thread.sleep(1000);
System.out.println("read......");
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
r.unlock();
}
}
// 寫操作，同時只允許一個寫操作
public void write() {
try {
w.lock();
Thread.sleep(1000);
System.out.println("write.....");
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
w.unlock();
}
}
}
可以編寫一個Runnable實現(xiàn)類尚困，把Foo類作為資源進(jìn)行調(diào)用(注意多線程是共享這個資源的)蠢箩，然后就會發(fā)現(xiàn)這樣的現(xiàn)象：讀寫鎖允許同時有多個讀操作但只允許一個寫操作，也就是當(dāng)有一個寫線程在執(zhí)行時事甜，所有的讀線程都會阻塞谬泌，直到寫線程釋放鎖資源為止，而讀鎖則可以有多個線程同時執(zhí)行逻谦。
2.Lock鎖是無阻塞鎖掌实，synchronized是阻塞鎖
當(dāng)線程A持有鎖時，線程B也期望獲得鎖邦马，此時贱鼻，如果程序中使用的顯示鎖，則B線程為等待狀態(tài)(在通常的描述中滋将，也認(rèn)為此線程被阻塞了)邻悬，若使用的是內(nèi)部鎖則為阻塞狀態(tài)。
3.Lock可實現(xiàn)公平鎖随闽，synchronized只能是非公平鎖
什么叫非公平鎖呢父丰？當(dāng)一個線程A持有鎖，而線程B掘宪、C處于阻塞(或等待)狀態(tài)時蛾扇，若線程A釋放鎖，JVM將從線程B添诉、C中隨機(jī)選擇一個持有鎖并使其獲得執(zhí)行權(quán)屁桑，這叫非公平鎖(因為它拋棄了先來后到的順序)；若JVM選擇了等待時間最長的一個線程持有鎖栏赴，則為公平鎖(保證每個線程的等待時間均衡)蘑斧。需要注意的是，即使是公平鎖，JVM也無法準(zhǔn)確做到" 公平 "竖瘾，在程序中不能以此作為精確計算沟突。
顯示鎖默認(rèn)是非公平鎖，但可以在構(gòu)造函數(shù)中加入?yún)?shù)為true來聲明出公平鎖捕传，而synchronized實現(xiàn)的是非公平鎖惠拭，他不能實現(xiàn)公平鎖。
4.Lock是代碼級的庸论，synchronized是JVM級的
Lock是通過編碼實現(xiàn)的职辅，synchronized是在運行期由JVM釋放的，相對來說synchronized的優(yōu)化可能性高聂示，畢竟是在最核心的部分支持的域携，Lock的優(yōu)化需要用戶自行考慮。
顯示鎖和內(nèi)部鎖的功能各不相同鱼喉，在性能上也稍有差別秀鞭，但隨著JDK的不斷推進(jìn)，相對來說扛禽，顯示鎖使用起來更加便利和強(qiáng)大锋边，在實際開發(fā)中選擇哪種類型的鎖就需要根據(jù)實際情況考慮了：靈活、強(qiáng)大選擇lock编曼，快捷豆巨、安全選擇synchronized.
建議128：預(yù)防線程死鎖
線程死鎖(DeadLock)是多線程編碼中最頭疼的問題，也是最難重現(xiàn)的問題掐场，因為Java是單進(jìn)程的多線程語言搀矫，一旦線程死鎖，則很難通過外科手術(shù)的方法使其起死回生刻肄，很多時候只有借助外部進(jìn)程重啟應(yīng)用才能解決問題，我們看看下面的多線程代碼是否會產(chǎn)生死鎖：
class Foo implements Runnable {
@Override
public void run() {
fun(10);
}
// 遞歸方法
public synchronized void fun(int i) {
if (--i > 0) {
for (int j = 0; j < i; j++) {
System.out.print("*");
}
System.out.println(i);
fun(i);
}
}
}
注意fun方法是一個遞歸函數(shù)融欧，而且還加上了synchronized關(guān)鍵字敏弃，它保證同時只有一個線程能夠執(zhí)行，想想synchronized關(guān)鍵字的作用：當(dāng)一個帶有synchronized關(guān)鍵字的方法在執(zhí)行時噪馏，其他synchronized方法會被阻塞麦到，因為線程持有該對象的鎖，比如有這樣的代碼:
class Foo1 {
public synchronized void m1() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// 異常處理
}
System.out.println("m1方法執(zhí)行完畢");
}
public synchronized void m2() {
System.out.println("m2方法執(zhí)行完畢");
}
}
相信大家都明白欠肾，先輸出"m1執(zhí)行完畢"瓶颠，然后再輸出"m2"執(zhí)行完畢，因為m1方法在執(zhí)行時刺桃，線程t持有foo對象的鎖粹淋，要想主線程獲得m2方法的執(zhí)行權(quán)限就必須等待m1方法執(zhí)行完畢，也就是釋放當(dāng)前鎖。明白了這個問題桃移，我們思考一下上例中帶有synchronized的遞歸方法是否能執(zhí)行屋匕？會不會產(chǎn)生死鎖？運行結(jié)果如下：
*********9
********8
*******7
******6
*****5
****4
3
2
1
一個倒三角形借杰，沒有產(chǎn)生死鎖过吻，正常執(zhí)行，這是為何呢蔗衡？很奇怪纤虽，是嗎？那是因為在運行時當(dāng)前線程(Thread-0)獲得了Foo對象的鎖(synchronized雖然是標(biāo)注在方法上的绞惦，但實際作用是整個對象)逼纸，也就是該線程持有了foo對象的鎖，所以它可以多次重如fun方法翩隧，也就是遞歸了樊展。可以這樣來思考該問題堆生，一個包廂有N把鑰匙专缠，分別由N個海盜持有 (也就是我們Java的線程了)，但是同一時間只能由一把鑰匙打開寶箱淑仆，獲取寶物涝婉，只有在上一個海盜關(guān)閉了包廂(釋放鎖)后，其它海盜才能繼續(xù)打開獲取寶物蔗怠，這里還有一個規(guī)則：一旦一個海盜打開了寶箱墩弯，則該寶箱內(nèi)的所有寶物對他來說都是開放的，即使是“ 寶箱中的寶箱”(即內(nèi)箱)對他也是開放的寞射∮婀ぃ可以用如下代碼來表示：
class Foo2 implements Runnable{
@Override
public void run() {
method1();
}
public synchronized void method1(){
method2();
}
public synchronized void method2(){
//doSomething
}
}
方法method1是synchronized修飾的，方法method2也是synchronized修飾的桥温，method1和method2方法重入完全是可行的引矩，此種情況下會不會產(chǎn)生死鎖。
那什么情況下回產(chǎn)生死鎖呢侵浸？看如下代碼：
class A {
public synchronized void a1(B b) {
String name = Thread.currentThread().getName();
System.out.println(name + " 進(jìn)入A.a1()");
try {
// 休眠一秒 仍持有鎖
Thread.sleep(1000);
} catch (Exception e) {
// 異常處理
}
System.out.println(name + " 試圖訪問B.b2()");
b.b2();
}
public synchronized void a2() {
System.out.println("進(jìn)入a.a2()");
}
}
class B {
public synchronized void b1(A a) {
String name = Thread.currentThread().getName();
System.out.println(name + " 進(jìn)入B.b1()");
try {
// 休眠一秒 仍持有鎖
Thread.sleep(1000);
} catch (Exception e) {
// 異常處理
}
System.out.println(name + " 試圖訪問A.a2()");
a.a2();
}
public synchronized void b2() {
System.out.println("進(jìn)入B.b2()");
}
}
public static void main(String[] args) throws InterruptedException {
final A a = new A();
final B b = new B();
// 線程A
new Thread(new Runnable() {
@Override
public void run() {
a.a1(b);
}
}, "線程A").start();
// 線程B
new Thread(new Runnable() {
@Override
public void run() {
b.b1(a);
}
}, "線程B").start();
}
此段程序定義了兩個資源A和B旺韭，然后在兩個線程Ａ、B中使用了該資源掏觉，由于兩個資源之間交互操作区端，并且都是同步方法，因此在線程A休眠一秒鐘后澳腹，它會試圖訪問資源B的b2方法织盼。但是B線程持有該類的鎖杨何，并同時在等待A線程釋放其鎖資源，所以此時就出現(xiàn)了兩個線程在互相等待釋放資源的情況悔政，也就是死鎖了晚吞，運行結(jié)果如下：
線程A 進(jìn)入A.a1()
線程B 進(jìn)入B.b1()
線程A 試圖訪問B.b2()
線程B 試圖訪問A.a2()
此種情況下，線程A和線程B會一直等下去谋国，直到有外界干擾為止槽地，比如終止一個線程，或者某一線程自行放棄資源的爭搶芦瘾，否則這兩個線程就始終處于死鎖狀態(tài)了捌蚊。我們知道達(dá)到線程死鎖需要四個條件：
互斥條件：一個資源每次只能被一個線程使用
資源獨占條件：一個線程因請求資源在未使用完之前，不能強(qiáng)行剝奪
不剝奪條件：線程已經(jīng)獲得的資源在未使用完之前近弟，不能強(qiáng)行剝奪
循環(huán)等待條件：若干線程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系
只有滿足了這些條件才能產(chǎn)生線程死鎖缅糟，這也同時告誡我們?nèi)绻鉀Q線程死鎖問題，就必須從這四個條件入手祷愉，一般情況下可以按照以下兩種方案解決：
(1)窗宦、避免或減少資源共享
一個資源被多個線程共享，若采用了同步機(jī)制二鳄，則產(chǎn)生死鎖的可能性大赴涵，特別是在項目比較龐大的情況下，很難杜絕死鎖订讼，對此最好的解決辦法就是減少資源共享髓窜。
例如一個B/S結(jié)構(gòu)的辦公系統(tǒng)可以完全忽略資源共享，這是因為此類系統(tǒng)有三個特征：一是并發(fā)訪問不會太高欺殿，二是讀操作多于寫操作寄纵，三是數(shù)據(jù)質(zhì)量要求比較低，因此即使出現(xiàn)數(shù)據(jù)資源不同步的情況也不可能產(chǎn)生太大影響脖苏，完全可以不使用同步技術(shù)程拭。但是如果是一個支付清算系統(tǒng)就必須慎重考慮資源同步問題了，因為此系統(tǒng)一是數(shù)據(jù)質(zhì)量要求非常高(如果產(chǎn)生數(shù)據(jù)不同步的情況那可是重大生產(chǎn)事故)棍潘，二是并發(fā)量大哺壶，不設(shè)置數(shù)據(jù)同步則會產(chǎn)生非常多的運算邏輯失效的情況，這會導(dǎo)致交易失敗蜒谤，產(chǎn)生大量的"臟數(shù)據(jù)",系統(tǒng)可靠性大大降低。
(2)至扰、使用自旋鎖
回到前面的例子鳍徽，線程A在等待線程B釋放資源，而線程B又在等待線程A釋放資源敢课，僵持不下阶祭，那如果線程B設(shè)置了超時時間是不是就可以解決該死鎖問題了呢绷杜？比如線程B在等待2秒后還是無法獲得資源，則自行終結(jié)該任務(wù)濒募，代碼如下：
public void b2() {
try {
// 立刻獲得鎖鞭盟，或者2秒等待鎖資源
if (lock.tryLock(2, TimeUnit.SECONDS)) {
System.out.println("進(jìn)入B.b2()");
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
上面的代碼中使用tryLock實現(xiàn)了自旋鎖(Spin Lock)，它跟互斥鎖一樣瑰剃，如果一個執(zhí)行單元要想訪問被自旋鎖保護(hù)的共享資源齿诉，則必須先得到鎖，在訪問完共享資源后晌姚，也必須釋放鎖粤剧。如果在獲取自旋鎖時，沒有任何執(zhí)行單元保持該鎖挥唠，那么將立即得到鎖抵恋；如果在獲取自旋鎖時已經(jīng)有保持者，那么獲取鎖操作將"自旋" 在哪里宝磨，直到該自旋鎖的保持者釋放了鎖為止弧关，在我們的例子中就是線程A等待線程B釋放鎖，在2秒內(nèi) 不斷嘗試是否能夠獲得鎖唤锉，達(dá)到2秒后還未獲得鎖資源世囊，線程A則結(jié)束運行，線程B將獲得資源繼續(xù)執(zhí)行腌紧，死鎖解除茸习。
對于死鎖的描述最經(jīng)典的案例是哲學(xué)家進(jìn)餐(五位哲學(xué)家圍坐在圓形餐桌旁，人手一根筷子壁肋，做一下兩件事情：吃飯和思考号胚。要求吃東西的時候停止思考，思考的時候停止吃東西浸遗，而且必須使用兩根筷子才能吃東西)猫胁，解決此問題的方法很多，比如引入服務(wù)生(資源地調(diào)度)跛锌、資源分級等方法都可以很好的解決此類死鎖問題弃秆。在我們Java多線程并發(fā)編程中，死鎖很難避免髓帽，也不容易預(yù)防菠赚，對付它的最好方法就是測試：提高測試覆蓋率，建立有效的邊界測試郑藏，加強(qiáng)資源監(jiān)控衡查，這些方法能使得死鎖無可遁形，即使發(fā)生了死鎖現(xiàn)象也能迅速查到原因必盖，提高系統(tǒng)性能拌牲。
建議129: 適當(dāng)設(shè)置租在隊列長度
阻塞隊列BlockingQueue擴(kuò)展了Queue,Collection接口,對元素的插入和提取使用了"阻塞"處理,我們知道Collection下的實現(xiàn)類一般都采用了長度自增的自行管理方式(也就是變長) 比如這樣的代碼是可以正常運行的:
public class Test129 {
public static void main(String[] args) {
//定義初始長度為5
List<String> list = new ArrayList<String>();
//加入10個元素
for (int i = 0; i < 10; i++) {
list.add("");
}
}
}
上述代碼定義了列表的初始長度為5,在實際使用的時候,當(dāng)加入的元素超過起初容量的時候,ArrayList會自動擴(kuò)容,確保能夠正常加入元素,.那BlockingQueue也是集合,也實現(xiàn)了Collection接口,它的容量是否會自行管理呢?我們來看代碼:
public class Test129 {
public static void main(String[] args) {
//定義初始長度為 5
BlockingQueue<String> bq = new ArrayBlockingQueue<String>(5);
//加入10個元素
for (int i = 0; i < 10; i++) {
bq.add("");
}
}
}
打印結(jié)果報錯
Exception in thread "main" java.lang.IllegalStateException: Queue full
at java.util.AbstractQueue.add(Unknown Source)
at java.util.concurrent.ArrayBlockingQueue.add(Unknown Source)
at cn.icanci.test_151.Test129.main(Test129.java:23)
顯然,BlockingQueue是不可以自行擴(kuò)容的.隊列報錯已滿異常.這是非阻塞隊列和阻塞隊列的一個重要區(qū)別,非阻塞隊列是看可以變長的.阻塞隊列在聲明的時候就要聲明隊列的容量,若指定的容量,則元素不可以超過此容量,若不指定,默認(rèn)值是Integer 的最大值.
阻塞隊列和非阻塞隊列有此區(qū)別的原因是阻塞隊列是了容納(或排序)多線程任務(wù)而存在的,其服務(wù)的對象是多線程應(yīng)用,而非阻塞的隊列容納的是普通的數(shù)據(jù)元素.我們看一下ArrayBolckingQueue類最常用的add方法
public boolean add(E e) {
if (offer(e))
return true;
else
throw new IllegalStateException("Queue full");
}
public boolean offer(E e) {
checkNotNull(e);
final ReentrantLock lock = this.lock;
lock.lock();
try {
if (count == items.length)
return false;
else {
enqueue(e);
return true;
}
} finally {
lock.unlock();
}
}
上面在增加元素的時候,如果判斷隊列已經(jīng)滿了,就返回false,表示插入失敗,之后再包裝成隊列滿異常.此處需要注意offer方法,如果我們直調(diào)用offer方法插入元素,再超出容量的情況下,除了會返回false,不會有其他的提示信息,那就會造成數(shù)據(jù)的"默默丟失",這就是它與非阻塞隊列的不同之處.
阻塞隊列對于這種機(jī)制的異步計算是非常有幫助的,例如我們定義深度為100的阻塞隊列容納100個任務(wù),多個線程從該隊列中獲取任務(wù)并處理,當(dāng)所有的線程都在繁忙,并且隊列中的數(shù)量已經(jīng)是100的時候,也就預(yù)示這系統(tǒng)壓力很大,而且處理結(jié)果的返回時間也比較長,于是滴101個想要加入的時候,隊列拒絕加入,并且返回異常.有系統(tǒng)自行處理,避免了運算的不可知性,但是如果應(yīng)用期望無論等待多久都要運行該任務(wù),不希望返回異常,那么應(yīng)該怎么處理呢?
此時就需要使用BlockingQueue接口定義的put方法了,它的作用就是把元素加入到隊列中,但是它和add,offer方法不同,他會等待隊列空出元素,,然后再把自己加入進(jìn)去
public void put(E e) throws InterruptedException {
checkNotNull(e);
final ReentrantLock lock = this.lock;
lock.lockInterruptibly();
try {
while (count == items.length)
notFull.await();
enqueue(e);
} finally {
lock.unlock();
}
}
pue的目的就是確保元素肯定會加入到隊列中去,.問題是此種等待是一個循環(huán),會不停止的消耗系統(tǒng)資源.怎么解決呢?JDK已經(jīng)想到了這個問題,它提供了有超時時間的offer方法.實現(xiàn)方法和put類似.只是使用Condition的awaitNanos方法來判斷當(dāng)前線程已經(jīng)等待了多少納秒.超時就返回false.
與插入元素對應(yīng),去除元素也有不同的實現(xiàn)
建議130: 使用CountDownLatch協(xié)調(diào)子線程
思考這樣的一個案例:百米賽跑,多個參加賽跑的人員在聽到強(qiáng)聲命令時候,就開始跑步,到達(dá)終點時候結(jié)束計時,然后統(tǒng)計平均成績.這里有兩點需要考慮:一是發(fā)令槍響,所有的跑步
步者(線程)接收到的出發(fā)信號俱饿，此處涉及裁判(主線程)如何通知跑步者( 子線程)的問題;二是如何獲知所有的跑步者完成了賽跑，也就是主線程如何知道子線程已經(jīng)全部完成塌忽，這有很多種實現(xiàn)方式拍埠，此處我們使用CountDownLatch工具類來實現(xiàn)，代碼如下:
static class Runner implements Callable<Integer> {
//開始信號
private CountDownLatch begin;//結(jié)束信號
private CountDownLatch end;
public Runner (CountDownLatch. _begin, CountDownLatch_ end) {
begin =_ _begin;end =_ end;
@Override
public Integer call() throws Exception {
//跑步的成績
int score = new Random() .nextInt (25) i//等待發(fā)令槍響起begin.awalt() ;//跑步中......
TimeUnit . MILLISECONDS . sleep (score) ;//跑步者已經(jīng)跑完全程end. countDown() ;return score;
}}
public static void main (String (] args) throws Exception{
int num = 10;
CountDownLatch begin = new Coun tDownLatch (1) ;
CountDownLatch end =new CountDownLatch (num)
ExecutorService es = Executors . newFixedThreadPool (num) ;
List<Future<Integer? futures = new ArrayList<Future< Integer?() ;
for(inti=0;i<num; i++)
futures . add (es. submit (new Runner (begin, end))) ;)
begin . countDown() ;
end.await() ;
int count = 0;
for(Future<Integer> f : futures){
count += f,get();
}
System.out,println(count/num);
}
CountDownLatch類是一個倒數(shù)的同步計數(shù)器土居，在程序中啟動了兩個計數(shù)器: -一個是開始計數(shù)器begin,表示的是發(fā)令槍:另外是結(jié)束計數(shù)器枣购，- - 共有10個，表示的是每個線程的執(zhí)行情況装盯，也就是跑步者是否跑完比賽坷虑。程序執(zhí)行邏輯如下:
1)10 個線程都開始運行，執(zhí)行到begin.await 后線程阻塞埂奈，等待begin的計數(shù)變?yōu)?.
2)主線程調(diào)用begin的countDown方法迄损，使begin的計數(shù)器為0
3)10個線程繼續(xù)運行。
4)主線程繼續(xù)運行下一個語句账磺，end的計數(shù)器不為0,主線程等待芹敌。
5)每個線程運行結(jié)束時把end的計數(shù)器減1,標(biāo)志著本線程運行完畢。
6)10個線程全部結(jié)束垮抗，end 計數(shù)器為0氏捞。
7)主線程繼續(xù)執(zhí)行，打印出成績平均值冒版。
CountDownLatch的作用是控制一個計數(shù)器液茎，每個線程在運行完畢后會執(zhí)行countDown,表示自己運行結(jié)束，這對于多個子任務(wù)的計算特別有效辞嗡，比如一一個異步任務(wù)需要拆分成10個子任務(wù)執(zhí)行捆等，主任務(wù)必須要知道子任務(wù)是否完成，所有子任務(wù)完成后才能進(jìn)行合并計算,從而保證了一個主任務(wù)的邏輯正確性续室。這和我們的實際工作非常類似栋烤，比如領(lǐng)導(dǎo)安排了一個大任務(wù)給我，我一一個人不可能完成挺狰，于是我把該任務(wù)分解給10個人做明郭，在10個人全部完成后，我把這10個結(jié)果組合起來返回給領(lǐng)導(dǎo)一這 就是CountDownLatch的作用丰泊。
建議131: CyclicBarrier讓多線程同步
思考這樣-一個案例:兩個工人從兩端挖掘隧道薯定，各自獨立奮戰(zhàn)，中間不溝通瞳购，如果兩人在匯合點處碰頭了沉唠，則表明隧道已經(jīng)挖通。這描繪的也是在多線程編程中苛败，兩個線程獨立運行满葛，在沒有線程間通信的情況下，如何解決兩個線程匯集在同一原點的問題罢屈。Java提供了CyclicBarrier (關(guān)卡嘀韧，也有翻譯為柵欄)工具類來實現(xiàn)，代碼如下:
static class Worker implements Runnable {
// 關(guān)卡
private CyclicBarrier cb;
public Worker (CyclicBarrier. cb) {
cb =_ cb;
}
public void run() {
try {
Thread . sleep (new Random() .nextInt (1000)) ;
System. out . print1n (Thread. currentThread() .getName() + "- 到達(dá)匯合點");
//到達(dá)匯合點cb. avait() 1
} catch (Exception e) {
//異常處理
}
public static void main (String[] args) throws Exception {
//設(shè)置匯集數(shù)量缠捌，以及匯集完成后的任務(wù)
CyclicBarrier cb = new cyclicBarrier(2, new Runnab1e() {
public void run(){
System. out . print1n("隧道巳經(jīng)打通! ");
}
});
//工人1挖隧道
new Thread (new Worker(cb),"工人1") .start() ;//工人2挖隧道
new Thread (new Worker(cb), "工人2") .start() ;
}
在這段程序中锄贷，定義了一個需要等待2個線程匯集的CyclicBarrier關(guān)卡，并且定義了完成匯集后的任務(wù)(輸出“隧道已經(jīng)打通!”)曼月，然后啟動了2個線程(也就是2個工人)開始執(zhí)行任務(wù)谊却。代碼邏輯如下:
- 2個線程同時開始運行，實現(xiàn)不同的任務(wù)哑芹，執(zhí)行時間不同炎辨。
2)“工人1”線程首先到達(dá)匯合點(也就是cb.await語句)，轉(zhuǎn)變?yōu)榈却隣顟B(tài)聪姿。
3)“工人2”線程到達(dá)匯合點碴萧，滿足預(yù)先的關(guān)卡條件(2 個線程到達(dá)關(guān)卡)，繼續(xù)執(zhí)行末购。此時還會額外的執(zhí)行兩個動作:執(zhí)行關(guān)卡任務(wù)(也就是run方法)和喚醒“工人1”線程破喻。
4)“工人1”線程繼續(xù)執(zhí)行扫茅。
CyclicBarrier關(guān)卡可以讓所有線程全部處于等待狀態(tài)( 阻塞)房铭，然后在滿足條件的情況下繼續(xù)執(zhí)行糊治，這就好比是一條起跑線艾疟，不管是如何到達(dá)起跑線的怀喉，只要到達(dá)這條起跑線就必須等待其他人員犬性，待人員到齊后再各奔東西泥耀，CyclicBarrier 關(guān)注的是匯合點的信息艾船，而不在乎之前或之后做何處理顶籽。
CyclicBarrier可以用在系統(tǒng)的性能測試中玩般，例如我們編寫了-一個核心算法，但不能確定其可靠性和效率如何礼饱，我們就可以讓N個線程匯集到測試原點上坏为，然后“一聲令下”，所有的線程都引用該算法镊绪，即可觀察出算法是否有缺陷匀伏。
第十章 性能和效率
在這個快餐時代，系統(tǒng)一直在提速蝴韭， 從未停步過够颠，從每秒百萬條指令的CPU到現(xiàn)在的每秒萬億條指令的多核CPU,從最初發(fā)布一個帖子需要等待N小時才有回復(fù)到現(xiàn)在的微博，一個消息在幾分鐘內(nèi)就可以傳遍全球;從N天才能完成的一-次轉(zhuǎn)賬交易榄鉴，到現(xiàn)在的即時轉(zhuǎn)賬-一我們進(jìn)入了一個光速 發(fā)展的時代履磨，我們享受著蛉抓，也在被追逐著一榨干硬件資源， 加速所有能加速的剃诅，提升所有能提升的巷送。
建議132: 提升Java性能的基本方法
Java從誕生之日起就被質(zhì)疑:字節(jié)碼在JVM中運行是否會比機(jī)器碼直接運行的效率會低很多?很多技術(shù)高手、權(quán)威網(wǎng)站都有類似的測試和爭論矛辕，從而來表明Java比C (或C++)更快或效率相同笑跛。此類話題我們暫且不表(這類問題的爭論沒完沒了，也許等到我們退休的時候聊品，還想找個活動腦筋的方式飞蹂，此類問題就會是最好的選擇)，我們先從如何提高Java的性能方面入手翻屈，看看怎么做才能讓Java程序跑得更快陈哑，效率更高，吞吐量更大妖胀。
(1)不要在循環(huán)條件中計算
如果在循環(huán)(如for循環(huán)芥颈、while 循環(huán))條件中計算，則每循環(huán)- -遍就要計算一次赚抡，這會降低系統(tǒng)效率爬坑，就比如這樣的代碼:
//每次循環(huán)都要計算count*2
while (i<count*2){
//Do Something
}
//應(yīng)該替換為: .1/只計算- -遍
int total =count * 2;
while (1<tota1){
//DO something
}
(2)盡可能把變量、方法聲明為final static 類型假設(shè)要將阿拉伯?dāng)?shù)字轉(zhuǎn)換為中文數(shù)字涂臣，其定義如下:
public String toChineseNum(int num) {
//中文數(shù)字
string[] cns ={"零","查","貳","塞","肆","伍","陸","柒","制","玖"};
return cns [num] :
}
每次調(diào)用該方法時都會重新生成-一個cns數(shù)組盾计，注意該數(shù)組不會改變，屬于不變數(shù)組,在這種情況下赁遗，把它聲明為類變量署辉，并且加上final static修飾會更合適，在類加載后就生成了該數(shù)組岩四，每次方法調(diào)用則不再重新生成數(shù)組對象了哭尝，這有助于提高系統(tǒng)性能，代碼如下剖煌。
(3)縮小變量的作用范圍
關(guān)于變量材鹦，能定義在方法內(nèi)的就定義在方法內(nèi)，能定義在-一個循環(huán)體內(nèi)的就定義在循環(huán)體內(nèi)耕姊，能放置在一個t.y...c.塊內(nèi)的就放置在該塊內(nèi)桶唐，其目的是加快GC的回收。
(4)頻繁字符串操作使用StringBuilder或StringBuffer
雖然String的聯(lián)接操作(“+”號)已經(jīng)做了很多優(yōu)化茉兰，但在大量的追加操作上StringBuilder或StringBuffer還是比“+”號的性能好很多尤泽，例如這樣的代碼:
String str = "Log file 1s read......";
for(int i=0;i<max;i++){
//此處生成三個對象
str += "1og"+ i;
應(yīng)該修改為:
StringBuilder sb = nev stringBuilder (20000) ;8b. append("Log file is ready......");
for(int i=0;i<max;i++){
eb.append("log”+ 1);
string 1og = sb. tostring();
(5)使用非線性檢索
如果在ArrayList中存儲了大量的數(shù)據(jù)，使用indexOf查找元素會比java.utils. Collections.binarySearch的效率低很多，原因是binarySearch是二分搜索法坯约，而indexOf使用的是逐個元素比對的方法熊咽。這里要注意:使用binarySearch搜索時，元素必須進(jìn)行排序闹丐，否則準(zhǔn)確性就不可靠了网棍。
(6)覆寫Exception的flInStackTrace方法
我們在第8章中提到flInStackTrace方法是用來記錄異常時的棧信息的，這是非常耗時的動作妇智，如果我們在開發(fā)時不需要關(guān)注棧信息，則可以覆蓋之氏身，如下覆蓋flInStackTrace的自定義異常會使性能提升10倍以上:
class MyException extends Exception {
public Throwable fillInStackTrace1) {
return this;
}
(7)不建立冗余對象
不需要建立的對象就不能建立巍棱，說起來很容易，要完全遵循此規(guī)則難度就很大了蛋欣，我們經(jīng)常就會無意地創(chuàng)建冗余對象航徙，例如這樣- - 段代碼:
public void doSomething() {
//異常信息
string exceptionMeg = "我出現(xiàn)異常了，快來就救我! ";try {
Thread. sleep(10) ;} catch (Exception e) {
//轉(zhuǎn)換為自定又運行期異常
throw new MyException (e, exceptionMeg) ;
}
注意看變量exceptionMsg陷虎，這個字符串變量在什么時候會被用到?只有在拋出異常時它才有用武之地到踏，那它是什么時候創(chuàng)建的呢?只要該方法被調(diào)用就創(chuàng)建，不管會不會拋出異常尚猿。我們知道異常不是我們的主邏輯窝稿，不是我們代碼必須或經(jīng)常要到達(dá)的區(qū)域，那為了這個不經(jīng)常出現(xiàn)的場景就每次都多定義-一個字符串變量凿掂，合適嗎?而且還要占用更多的內(nèi)存!所以伴榔，在catch塊中定義exceptionMsg方法才是正道:需要的時候才創(chuàng)建對象。
我們知道運行一-段程序需要三種資源: CPU庄萎、內(nèi)存踪少、I/O， 提升CPU的處理速度可以加快代碼的執(zhí)行速度糠涛，直接表現(xiàn)就是返回時間縮短了援奢，效率提高了:內(nèi)存是Java程序必須考慮的問題，在32位的機(jī)器上忍捡，一個JVM最多只能使用2GB的內(nèi)存集漾，而且程序占用的內(nèi)存越大，尋址效率也就越低锉罐，這也是影響效率的-一個因素帆竹。I/O 是程序展示和存儲數(shù)據(jù)的主要通道，如果它很緩慢就會影響正常的顯示效果脓规。所以我們在編碼時需要從這三個方面入手接口(當(dāng)然了栽连，任何程序優(yōu)化都是從這三方面入手的)。
Java的基本優(yōu)化方法非常多，這里不再羅列秒紧，相信讀者也有自己的小本本绢陌，上面所 羅列的性能優(yōu)化方法可能遠(yuǎn)比這里多，但是隨著Java的不斷升級熔恢，很多看似很正確的優(yōu)化策略就逐漸過時了(或者說已經(jīng)失效了)脐湾，這一點還需要讀者注意。最基本的優(yōu)化方法就是自我驗證叙淌，找出最佳的優(yōu)化途徑秤掌，提高系統(tǒng)性能，不可盲目信任鹰霍。
建議133: 若非必要,不要克隆對象
通過clone方法生成一個對象時闻鉴，就會不再執(zhí)行構(gòu)造函數(shù)了，只是在內(nèi)存中進(jìn)行數(shù)據(jù)塊的拷貝茂洒，此方法看上去似乎應(yīng)該比new方法的性能好很多孟岛，但是Java的締造者們也認(rèn)識到“二八原則”，80% (甚至更多)的對象是通過new關(guān)鍵字創(chuàng)建出來的督勺，所以對new在生成對象(分配內(nèi)存渠羞、初始化)時做了充分的性能優(yōu)化，事實上智哀，一般情況下new生成的對象比clone生成的性能方面要好很多次询，例如這樣的代碼。
private static class Apple implements C1oneable [
public Object c1one() l
try (
return super .clone() ;
}
catch (C1 oneNot SupportedException e) (
throw new Error() ;
public static void main(Stringl) args) {
final int maxLoops = 10 * 10000;int 1oops = 0;11????
long start = System. nanoTime() ;11 "?"*4
Apple apple = new Apple() ;while (++1oaps < maxLoops) l
app1e.c1one();
long mid = System. nanoTime() ;
System. out. println("clone: " + (mid - start) + " ns");
while (--loaps > 0) {
new Apple() ;
}
long end = System. nanoTime() ;
System. out . print1n("new: " + (end - mid) + " ns");
在上面的代碼中盏触，Apple 是一個簡單的可拷貝類渗蟹，用兩種方式生成了10萬個蘋果:一種是通過克隆技術(shù)，-種是通過直接種植( 也就是new關(guān)鍵字)赞辩，按照我們的常識想當(dāng)然地會認(rèn)為克隆肯定比new要快雌芽，但是結(jié)果卻是這樣的:
clone方法生成對象耗時: 18731431 ns
new生成對象耗時: 2391924 ns
不用看具體的數(shù)字，數(shù)數(shù)位數(shù)就可以了:clone方法花費的時間是8位數(shù)辨嗽，而new方法是7位數(shù)世落，用new生成對象比clone方法快很多!原因是Apple的構(gòu)造函數(shù)非常簡單，而且JVM對new做了大量的性能優(yōu)化糟需，而clone方式只是一個冷僻的生成對象方式屉佳，并不是主流，它主要用于構(gòu)造函數(shù)比較復(fù)雜洲押，對象屬性比較多武花，通過new關(guān)鍵字創(chuàng)建-一個對象比較耗時間的時候。
注意 克隆對象并不比直接生成對象效率高杈帐。
建議134: 推薦使用""望聞問切的方式診斷性能
“望聞問切”是中醫(yī)診斷疾病的必經(jīng)步驟体箕，“望”是指觀氣色专钉，“聞”是指聽聲息，“問”.是指詢問癥狀累铅，“切”是指摸脈象跃须，合稱“四診”，經(jīng)過這四個步驟娃兽，大夫基本上就能確認(rèn)病癥所在菇民，然后加以藥物調(diào)理，或能還以病人健康身軀投储。
-個應(yīng)用系統(tǒng)如果出現(xiàn)性能問題第练，不管是偶發(fā)性問題還是持久性問題，都是系統(tǒng)“生病”的表現(xiàn)玛荞，需要工程師去診斷复旬，然后對癥下藥。我們可以把Java的性能診斷也分為此四個過程(把我們自己想象成醫(yī)生吧冲泥，只是我們的英文名字不叫Doctor,而是叫做TroubleShooter) :
(1)望
觀察性能問題的癥狀。有人投訴我們開發(fā)出的系統(tǒng)性能慢壁涎，如蝸牛爬行凡恍，執(zhí)行一個操作，在等待它返回的過程中怔球，用戶已經(jīng)完成了倒水嚼酝、喝茶、抽煙等一系列消遣活動竟坛，但系統(tǒng)還是沒返回結(jié)果!其實這是個好現(xiàn)象闽巩，至少我們能看到癥狀，從而可以對癥下藥担汤。性能問題從表象上來看可以分為兩類:
不可(或很難)重現(xiàn)的偶發(fā)性問題
比如線程阻塞涎跨，在某種特殊條件下，多個線程訪問共享資源時會被阻塞崭歧，但不會形成死鎖隅很，這種情況很難去重現(xiàn)，當(dāng)用戶打電話投訴時率碾，我們自已趕到現(xiàn)場癥狀已經(jīng)消失了叔营，然后1個月內(nèi)再也沒有出現(xiàn)過，當(dāng)我們都認(rèn)為“磨合”期已過所宰，系統(tǒng)已經(jīng)正常運行的時候绒尊，又接到了類似的投訴，崩潰呀!對于這種情況仔粥，“望”已經(jīng)不起作用了婴谱，不要為了看到癥狀而花費大量的時間和精力，可以采用后續(xù)提到的“聞問切”方式。
可重現(xiàn)的性能問題
客戶打電話給我們勘究，反映系統(tǒng)性能緩慢矮湘，不需要我們趕到現(xiàn)場，自己觀察一下生產(chǎn)機(jī)就可以發(fā)現(xiàn)部分交易緩慢口糕，CPU過高缅阳，可用內(nèi)存較低等問題，在這種情況下我們至少要測試三個有性能問題的交易( 或者三個與業(yè)務(wù)相關(guān)而技術(shù)無關(guān)的功能景描，或者與技術(shù)有關(guān)而業(yè)務(wù)無關(guān)的功能)十办，為什么是三個呢?因為“永遠(yuǎn)不要帶兩塊手表”，這會致使無法驗證和校對超棺。
比如三個不同的輸入功能向族，都是用戶輸入信息，然后保存到數(shù)據(jù)庫中棠绘，但是三個交易的性能都非常緩慢件相，通過初步的“望”我們就可以基本確認(rèn)是與數(shù)據(jù)庫或數(shù)據(jù)驅(qū)動相關(guān)的問題;若是只有一個交易緩慢，其他兩個正常,那就可以大致定位到-一個面:該交易的邏輯層出現(xiàn)問題氧苍。
(2)聞
中醫(yī)上的“聞”是大夫聽(或嗅)患者不自覺發(fā)出的聲音和氣味夜矗，在性能優(yōu)化上的“聞"則是關(guān)注項目被動產(chǎn)生的信息，其中包括:項目組的技術(shù)能力(主要取決于技術(shù)經(jīng)理的技術(shù)能力)让虐、文化氛圍紊撕、群體的習(xí)慣和習(xí)性，以及他們專注和擅長的領(lǐng)域等赡突，各位讀者可能要疑惑了:中醫(yī)上“聞”的對象是病人对扶，而為什么這里“聞”的對象卻是開發(fā)團(tuán)隊呢?
我們込祥來思考垓向題，如果是-一個人(個體)生病了惭缰，找大夫如此処理是沒有任何同題的浪南，但是如果是人奧(群體)生病了，那如何追尋送個根源昵?假沒人是上帝例造的漱受，如果有一群外星生物説“人奧都有自私的缺陥"逞泄，那是不是座垓去現(xiàn)察一下上帝?了解込個缺陷是源于他的可慣性効作述是技能缺乏，或者是“文化侍承".対于-一個Java座用來説拜效，我竹就是“上帝",我佝創(chuàng)造了他喷众，給了他生命(能答送行)，給了他尊門(用戸需要它)紧憾，給了他炙魂(解決了止努向題)到千，那- - 旦他生病，是不是座垓車視一下我仇込些“上帝”昵?或者我仂得自我反省一下昵?
如果項目組的技木能力很強(qiáng)赴穗，有資深的數(shù)據(jù)庠寺家憔四，有頂尖的架杓姉膀息，也有首席程序員，那性能向題廣生的根源就虛垓定位在無意訳的代礙缺陷上了赵。
如果項目組的文化氛國很精様潜支，組員不交流，沒有固定的代碣規(guī)范柿汛，缺乏整體的架枸等冗酿，那性能向題的根源就可能存在于某個配置上，或者相互的接口調(diào)用.上络断。
如果項目組已経ヨ慣了某- -個框架裁替，而且也可慣了框架的狆神約束，那性能的根源就可能是有人越述了框架的か約貌笨。
需要注意的是弱判，“”并不是主効地去了解，而是由技木(人或座用)自行擇爰出的“味道”锥惋，需要我們要敏鋭地抓住昌腰，込可能會対性能分析有非常大的幇助。
(3)向
“向"就是與技木人員(締造者)和止努人員(使用者) - -起探対核向題膀跌，了 解性能向題的萬史狀況剥哑，了解“慢”聲生的前因后果，比如対于韭多人員我仞可以咨詢:
性能是不是一苴込祥慢淹父， 從何肘起慢到不能忍受?
郷一個操作或梛-一奧操作最慢，大概的等待肘伺是多長?用戸的操作可慣是什幺怎虫，是喜玖快捷鍵逐是喜吹用鼠柝點む?
在什幺吋同段最慢暑认，韭多高峰期是否有滯頓現(xiàn)象，韭多低谷是否也緩慢?其他坊向渠道大审，如移効沒各是否也有效率向題?
韭努品神和數(shù)量有沒有激増蘸际，操作人員是否大規(guī)模増加?
是否在止多上爰生せ重大事項或重要変更，當(dāng)吋的性能如何?用戸的操作慣有沒有改変徒扶，或者用戸是否自定乂了某些功能?
而対于技木人員粮彤，我們就要從技木角度來詢向性能向題了，而且由于技木人員対系統(tǒng)了如指掌姜骡，可能會“無意沢"地回避向題导坟，我們座垓有技巧地処理送奧向題，例如可以込祥來詢向技木人員:
系統(tǒng)日志是否記彖了緩慢信息圈澈，是否可以回放緩慢交易?鏝慢吋系統(tǒng)的CPU惫周、內(nèi)存、IO如何?
高峰期和低谷肘止多并爰數(shù)量康栈、并爰交易神炎递递、達(dá)接池的數(shù)量喷橙、數(shù)據(jù)的達(dá)接數(shù)量如何?最早接到用戸投訴是什幺吋候，是如何赴理的登舞，代化后如何?數(shù)據(jù)量的増矢幅度如何贰逾，是否有萬史數(shù)據(jù)処理策略?
系統(tǒng)是否有不穩(wěn)定的情況，是否出現(xiàn)過宕機(jī)菠秒，是否產(chǎn)生過javacore文件?最后一次變更是何時疙剑，變更的內(nèi)容是哪些，變更后是否出現(xiàn)過性能問題?操作系統(tǒng)稽煤、網(wǎng)絡(luò)核芽、存儲、應(yīng)用軟件等環(huán)境是否發(fā)生過改變?
通過與技術(shù)人員和業(yè)務(wù)人員交流酵熙，我們可以對性能問題有一個整體認(rèn)識轧简，避免“管中窺豹，只見一斑”的偏見匾二，更加有助于我們分析和定位問題哮独。
(4)切
“切”是“四診”的最后-一個環(huán)節(jié)，也是最重要的環(huán)節(jié)察藐，這個環(huán)節(jié)結(jié)束我們就要給出定論:問題出在什么地方皮璧，該如何處理等。Java的性能診斷也是類似的分飞，“切”就要我們接觸真實的系統(tǒng)數(shù)據(jù)悴务，需要去看設(shè)計，看代碼譬猫，看日志讯檐，看系統(tǒng)環(huán)境，然后是思考分析染服，最后給出結(jié)論别洪。在這一-環(huán)節(jié)中，需要注意兩點: - -是所有的非- -手資料( 如報告柳刮、非系統(tǒng)信息)都不是100%可信的挖垛，二是測試環(huán)境畢竟是測試環(huán)境，它只是證明假設(shè)的輔助工具秉颗，并不能證明方法或策略的正確性痢毒。
曾經(jīng)遇到過這樣-一個案例，有一一個24小時運行的高并發(fā)系統(tǒng)蚕甥，從獲得的資料上看闸准，在出現(xiàn)偶發(fā)性的性能故障前系統(tǒng)沒有做過任何變更，網(wǎng)絡(luò)也沒變更過梢灭，業(yè)務(wù)也沒有過大的變動夷家，業(yè)務(wù)人員的形容是“一夜之間系統(tǒng)就變慢了”蒸其，而且該問題在測試機(jī)上不能模擬重現(xiàn)。接到任務(wù)后库快，馬上進(jìn)行“望聞問”摸袁，都沒有太大的收獲。進(jìn)入到“切”環(huán)節(jié)時义屏，對大量的日志進(jìn)行跟蹤分析調(diào)試靠汁，最終鎖定到了加密機(jī)上:加密機(jī)屬于多個系統(tǒng)的共享資源，當(dāng)排隊加密數(shù)據(jù)時就有可能出現(xiàn)性能問題闽铐，最終的解決方案是增加一臺加密機(jī)蝶怔，于是系統(tǒng)性能恢復(fù)正常。
性能優(yōu)化是一一個漫長的工作兄墅，特別是對于偶發(fā)性的性能問題踢星，不要期望找到“名醫(yī)”立刻就能見效，這是不現(xiàn)實的隙咸，深入思考沐悦，尋根探源，最終必然能找到根源所在五督。中醫(yī)上有一句話“病來如山倒藏否，病去如抽絲”，系統(tǒng)診斷也應(yīng)該這樣-一個過程充包，切忌急躁副签。
注意性能診斷遵循 “望聞問切”，不可過度急躁基矮。
建議135: 必須定義性能的衡量標(biāo)準(zhǔn)
出現(xiàn)性能問題不可怕淆储，可 怕的是沒有目標(biāo)，用戶只是說“我希望它非秤保快”，或者說“和以前一樣快”慈鸠，在這種情況下蓝谨，我們就需要把制定性能衡量標(biāo)準(zhǔn)放在首位了，原因有兩個:
(1)性能衡量標(biāo)準(zhǔn)是技術(shù)與業(yè)務(wù)之間的契約
“非城嗤牛快”是一個直觀性的描述譬巫，它不具有衡量的可能性，對技術(shù)人員來說督笆，-一個請求在2秒鐘之內(nèi)響應(yīng)就可以認(rèn)為是“非陈簦快”了，但對業(yè)務(wù)人員來說娃肿，“非彻径校快”指的是在0.5秒內(nèi)看到結(jié)果一看珠十， 出現(xiàn)偏差了。如果我們不解決這種偏差凭豪，就有可能出現(xiàn)當(dāng)技術(shù)人員認(rèn)為優(yōu)化結(jié)束的時候焙蹭，而業(yè)務(wù)人員還認(rèn)為系統(tǒng)很慢，仍然需要提高繼續(xù)性能嫂伞，于是拒不簽收驗收文檔孔厉，這就產(chǎn)生商務(wù)麻煩了。
(2)性能衡量標(biāo)志是技術(shù)優(yōu)化的目標(biāo)
性能優(yōu)化是無底線的帖努，性能優(yōu)化得越厲害帶來的副作用也就明顯撰豺，例如代碼的可讀性差，可擴(kuò)展性降低等拼余，比如- -個乘法計算污桦，我們一-般是這樣寫代碼的:
int i =100*16;
如果我們?yōu)榱颂嵘到y(tǒng)性能，使用左移的方式來計算姿搜，代碼如下:
int i =100<<4;
性能確實提高了寡润，但是也帶來了副作用，比如代碼的可讀性降低了很多舅柜，要想讓其他人員看明白這個左移是何意梭纹，就需要加上注釋說“把100擴(kuò)大16倍”，這在項目開發(fā)中是非常不合適的致份。因此為了讓我們的代碼保持優(yōu)雅变抽，減少“壞味道”的產(chǎn)生，就需要定義一個優(yōu)化目標(biāo):優(yōu)化到什么地步才算結(jié)束氮块。
明白了性能標(biāo)準(zhǔn)的重要性绍载，就需要在優(yōu)化前就制定好它，-一個好的性能衡量標(biāo)準(zhǔn)應(yīng)該包括以下KPI (Key Performance Indicators):
核心業(yè)務(wù)的響應(yīng)時間滔蝉。一個新聞網(wǎng)站的核心業(yè)務(wù)就是新聞瀏覽击儡，它的衡量標(biāo)準(zhǔn)就是打
開一個新聞的時間;一個郵件系統(tǒng)的核心業(yè)務(wù)就是郵件發(fā)送和接收速度; -一個管理型系統(tǒng)的核心就是流程提交，這也就是它的衡量標(biāo)準(zhǔn)蝠引。
重要業(yè)務(wù)的響應(yīng)時間阳谍。重要業(yè)務(wù)是指在系統(tǒng)中占據(jù)前沿地位的業(yè)務(wù)，但是不會涉及業(yè)務(wù)數(shù)據(jù)的功能螃概，例如一個業(yè)務(wù)系統(tǒng)需要登錄后才能操作核心業(yè)務(wù)矫夯，這個登錄交易就是它的重要交易，比如郵件系統(tǒng)的登錄吊洼。
當(dāng)然训貌，性能衡量標(biāo)準(zhǔn)必須在- -定的環(huán)境下，比如網(wǎng)絡(luò)冒窍、操作系統(tǒng)递沪、硬件設(shè)備等確定的情況下才會有意義豺鼻，并且還需要限定并發(fā)數(shù)、資源數(shù)(如10萬數(shù)據(jù)和1000萬的數(shù)據(jù)響應(yīng)時間肯定不同)等区拳，當(dāng)然很多時候我們并沒有必要白紙黑字地簽署- - 份協(xié)約拘领，我們編寫性能衡量標(biāo)準(zhǔn)更多地是為了確定一個目標(biāo)，并盡快達(dá)到業(yè)務(wù)要求而已.
