文檔資料: wenku.itilzj.com

1. 并行處理簡要說明

舉個例子：在價格查詢鏈路中，我們需要獲取多種獨立的價格配置項信息，如基礎(chǔ)價、折扣價、商戶活動價、平臺活動價等等。為了加快處理速度，可以使用多線程并行處理的方式，利用并發(fā)計算的優(yōu)勢。而CompletableFuture是一種流行的實現(xiàn)多線程的方式，它可以輕松地管理線程的創(chuàng)建、執(zhí)行和回調(diào)，提高程序的可擴展性和并發(fā)性。

然而，多線程的使用也存在一些弊端，例如硬件資源的限制和線程間的通信開銷等。因此，我們需要在使用多線程的同時，考慮到 I/O 密集型和 CPU 密集型的差異，以避免過度開啟線程導(dǎo)致性能下降。同時，對于線程池的運行情況，我們也需要有一定的了解和控制，以確保程序的高效穩(wěn)定運行。

CompletableFuture 是銀彈嗎？

我們常說“手拿錘子看什么都像釘子”，使用CompletableFuture的確能夠幫助我們解決許多獨立處理邏輯的問題，但是如果使用過多的線程，反而會導(dǎo)致線程調(diào)度時間不能得到保障，線程會被浪費在等待 CPU 時間片上，特別是對于那些本來執(zhí)行速度就很快的任務(wù)，使用 CompletableFuture 之后反而會拖慢整體執(zhí)行時長。

因此，在使用CompletableFuture時，我們需要根據(jù)具體的場景和任務(wù)，仔細考慮是否需要并行處理。如果需要并行處理，我們需要根據(jù)任務(wù)的性質(zhì)和執(zhí)行速度，選擇合適的線程池大小和并行線程數(shù)量，以避免線程調(diào)度時間的浪費和執(zhí)行效率的下降。

測試案例

執(zhí)行 a,b,c,d4 個方法，比較同步執(zhí)行與異步執(zhí)行的耗時情況。

全同步執(zhí)行

private voidtest(){
longs=System.currentTimeMillis();
a(10);
b(10);
c(10);
d(10);
longe=System.currentTimeMillis();
System.out.println(e - s);
}
publicvoida(int time){
try{
Thread.sleep(time);
}catch(InterruptedException e){
e.printStackTrace();
}
}
publicvoidb(int time){
try{
Thread.sleep(time);
}catch(InterruptedException e){
e.printStackTrace();
}
}
publicvoidc(int time){
try{
Thread.sleep(time);
}catch(InterruptedException e){
e.printStackTrace();
}
}
publicvoidd(int time){
try{
Thread.sleep(time);
}catch(InterruptedException e){
e.printStackTrace();
}
}

全異步執(zhí)行

private voidtest2(){
longs=System.currentTimeMillis();
List completableFutureList = new ArrayList<>();
CompletableFuture future1 =CompletableFuture.runAsync(()->{
a( 10);
});
completableFutureList.add(future1);
CompletableFuture future2 =CompletableFuture.runAsync(()->{
b( 10);
});
completableFutureList.add(future2);
CompletableFuture future3 =CompletableFuture.runAsync(()->{
c( 10);
});
completableFutureList.add(future3);
CompletableFuture future4 =CompletableFuture.runAsync(()->{
d( 10);
});
completableFutureList.add(future4);
CompletableFuture[] futures = completableFutureList.toArray( new CompletableFuture[ 0]);
CompletableFuture futureAll =CompletableFuture.allOf(futures);
futureAll.join();
long e=System.currentTimeMillis();
System.out.println(e - s);
}

結(jié)果統(tǒng)計

測試結(jié)論

在分配了相對合理的線程池的情況下，通過以上分析，可以得出下列兩個結(jié)論：

• ? 方法耗時越少，同步比異步越好。

• ? 方法數(shù)量越少，同步比異步越好。

有時候，如果方法較多，為了減少高并發(fā)時 P99 較高，我們可以讓耗時多的方法異步執(zhí)行，耗時少的方法同步執(zhí)行。

通過以下數(shù)據(jù)可以看出，耗時是差不多的，但可以節(jié)省不少線程資源。

總結(jié)

CompletableFuture提供了一種優(yōu)雅而強大的方式來處理并發(fā)請求和任務(wù)。然而，正如在處理高并發(fā)時使用過多的線程會導(dǎo)致資源浪費和效率下降一樣，使用過多的CompletableFuture也會導(dǎo)致同樣的問題。這種現(xiàn)象被稱為 "線程調(diào)度問題"，它會導(dǎo)致性能下降和吞吐量下降（P99 值較高）。

因此，我們需要在使用CompletableFuture時考慮實際場景和負載情況，并根據(jù)需要使用恰當?shù)募夹g(shù)來優(yōu)化性能。

2. 最小化事務(wù)范圍簡要說明

首先，我們需要明確的是，事務(wù)的存在勢必會對性能產(chǎn)生影響，特別是在高并發(fā)的情況下，因為鎖的競爭，會帶來極大的性能損耗。因此，在處理數(shù)據(jù)交互的過程中，我們始終堅持盡可能地減少事務(wù)的范圍，從而提升接口的響應(yīng)速度。

