1.場景

對賬系統(tǒng)流程圖

2.方案

1.直接按照邏輯

對賬系統(tǒng)單線程執(zhí)行示意圖

代碼實現(xiàn)

這樣雖然簡單，但是問題也很明顯，就是都是串行萨咕，效率比較低丑孩！

2.利用并行優(yōu)化對賬系統(tǒng)：

對賬系統(tǒng)并行執(zhí)行示意圖

代碼實現(xiàn)

while循環(huán)里面每次都會創(chuàng)建新的線程冀宴，而創(chuàng)建線程可是個耗時的操作。所以最好是創(chuàng)建出來的線程能夠循環(huán)利用温学，估計這時你已經(jīng)想到線程池了略贮，是的，線程池就能解決這個問題仗岖！但是線程池的方案里逃延，線程根本就不會退出，所以join就失效了轧拄！

方案3 用CountDownLatch+線程池：執(zhí)行圖還是如上圖

代碼實現(xiàn)

方案4:CyclicBarrier實現(xiàn)線程同步進一步優(yōu)化性能：

優(yōu)化思路：我們都知道前面?zhèn)z個方案都是先執(zhí)行查詢單和派送單揽祥，然后再進行對賬！也就是說檩电，執(zhí)行查詢單和派送單倆個操作是并行拄丰，但是和對賬操作是串行(對賬操作等到倆個操作都執(zhí)行完成，再統(tǒng)一dui賬)俐末，這個時候我們優(yōu)化的思路就是可不可以不等執(zhí)行查詢單和派送單都執(zhí)行完成再對賬料按，可以等查詢單和派送單分別查詢出有記錄的時候，就執(zhí)行對賬操作卓箫！

完全并行執(zhí)行示意圖

如何實現(xiàn)優(yōu)化：其實這有點類似于生產(chǎn)者消費者模型载矿，就是需要倆個隊列用來存放未對賬單和派送單每次查詢的記錄，然后消費者也就是對賬操作這個線程烹卒，負責從隊列里取記錄進行執(zhí)行對賬恢准！

過程:線程T1和線程T2只有都生產(chǎn)完1條數(shù)據(jù)的時候，才能一起向下執(zhí)行甫题，也就是說馁筐，線程T1和線程T2要互相等待，步調(diào)要一致坠非；同時當線程T1和T2都生產(chǎn)完一條數(shù)據(jù)的時候敏沉，還要能夠通知線程T3執(zhí)行對賬操作。

雙隊列示意圖

同步執(zhí)行示意圖

難點：一個是線程T1和T2要做到步調(diào)一致，另一個是要能夠通知到線程T3盟迟。

解決方案：用CyclicBarrier實現(xiàn)線程同步秋泳！(其實依然可以用一個計數(shù)器來解決這兩個難點，計數(shù)器初始化為2攒菠，線程T1和T2生產(chǎn)完一條數(shù)據(jù)都將計數(shù)器減1迫皱，如果計數(shù)器大于0則線程T1或者T2等待。如果計數(shù)器等于0辖众，則通知線程T3卓起，并喚醒等待的線程T1或者T2，與此同時凹炸，將計數(shù)器重置為2戏阅，這樣線程T1和線程T2生產(chǎn)下一條數(shù)據(jù)的時候就可以繼續(xù)使用這個計數(shù)器了，但是java給我們提供了更加強大的CyclicBarrier)

實現(xiàn)：線程T1負責查詢訂單啤它，當查出一條時奕筐，調(diào)用?barrier.await()?來將計數(shù)器減1，同時等待計數(shù)器變成0变骡；線程T2負責查詢派送單离赫，當查出一條時，也調(diào)用?barrier.await()?來將計數(shù)器減1塌碌，同時等待計數(shù)器變成0笆怠；當T1和T2都調(diào)用?barrier.await()?的時候，計數(shù)器會減到0誊爹，此時T1和T2就可以執(zhí)行下一條語句了蹬刷，同時會調(diào)用barrier的回調(diào)函數(shù)來執(zhí)行對賬操作。非常值得一提的是频丘，CyclicBarrier的計數(shù)器有自動重置的功能办成，當減到0的時候，會自動重置你設置的初始值

對賬

查詢操作

注意點：1. 執(zhí)行回調(diào)的線程池Executor executor =Executors.newFixedThreadPool(1);大小必須是1搂漠！如果設置為多個迂卢，有可能會兩個線程 A 和 B 同時執(zhí)行對賬操作，造成對賬的數(shù)據(jù)不匹配(可能A線程取到倆個隊列中不是一一對應的數(shù)據(jù))桐汤；所以1個線程實現(xiàn)生產(chǎn)數(shù)據(jù)串行執(zhí)行而克，保證數(shù)據(jù)安全！

2.調(diào)用的check不可以直接調(diào)用--》必須要在線程池中怔毛，如果不用線程池员萍，那執(zhí)行check這個操作的回調(diào)線程就是CyclicBarrier把計數(shù)器減為0的線程，也就是查詢線程在執(zhí)行check操作拣度，就會導致一個查詢線程在等待碎绎，一個查詢線程在執(zhí)行check操作螃壤，導致效率降低

方案5:CompletableFuture優(yōu)化方案三的寫法---》方案三的寫法也可以改為Future寫法

CompletableFuture優(yōu)化

總結(jié)

1.出現(xiàn)問題1：oom，如果隊列生產(chǎn)太快筋帖，消費者（對賬）來不及消費奸晴，就會出現(xiàn)oom

2.出現(xiàn)問題2:? 生產(chǎn)環(huán)境下真的可以保證訂單數(shù)據(jù)一一對應？