一般來說，我們可以利用@Transactional注解輕松實現(xiàn)事務(wù)的控制。但是，由于@Transactional注解的最小粒度僅限于方法級別，因此，為了更好地控制事務(wù)的范圍，我們需要通過編程式事務(wù)來實現(xiàn)。

在編程式事務(wù)中，我們可以更靈活地控制事務(wù)的開啟和結(jié)束，以及對數(shù)據(jù)庫操作的處理。通過適當?shù)脑O(shè)置事務(wù)參數(shù)和操作規(guī)則，我們可以實現(xiàn)事務(wù)的最小化，從而提升系統(tǒng)的性能和可靠性。

編程式事務(wù)模板

public interfaceTransactionControlService{
/**
* 事務(wù)處理
*
* @param objectLogicFunction 業(yè)務(wù)邏輯
* @param result type
* @return 處理結(jié)果
* @throws Exception 業(yè)務(wù)異常信息
*/
T execute(ObjectLogicFunction objectLogicFunction) throwsException;
/**
* 事務(wù)處理
*
* @param voidLogicFunction 業(yè)務(wù)邏輯
* @throws Exception 業(yè)務(wù)異常信息
*/
void execute(VoidLogicFunction voidLogicFunction) throwsException;
}

@Service
publicclassTransactionControlServiceImplimplementsTransactionControlService{

@Autowired
privatePlatformTransactionManager platformTransactionManager;

@Autowired
privateTransactionDefinition transactionDefinition;

/**
* 事務(wù)處理
*
* @param businessLogic 業(yè)務(wù)邏輯
* @param result type
* @return 處理結(jié)果
* @throws Exception 業(yè)務(wù)異常信息
*/
@Override
public T execute(ObjectLogicFunction businessLogic) throwsException{
TransactionStatus transactionStatus= platformTransactionManager.getTransaction(transactionDefinition);
try{
T resp= businessLogic.logic();
platformTransactionManager.commit(transactionStatus);
return resp;
} catch(Exception e){
platformTransactionManager.rollback(transactionStatus);
throw new Exception(e);
}
}

/**
* 事務(wù)處理
*
* @param businessLogic 業(yè)務(wù)邏輯
*/
@Override
public void execute(VoidLogicFunction businessLogic) throwsException{
TransactionStatus transactionStatus= platformTransactionManager.getTransaction(transactionDefinition);
try{
businessLogic.logic();
platformTransactionManager.commit(transactionStatus);
} catch(Exception e){
platformTransactionManager.rollback(transactionStatus);
throw new Exception(e);
}
}


}

@FunctionalInterface
public interface ObjectLogicFunction {

/**
* 業(yè)務(wù)邏輯處理
*
* @return 業(yè)務(wù)處理結(jié)果
* @throws BusinessException e
*/
T logic() throws BusinessException;
}

@FunctionalInterface
public interface VoidLogicFunction {

/**
* 業(yè)務(wù)邏輯處理
*
* @throws Exception e
*/
void logic() throws Exception;
}

transactionControlService.execute(() -> {


// 把需要事務(wù)控制的業(yè)務(wù)邏輯寫在這里即可

緩存，這一在性能提升方面堪稱萬金油的技術(shù)手段，它的重要性在各種計算機應(yīng)用領(lǐng)域中無可比擬。

緩存作為一種高效的數(shù)據(jù)讀取和寫入的優(yōu)化方式，被廣泛應(yīng)用于各種領(lǐng)域，包括電商、金融、游戲、直播等。

雖然在網(wǎng)絡(luò)上關(guān)于緩存的文章不勝枚舉，但要想充分發(fā)揮緩存的作用，需要針對具體的業(yè)務(wù)場景進行深入分析和探討。因此，在本節(jié)中，我們將不過多贅述緩存的具體使用方法，而是重點列舉一些使用緩存時的注意事項.

使用緩存時的注意事項

• ?緩存過期時間：設(shè)置合適的過期時間可以保證緩存的有效性，但過期時間過長可能會浪費內(nèi)存空間，過期時間過短可能會導(dǎo)致頻繁刷新緩存，影響性能。

• ?緩存一致性：如果緩存的數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)不一致，可能會導(dǎo)致業(yè)務(wù)邏輯出現(xiàn)問題。因此，在使用緩存時需要考慮緩存一致性的問題。

• ?緩存容量限制：緩存容量有限，如果緩存的數(shù)據(jù)量過大，可能會導(dǎo)致內(nèi)存溢出或者緩存頻繁清理。因此，在使用緩存時需要注意緩存容量的限制。

• ?緩存需要考慮負載均衡：在高并發(fā)場景下，需要考慮緩存的負載均衡問題，避免某些緩存服務(wù)器因為熱點數(shù)據(jù)等問題負載過重導(dǎo)致系統(tǒng)崩潰或者響應(yīng)變慢。

• ?緩存需要考慮并發(fā)讀寫：當多個用戶同時訪問緩存時，需要考慮并發(fā)讀寫的問題，避免緩存沖突和數(shù)據(jù)一致性問題。

• ?緩存穿透問題：當大量的查詢請求都無法命中緩存時，導(dǎo)致每次查詢都會落到數(shù)據(jù)庫上，從而造成數(shù)據(jù)庫壓力過大。

• ?緩存擊穿問題：當緩存數(shù)據(jù)失效后，導(dǎo)致大量的請求直接打到數(shù)據(jù)庫中，從而造成數(shù)據(jù)庫壓力過大。

• ?查詢時間復(fù)雜度：需額外注意緩存查詢的時間復(fù)雜度問題，如果是 O(n)，甚至更差的時間復(fù)雜度，則會因為緩存的數(shù)據(jù)量增加而跟著增加。

• ?數(shù)據(jù)壓縮：選擇合理的數(shù)據(jù)類型，舉個例子：如果用Integer[]和int[]來比較，Integer 占用的空間大約是 int 的 4 倍。其他情況下，使用一些常見數(shù)據(jù)編碼壓縮技術(shù)也是常見的節(jié)省內(nèi)存的方式，比如：BitMap、字典編碼等。

• ?預(yù)加載：當行為可預(yù)測時，那么提前加載便可解決構(gòu)建緩存時的壓力。

• ?熱點數(shù)據(jù)：熱點數(shù)據(jù)如果不能打散，那么通常就會構(gòu)建多級緩存，比如將應(yīng)用服務(wù)設(shè)為一級緩存，Redis 設(shè)為二級緩存，一級緩存，緩存全量熱點數(shù)據(jù)，從而實現(xiàn)壓力分攤。

• ?緩存穿透、擊穿：針對命中不了緩存的查詢也可以緩存一個額外的標識；而針對緩存失效，要么就在失效前，主動刷新一次，要么就分散失效時間，避免大量緩存同時失效。

• ?時間復(fù)雜度：在設(shè)計緩存時，優(yōu)先考慮選擇常數(shù)級的時間復(fù)雜度的方法。

在本文開始提到的使用CompletableFuture并行處理時，實際上就已經(jīng)使用到線程池了，池化技術(shù)的好處，我想應(yīng)該不用再過多闡述了，但關(guān)于線程池的使用還是有很多注意點的。

使用場景異步任務(wù)

簡單來說就是某些不需要同步返回業(yè)務(wù)處理結(jié)果的場景，比如：短信、郵件等通知類業(yè)務(wù)，評論、點贊等互動性業(yè)務(wù)。

并行計算

就像MapReduce一樣，充分利用多線程的并行計算能力，將大任務(wù)拆分為多個子任務(wù)，最后再將所有子任務(wù)計算后的結(jié)果進行匯總，ForkJoinPool就是 JDK 中典型的并行計算框架。

同步任務(wù)

前面講到的CompletableFuture使用，就是典型的同步改異步的方式，如果任務(wù)之間沒有依賴，那么就可以利用線程，同時進行處理，這樣理論上就只需要等待耗時最長的步驟結(jié)束即可（實際情況可參考CompletableFuture分析）。

線程池的創(chuàng)建

不要直接使用Executors創(chuàng)建線程池，應(yīng)通過ThreadPoolExecutor的方式，主動明確線程池的參數(shù)，避免產(chǎn)生意外。

每個參數(shù)都要顯示設(shè)置，例如像下面這樣：

private staticfinalExecutorServiceexecutor=newThreadPoolExecutor(
2,
4,
1L,
TimeUnit.MINUTES,
newLinkedBlockingQueue<>(100),
newThreadFactoryBuilder().setNameFormat("common-pool-%d").build(),
newThreadPoolExecutor.CallerRunsPolicy());

參數(shù)的配置建議CorePoolSize（核心線程數(shù)）

一般在配置核心線程數(shù)的時候，是需要結(jié)合線程池將要處理任務(wù)的特性來決定的，而任務(wù)的性質(zhì)一般可以劃分為：CPU 密集型、I/O 密集型。

比較通用的配置方式如下

• ?CPU 密集型：一般建議線程的核心數(shù)與 CPU 核心數(shù)保持一致。

• ?I/O 密集型：一般可以設(shè)置 2 倍的 CPU 核心數(shù)的線程數(shù)，因為此類任務(wù) CPU 比較空閑，可以多分配點線程充分利用 CPU 資源來提高效率。

通過Runtime.getRuntime().availableProcessors()可以獲取核心線程數(shù)。

另外還有一個公式可以借鑒

• ? 線程核心數(shù) = cpu 核心數(shù) / （1-阻塞系數(shù)）

• ? 阻塞系數(shù) = 阻塞時間／（阻塞時間+使用 CPU 的時間）

實際上大多數(shù)線上業(yè)務(wù)所消耗的時間主要就是 I/O 等待，因此一般線程數(shù)都可以設(shè)置的多一點，比如 tomcat 中默認的線程數(shù)就是 200，所以最佳的核心線程數(shù)是需要根據(jù)特定場景，然后通過實際上線上允許結(jié)果分析后，再不斷的進行調(diào)整。

MaximumPoolSize

maximumPoolSize的設(shè)置也是看實際應(yīng)用場景，如果設(shè)置的和corePoolSize一樣，那就完全依靠阻塞隊列和拒絕策略來控制任務(wù)的處理情況，如果設(shè)置的比corePoolSize稍微大一點，那就可以更好的應(yīng)對一些有突發(fā)流量產(chǎn)生的場景。

KeepAliveTime

由maximumPoolSize創(chuàng)建出來的線程，在經(jīng)過keepAliveTime時間后進行銷毀，依據(jù)突發(fā)流量持續(xù)的時間來決定。

WorkQueue

那么阻塞隊列應(yīng)該設(shè)置多大呢？我們知道當線程池中所有的線程都在工作時，如果再有任務(wù)進來，就會被放到阻塞隊列中等待，如果阻塞隊列設(shè)置的太小，可能很快隊列就滿了，導(dǎo)致任務(wù)被丟棄或者異常（由拒絕策略決定），如果隊列設(shè)置的太大，又可能會帶來內(nèi)存資源的緊張，甚至 OOM，以及任務(wù)延遲時間過長。

所以阻塞隊列的大小，又是要結(jié)合實際場景來設(shè)置的。

一般會根據(jù)處理任務(wù)的速度與任務(wù)產(chǎn)生的速度進行計算得到一個大概的數(shù)值。

假設(shè)現(xiàn)在有 1 個線程，每秒鐘可以處理 10 個任務(wù)，正常情況下每秒鐘產(chǎn)生的任務(wù)數(shù)小于 10，那么此時隊列長度為 10 就足以。

但是如果高峰時期，每秒產(chǎn)生的任務(wù)數(shù)會達到 20，會持續(xù) 10 秒，且任務(wù)又不希望丟棄，那么此時隊列的長度就需要設(shè)置到 100。

監(jiān)控 workQueue 中等待任務(wù)的數(shù)量是非常重要的，只有了解實際的情況，才能做出正確的決定。

在有些場景中，可能并不希望因為任務(wù)被丟進阻塞隊列而等待太長的時間，而是希望直接開啟設(shè)置的 MaximumPoolSize 線程池數(shù)來執(zhí)行任務(wù)，這種情況下一般可以直接使用 SynchronousQueue 隊列來實現(xiàn)

通過 threadFactory 我們可以自定義線程組的名字，設(shè)置合理的名稱將有利于你線上進行問題排查。

Handler

最后拒絕策略，這也是要結(jié)合實際的業(yè)務(wù)場景來決定采用什么樣的拒絕方式，例如像過程類的數(shù)據(jù)，可以直接采用DiscardOldestPolicy策略。

線程池的監(jiān)控

線上使用線程池時，一定要做好監(jiān)控，以便根據(jù)實際運行情況進行調(diào)整，常見的監(jiān)控方式可以通過線程池提供的 API，然后暴露給 Metrics 來完成實時數(shù)據(jù)統(tǒng)計。

監(jiān)控示例

線程池自身提供的統(tǒng)計數(shù)據(jù)

public classThreadPoolMonitor{

privatefinalstaticLoggerlog=LoggerFactory.getLogger(ThreadPoolMonitor.class);

privatestaticfinalThreadPoolExecutorthreadPool=newThreadPoolExecutor(2,4,0,
TimeUnit.SECONDS,newLinkedBlockingQueue<>(100),
newThreadFactoryBuilder().setNameFormat("my_thread_pool_%d").build());

publicstaticvoidmain(String[] args){
log.info("Pool Size: "+ threadPool.getPoolSize());
log.info("Active Thread Count: "+ threadPool.getActiveCount());
log.info("Task Queue Size: "+ threadPool.getQueue().size());
log.info("Completed Task Count: "+ threadPool.getCompletedTaskCount());
}
}

通過 micrometer API 完成統(tǒng)計，這樣就可以接入Prometheus了

package com.springboot.micrometer.monitor;

import com.google.common.util.concurrent.ThreadFactoryBuilder;
import io.micrometer.core.instrument.Metrics;
import org.springframework.stereotype.Component;

import javax.annotation.PostConstruct;
import java.util.concurrent.Executors;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;
import java.util.stream.IntStream;

@Component
publicclassThreadPoolMonitor{

privatestaticfinalThreadPoolExecutorthreadPool=newThreadPoolExecutor(4,8,0,
TimeUnit.SECONDS,newLinkedBlockingQueue<>(100),
newThreadFactoryBuilder().setNameFormat("my_thread_pool_%d").build(),newThreadPoolExecutor.DiscardOldestPolicy());

/**
* 活躍線程數(shù)
*/
privateAtomicLongactiveThreadCount=newAtomicLong(0);

/**
* 隊列任務(wù)數(shù)
*/
privateAtomicLongtaskQueueSize=newAtomicLong(0);

/**
* 完成任務(wù)數(shù)
*/
privateAtomicLongcompletedTaskCount=newAtomicLong(0);

/**
* 線程池中當前線程的數(shù)量
*/
privateAtomicLongpoolSize=newAtomicLong(0);

@PostConstruct
privatevoidinit(){

/**
* 通過micrometer API完成統(tǒng)計
*
* gauge最典型的使用場景就是統(tǒng)計：list、Map、線程池、連接池等集合類型的數(shù)據(jù)
*/
Metrics.gauge("my_thread_pool_active_thread_count", activeThreadCount);
Metrics.gauge("my_thread_pool_task_queue_size", taskQueueSize);
Metrics.gauge("my_thread_pool_completed_task_count", completedTaskCount);
Metrics.gauge("my_thread_pool_size", poolSize);

// 模擬線程池的使用

privatevoidrunTask(){


// 每5秒監(jiān)控一次線程池的使用情況

// 模擬任務(wù)執(zhí)行

// 每500毫秒，執(zhí)行一個任務(wù)

// 每個處理一個任務(wù)耗時5秒

privatevoidmonitorThreadPoolState(){
Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(()->{
activeThreadCount.set(threadPool.getActiveCount());
taskQueueSize.set(threadPool.getQueue().size());
poolSize.set(threadPool.getPoolSize());
completedTaskCount.set(threadPool.getCompletedTaskCount());
},0,5,TimeUnit.SECONDS);
}
}
線程池的資源隔離

在生產(chǎn)環(huán)境中，一定要注意好資源隔離的問題，盡量不要將不同類型，不同重要等級的任務(wù)放入一個線程池中，以免因為線程資源爭搶而互相影響。

5. 服務(wù)預(yù)熱

服務(wù)預(yù)熱也是很常見的一種優(yōu)化手段，例如數(shù)據(jù)庫連接、線程池中的核心線程，緩存等信息可以利用服務(wù)啟動階段預(yù)先加載，從而避免請求到來后臨時構(gòu)建的耗時。

下面提供一些預(yù)加載的方式

線程池

線程池本身提供了相關(guān)的 API：prestartAllCoreThreads()通過該方法可以提前將核心線程創(chuàng)建好，非常方便。

Web 服務(wù)

常見的如 Tomcat，其本身也用到了線程池，只是其自身已經(jīng)考慮到了預(yù)加載的問題，不需要我們額外處理了。

連接池常用的一般就是數(shù)據(jù)庫連接池以及Redis連接池，大多數(shù)這些連接的客戶端也都做了連接提前加載的工作，遇到?jīng)]有預(yù)加載的參考其他客戶端方式搞一下即可。

緩存

一般本地緩存可以在每次服務(wù)啟動時預(yù)先加載好，以免出現(xiàn)緩存擊穿的情況。

靜態(tài)代碼塊

在服務(wù)啟動時，靜態(tài)代碼塊中的相關(guān)功能會優(yōu)先被加載，可以有效避免在運行時再加載的情況。

其他擴展

預(yù)熱實際上可聊的內(nèi)容很多，一般有用到池化技術(shù)的方式，都是需要預(yù)熱的，為了能夠提升響應(yīng)性能，將不在內(nèi)存中的數(shù)據(jù)提前查好放入內(nèi)存中，或者將需要計算的數(shù)據(jù)提前計算好，這都是很容易想到的解決方式。

此外還有一些服務(wù)端在設(shè)計之初就會針對性地對一些熱點數(shù)據(jù)進行特殊處理，比如JVM中的JIT、內(nèi)存分配比；OS中的page cache；MySQL中的innodb_buffer_pool等，這些一般可以通過流量預(yù)熱的方式來使其達到最佳狀態(tài)。

6. 緩存對齊CPU的多級緩存

CPU緩存通常分為大小不等的三級緩存

來自百度百科對三級緩存分類的介紹：

一級緩存都內(nèi)置在CPU內(nèi)部并與CPU同速運行，可以有效的提高CPU的運行效率。一級緩存越大，CPU的運行效率越高，但受到CPU內(nèi)部結(jié)構(gòu)的限制，一級緩存的容量都很小。

二級緩存，它是為了協(xié)調(diào)一級緩存和內(nèi)存之間的速度。cpu調(diào)用緩存首先是一級緩存，當處理器的速度逐漸提升，會導(dǎo)致一級緩存就供不應(yīng)求，這樣就得提升到二級緩存了。二級緩存它比一級緩存的速度相對來說會慢，但是它比一級緩存的空間容量要大。主要就是做一級緩存和內(nèi)存之間數(shù)據(jù)臨時交換的地方用。

三級緩存是為讀取二級緩存后未命中的數(shù)據(jù)設(shè)計的—種緩存，在擁有三級緩存的CPU中，只有約5%的數(shù)據(jù)需要從內(nèi)存中調(diào)用，這進一步提高了CPU的效率。其運作原理在于使用較快速的儲存裝置保留一份從慢速儲存裝置中所讀取數(shù)據(jù)并進行拷貝，當有需要再從較慢的儲存體中讀寫數(shù)據(jù)時，緩存(cache)能夠使得讀寫的動作先在快速的裝置上完成，如此會使系統(tǒng)的響應(yīng)較為快速。

public classCacheLine{
publicstaticvoidmain(String[] args){
int[][] arr =newint[10000][10000];
longs=System.currentTimeMillis();
for(inti=0; i < arr.length; i++){
for(intj=0; j < arr[i].length; j++){
arr[i][j]=0;
}
}
longe=System.currentTimeMillis();
System.out.println(e-s);
}
}

逐列寫入

public classCacheLine{
publicstaticvoidmain(String[] args){
int[][] arr =newint[10000][10000];
longs=System.currentTimeMillis();
for(inti=0; i < arr.length; i++){
for(intj=0; j < arr[i].length; j++){
arr[j][i]=0;
}
}
longe=System.currentTimeMillis();
System.out.println(e-s);
}
}

雖然兩種方式得到的結(jié)果是一樣的，但性能對比卻相差巨大，這就是緩存行帶來的影響。

原因分析

CPU的緩存是由多個緩存行組成的，以緩存行為基本單位，一個緩存行的大小一般為64字節(jié)，二維數(shù)組在內(nèi)存中保存時，實際上是以按行遍歷的方式進行保存，比如:arr[0][0],arr[0][1],arr[1][0],arr[1][1],arr[2][0],arr[2][1]...

所以當按行訪問時，是按照內(nèi)存存儲的順序進行訪問，那么CPU緩存后面的元素就可以利用到，而如果是按列訪問，那么CPU的緩存是沒有用的。

緩存行對齊

public classCacheLinePadding{
privatestaticclassPadding{


// 一個long是8個字節(jié)，一共7個long

// public volatile long p1, p2, p3, p4, p5, p6, p7;

privatestaticclassTextendsPadding{


// x變量8個字節(jié)，加上Padding中的變量，剛好64個字節(jié)，獨占一個緩存行。

publicstatic T[] arr =newT[2];

static{
arr[0]=newT();
arr[1]=newT();
}

publicstaticvoidmain(String[] args)throwsException{
Threadt1=newThread(()->{
for(longi=0; i <10000000; i++){
arr[0].x = i;
}
});

Threadt2=newThread(()->{
for(longi=0; i <10000000; i++){
arr[1].x = i;
}
});

finallongstart=System.nanoTime();
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println((System.nanoTime()- start)/100000);
}
}

同樣的含有public volatile long p1, p2, p3, p4, p5, p6, p7;這一行代碼與不含性能也相差巨大，這同樣也是因為緩存行的原因，當運行在兩個不同CPU上的兩個線程要寫入。

7. 減少對象的產(chǎn)生避免使用包裝類型

因為包裝類型的創(chuàng)建和銷毀都會產(chǎn)生臨時對象，因此相比基本數(shù)據(jù)類型來說，會帶來額外的消耗。

public classMain{

publicstaticvoidmain(String[] args){
longs=System.currentTimeMillis();
testInteger();
longe=System.currentTimeMillis();
System.out.println(e - s);
testInt();
longe2=System.currentTimeMillis();
System.out.println(e2 - e);
}

privatestaticvoidtestInt(){
intsum=1;
for(inti=1; i <50000000; i++){
sum++;
}
System.out.println(sum);
}

privatestaticvoidtestInteger(){
Integersum=1;
for(inti=1; i <50000000; i++){
sum++;
}
System.out.println(sum);
}
}

兩個方法不僅執(zhí)行時間相差百倍，在CPU和內(nèi)存的消耗上Integer也明顯弱于int。

Integer內(nèi)存和CPU都能看到明顯的波動

int幾乎沒波動

最為典型的案例就是String，我想應(yīng)該不會有人去通過new的方式再去構(gòu)建一個String字符串了吧！

String str = new String("abc");
String str = "abc";

同時，在實現(xiàn)字符串連接時通常使用StringBuilder或StringBuffer，這樣可以避免使用連接符，導(dǎo)致每次都創(chuàng)建新的字符串對象。

靜態(tài)方法

靜態(tài)對象

Boolean.valueOf("true");

publicstaticBooleanvalueOf(String s){
return parseBoolean(s)? TRUE : FALSE;
}

publicstaticfinalBooleanTRUE=newBoolean(true);

publicstaticfinalBooleanFALSE=newBoolean(false);

靜態(tài)工廠（單例模式）

public classStaticSingleton{
privatestaticclassStaticHolder{
publicstaticfinalStaticSingletonINSTANCE=newStaticSingleton();
}

publicstaticStaticSingletongetInstance(){
returnStaticHolder.INSTANCE;
}
}

枚舉

public enum EnumSingleton { INSTANCE; }

視圖

視圖是返回引用的一種方式。

map的keySet方法，實際上每次返回的都是同一個對象的引用。

public Set keySet(){
Set ks = keySet;
if(ks == null){
ks = new KeySet();
keySet = ks;
}
return ks;
}

對象池

對象池可以有效減少頻繁的對象創(chuàng)建和銷毀的過程，一般情況下如果每次創(chuàng)建對象的過程較為復(fù)雜，且對象占用空間又比較大，那么就建議使用對象池的方式來優(yōu)化。

使用示例

org.apache.commons提供了對象池的工具類，可以直接拿來使用


org.apache.commonsgroupId>
commons-pool2artifactId>
2.11.1version>
dependency>

池化的對象

@Data
public class Cache {
private byte[] size;
}

池化對象工廠

public classCachePoolObjectFactoryextendsBasePooledObjectFactory {

@Override
publicCache create(){
Cache cache= new Cache();
cache.setSize( new byte[ 1024* 1024* 16]);
return cache;
}

@Override
publicPooledObject wrap(Cache cache){
return new DefaultPooledObject<>(cache);
}

}

對象池工具

import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;

import java.time.Duration;

publicenumCachePoolUtil{

INSTANCE;

privateGenericObjectPool objectPool;

CachePoolUtil(){
GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig<>();


// 對象池中最大對象數(shù)

// 對象池中最小空閑對象數(shù)

// 對象池中最大空閑對象數(shù)

// 獲取對象最大等待時間 默認 -1 一直等待

// 創(chuàng)建對象工廠

// 創(chuàng)建對象池

// 將對象歸還給對象池

public classMain{

publicstaticvoidmain(String[] args){
CachePoolUtilcachePoolUtil=CachePoolUtil.INSTANCE;
for(inti=0; i <10; i++){
newThread(newRunnable(){
@SneakyThrows
@Override
publicvoidrun(){
while(true){
Thread.sleep(100);

// 使用對象池

// 不使用對象池

//Cache cache = new Cache();

//cache.setSize(new byte[1024 * 1024 * 2]);

//m(cache);

}
}).start();
}
}

// 無特殊作用

使用對象池

不適用對象池

并發(fā)場景下就要考慮線程安全的問題，常見的解決方式：volatile、CAS、自旋鎖、對象鎖、類鎖、分段鎖、讀寫鎖，理論上來說，鎖的粒度越小，并行效果就越高。

volatile

volatile是Java中的一個關(guān)鍵字，用于修飾變量。它的作用是保證被volatile修飾的變量在多線程環(huán)境下的可見性和禁止指令重排序。

volatile雖然不能保證原子性，但如果對共享變量是純賦值或讀取的操作，那么因為volatile保證了可見性，因此也是可以實現(xiàn)線程安全的。

CAS

compare and swap（比較并交換），CAS主要有三個參數(shù)，

• ? V：內(nèi)存值

• ? A：當前時

• ? B：待更新的值

當且僅當V等于A時，就將A更新為B，否則什么都不做。V和A的比較是一個原子性操作保證線程安全。

Random通過cas的方式保證了線程安全，但在高并發(fā)下很有可能會失敗，造成頻繁的重試。

protected intnext(int bits){
long oldseed, nextseed;
AtomicLongseed=this.seed;
do{
oldseed = seed.get();
nextseed =(oldseed * multiplier + addend)& mask;
}while(!seed.compareAndSet(oldseed, nextseed));
return(int)(nextseed >>>(48- bits));
}

ThreadLocalRandom進行了優(yōu)化，其主要方式就是分段，通過讓每個線程擁有獨立的存儲空間，這樣即保證了線程安全，同時效率也不會太差。

public staticThreadLocalRandomcurrent(){
if(U.getInt(Thread.currentThread(), PROBE)==0)
localInit();
return instance;
}
staticfinalvoidlocalInit(){
intp= probeGenerator.addAndGet(PROBE_INCREMENT);
intprobe=(p ==0)?1: p;

// skip 0

// read and update per-thread seed

主要就是通過synchronized實現(xiàn)，是最基礎(chǔ)的鎖機制。

自旋鎖

在自旋鎖中，當一個操作需要訪問一個共享資源時，它會檢查這個資源是否被其他操作占用。如果是，它會一直等待，直到資源被釋放。在等待期間，這個操作會進入一個自旋狀態(tài)，也就是不會被系統(tǒng)掛起，但是也不會繼續(xù)執(zhí)行其他任務(wù)。當資源被釋放后，這個操作會立即返回并繼續(xù)執(zhí)行下一步操作。

自旋鎖是一種簡單而有效的同步機制，自旋鎖的優(yōu)點是減少線程上下文切換的開銷，但是它也有一些缺點。由于它需要一直進行自旋操作，所以會消耗一定的CPU資源。因此，在使用自旋鎖時需要仔細考慮并發(fā)問題和性能問題。

分段鎖

在分段鎖的模型中，共享數(shù)據(jù)被分割成若干個段，每個段都被一個鎖所保護，同時只有一個線程可以在同一時刻對同一段進行加鎖和解鎖操作。這種鎖機制可以降低鎖的競爭，提高并發(fā)訪問的效率。

ConcurrentHashMap的設(shè)計就是采用分段鎖的思想，其會按照map中的table capacity（默認16）來劃分，也就是說每個線程會鎖1/16的數(shù)據(jù)段，這樣一來就大大提升了并發(fā)訪問的效率。

讀寫鎖

讀寫鎖主要根據(jù)大多數(shù)業(yè)務(wù)場景都是讀多寫少的情況，在讀數(shù)據(jù)時，無論多少線程同時訪問都不會有安全問題，所以在讀數(shù)據(jù)的時候可以不加鎖，不過一旦有寫請求時就需要加鎖了。

• ? 讀、讀：不沖突

• ? 讀、寫：沖突

• ? 寫、寫：沖突

典型的如：ReentrantReadWriteLock

寫時復(fù)制最大的優(yōu)勢在于，在寫數(shù)據(jù)的過程時，不影響讀，可以理解為讀的是數(shù)據(jù)的副本，而只有當數(shù)據(jù)真正寫完后才會替換副本，當副本特別大、寫數(shù)據(jù)過程比較漫長時，寫時復(fù)制就特別有用了。

CopyOnWriteArrayList、CopyOnWriteArraySet就是集合操作時，為保證線程安全，使用寫時復(fù)制的實現(xiàn)

public E get(int index){
return elementAt(getArray(), index);
}
finalObject[] getArray(){
return array;
}
publicbooleanadd(E e){
synchronized(lock){
Object[] es = getArray();
intlen= es.length;
es =Arrays.copyOf(es, len +1);
es[len]= e;
setArray(es);
returntrue;
}
}
finalvoidsetArray(Object[] a){
array = a;
}

寫時復(fù)制也存在兩個問題，可以看到在add方法時使用了synchronized，也就是說當存在大量的寫入操作時，效率實際上是非常低的，另一個問題就是需要copy一份一模一樣的數(shù)據(jù)，可能會造成內(nèi)存的異常波動，因此寫時復(fù)制實際上適用于讀多寫少的場景。

對比說明

import java.util.Collections;
import java.util.Iterator;
import java.util.Set;
import java.util.UUID;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.CopyOnWriteArraySet;
import java.util.concurrent.CountDownLatch;

publicclassThreadSafeSet{
publicstaticvoidmain(String[] args)throwsInterruptedException{

//Set set = ConcurrentHashMap.newKeySet();

//CopyOnWriteArraySet set = new CopyOnWriteArraySet();

readMoreWriteLess(set);

System.out.println("==========華麗的分隔符==========");

//set = ConcurrentHashMap.newKeySet();

//set = new CopyOnWriteArraySet();

writeMoreReadLess(set);
}

privatestaticvoidwriteMoreReadLess(Set set) throwsInterruptedException{


//測20組

//創(chuàng)建9個線程，每個線程向set中寫1000條數(shù)據(jù)

//創(chuàng)建1個線程，每個線程從set中讀取所有數(shù)據(jù)，每個線程一共讀取10次。

//阻塞，直到10個線程都執(zhí)行結(jié)束

//測20組

//創(chuàng)建1個線程，每個線程向set中寫10條數(shù)據(jù)

//創(chuàng)建9個線程，每個線程從set中讀取所有數(shù)據(jù)，每個線程一共讀取100萬次。

經(jīng)過測試可以發(fā)現(xiàn)在讀多寫少時CopyOnWriteArraySet會明顯優(yōu)于ConcurrentHashMap.newKeySet()，但在寫多讀少時又會明顯弱于ConcurrentHashMap.newKeySet()。

當然使用CopyOnWriteArraySet還需要注意一點，寫入的數(shù)據(jù)可能不會被及時的讀取到，因為遍歷的是讀取之前獲取的快照。

這段代碼可以測試CopyOnWriteArraySet寫入數(shù)據(jù)不能被及時讀取到的問題。

public classCOWSetTest{
publicstaticvoidmain(String[] args)throwsInterruptedException{
CopyOnWriteArraySet set = new CopyOnWriteArraySet();
new Thread(()->{
try{
set.add( 1);
System.out.println( "第一個線程啟動，添加了一個元素，睡100毫秒");
Thread.sleep( 100);
set.add( 2);
set.add( 3);
System.out.println( "第一個線程添加了3個元素，執(zhí)行結(jié)束");
} catch(InterruptedException e){
e.printStackTrace();
}
}).start();



//保證讓第一個線程先執(zhí)行

//Thread.sleep(200);//如果在這邊睡眠，可以獲取到3個元素

//生成快照

//如果在這邊睡眠，只能獲取到1個元素

異步是提升系統(tǒng)響應(yīng)能力的重要手段之一，異步思想的應(yīng)用也非常的廣泛，常見的有：線程、MQ、事件通知、響應(yīng)式編程等方式，有些概念在前面的章節(jié)中也涉及到了，異步最核心的思想就是，先快速接收，后查詢結(jié)果，比如：如果接口處理時間較長，那么可以優(yōu)先響應(yīng)中間狀態(tài)（處理中），然后提供回調(diào)和查詢接口，這樣就可以大大提升接口的吞吐量！

10. for循環(huán)優(yōu)化減少循環(huán)

通?？梢酝ㄟ^一些高效的算法或者數(shù)據(jù)結(jié)構(gòu)來減少循環(huán)次數(shù)，尤其當出現(xiàn)嵌套循環(huán)時要格外小心。常見的方式比如：有序的查找可以用二分，排序可以用快排，檢索可以構(gòu)建Hash索引等等。

批量獲取

優(yōu)化前：每次查詢一次數(shù)據(jù)庫

for(String userId : userIds){
User user = userMapper.queryById(userId);
if(user.getName().equals("xxx")){


// ...

優(yōu)化后：先批量查詢出來，再處理

Map userMap = userMapper.queryByIds(userIds);
for(String userId : userIds){
User user = userMap.get(userId);
if(user.getName().equals( "xxx")){


// ...

優(yōu)化前：每次都要根據(jù)每個用戶的roleId去數(shù)據(jù)庫查詢一次。

Map userMap = userMapper.queryByIds(userIds);
for(String userId : userIds){
User user = userMap.get(userId);
Role role = roleMapper.queryById(user.getRoleId());
}

優(yōu)化后：每次根據(jù)roleId查詢過以后就暫記下來，后面再遇到相同roleId時即可直接獲取，這比較適用于一次循環(huán)中roleId重復(fù)次數(shù)較多的場景。

Map userMap = userMapper.queryByIds(userIds);
Map roleMap = new HashMap<>();
for(String userId : userIds){
@#@spiderLineB...