△Hollis, 一個對Coding有著獨特追求的人△

這是Hollis的第?362?篇原創(chuàng)分享

作者 l Hollis

來源 l Hollis（ID：hollischuang）

上周，因為要測試一個方法的在并發(fā)場景下的結(jié)果是不是符合預(yù)期，我寫了一段單元測試的代碼。寫完之后截了個圖發(fā)了一個朋友圈，很多人表示短短的幾行代碼，涉及到好幾個知識點。

還有人給出了一些優(yōu)化的建議。那么，這是怎樣的一段代碼呢？涉及到哪些知識，又有哪些可以優(yōu)化的點呢？

讓我們來看一下。

背景

先說一下背景，也就是要知道我們單元測試要測的這個方法具體是什么樣的功能。我們要測試的服務(wù)是AssetService，被測試的方法是update方法。

update方法主要做兩件事，第一個是更新Asset、第二個是插入一條AssetStream。

更新Asset方法中，主要是更新數(shù)據(jù)庫中的Asset的信息，這里為了防止并發(fā)，使用了樂觀鎖。

插入AssetStream方法中，主要是插入一條AssetStream的流水信息，為了防止并發(fā)，這里在數(shù)據(jù)庫中增加了唯一性約束。

為了保證數(shù)據(jù)一致性，我們通過本地事務(wù)將這兩個操作包在同一個事務(wù)中。

以下是主要的代碼，當(dāng)然，這個方法中還會有一些前置的冪等性校驗、參數(shù)合法性校驗等，這里就都省略了：

@Servicepublic?class?AssetServiceImpl?implements?AssetService?{@Autowiredprivate?TransactionTemplate?transactionTemplate;@Overridepublic?String?update(Asset?asset)?{//參數(shù)檢查、冪等校驗、從數(shù)據(jù)庫取出最新asset等。return?transactionTemplate.execute(status?->?{updateAsset(asset);return?insertAssetStream(asset);});}}

因為這個方法可能會在并發(fā)場景中執(zhí)行，所以該方法通過事務(wù)+樂觀鎖+唯一性約束做了并發(fā)控制。關(guān)于這部分的細(xì)節(jié)就不多講了，大家感興趣的話后面我再展開關(guān)于如何防并發(fā)的內(nèi)容。

單測

因為上面這個方法是可能在并發(fā)場景中被調(diào)用的，所以需要在單測中模擬并發(fā)場景，于是，我就寫了以下的單元測試的代碼：

public?class?AssetServiceImplTest?{private?static?ThreadFactory?namedThreadFactory?=?new?ThreadFactoryBuilder().setNameFormat("demo-pool-%d").build();private?static?ExecutorService?pool?=?new?ThreadPoolExecutor(20,?100,0L,?TimeUnit.MILLISECONDS,new?LinkedBlockingQueue<Runnable>(128),?namedThreadFactory,?new?ThreadPoolExecutor.AbortPolicy());@Autowiredprivate AssetService?assetService;@Testpublic?void?test_updateConcurrent()?{Asset?asset?=?getAsset();//參數(shù)的準(zhǔn)備//...//并發(fā)場景模擬CountDownLatch?countDownLatch?=?new?CountDownLatch(10);AtomicInteger?atomicInteger?=new?AtomicInteger();????????????//并發(fā)批量修改，只有一條可以修改成功for?(int?i?=?0;?i?<?10;?i++)?{pool.execute(()?->?{try?{String?streamNo?=?assetService.update(asset);}?catch?(Exception?e)?{System.out.println("Error?:?"?+?e);failedCount.getAndIncrement();}?finally?{countDownLatch.countDown();}});}try?{//主線程等子線程都執(zhí)行完之后查詢最新的資產(chǎn)countDownLatch.await();}?catch?(InterruptedException?e)?{e.printStackTrace();}Assert.assertEquals(failedCount.intValue(),?9);//?從數(shù)據(jù)庫中反查出最新的Asset//?再對關(guān)鍵字段做注意校驗}}

以上，就是我做了簡化之后的單元測試的部分代碼。因為要測并發(fā)場景，所以這里面涉及到了很多并發(fā)相關(guān)的知識。

很多人之前和我說，并發(fā)相關(guān)的知識自己了解的很多，但是好像沒什么機(jī)會寫并發(fā)的代碼。其實，單元測試就是個很好的機(jī)會。

我們來看看上面的代碼涉及到哪些知識點？

知識點

以上這段單元測試的代碼中涉及到幾個知識點，我這里簡單說一下。

線程池

這里面因為要模擬并發(fā)的場景，所以需要用到多線程， 所以我這里使用了線程池，而且我沒有直接用Java提供的Executors類創(chuàng)建線程池。

而是使用guava提供的ThreadFactoryBuilder來創(chuàng)建線程池，使用這種方式創(chuàng)建線程時，不僅可以避免OOM的問題，還可以自定義線程名稱，更加方便的出錯的時候溯源。（關(guān)于線程池創(chuàng)建的OOM問題）

CountDownLatch

因為我的單元測試代碼中，希望在所有的子線程都執(zhí)行之后，主線程再去檢查執(zhí)行結(jié)果。

所以，如何使主線程阻塞，直到所有子線程執(zhí)行完呢？這里面用到了一個同步輔助類CountDownLatch。

用給定的計數(shù)初始化 CountDownLatch。由于調(diào)用了 countDown() 方法，所以在當(dāng)前計數(shù)到達(dá)零之前，await 方法會一直受阻塞。

AtomicInteger

因為我在單測代碼中，創(chuàng)建了10個線程，但是我需要保證只有一個線程可以執(zhí)行成功。所以，我需要對失敗的次數(shù)做統(tǒng)計。

那么，如何在并發(fā)場景中做計數(shù)統(tǒng)計呢，這里用到了AtomicInteger，這是一個原子操作類，可以提供線程安全的操作方法。

異常處理

因為我們模擬了多個線程并發(fā)執(zhí)行，那么就一定會存在部分線程執(zhí)行失敗的情況。

因為方法底層沒有對異常進(jìn)行捕獲。所以需要在單測代碼中進(jìn)行異常的捕獲。

????try?{String?streamNo?=?assetService.update(asset);}?catch?(Exception?e)?{System.out.println("Error?:?"?+?e);failedCount.increment();}?finally?{countDownLatch.countDown();}

這段代碼中，try、catch、finall都用上了，而且位置是不能調(diào)換的。失敗次數(shù)的統(tǒng)計一定要放到catch中，countDownLatch的countDown也一定要放到finally中。

Assert

這個相信大家都比較熟悉，這就是JUnit中提供的斷言工具類，在單元測試時可以用做斷言。這就不詳細(xì)介紹了。

優(yōu)化點

以上代碼涉及到了很多知識點，但是，難道就沒有什么優(yōu)化點了嗎？

首先說一下，其實單元測試的代碼對性能、穩(wěn)定性之類的要求并不高，所謂的優(yōu)化點，也并不是必要的。這里只是說討論下，如果真的是要做到精益求精，還有什么點可以優(yōu)化呢？

使用LongAdder代替AtomicInteger

我的朋友圈的網(wǎng)友@zkx 提出，可以使用LongAdder代替AtomicInteger。

java.util.concurrency.atomic.LongAdder是Java8新增的一個類，提供了原子累計值的方法。而且在其Javadoc中也明確指出其性能要優(yōu)于AtomicLong。

首先它有一個基礎(chǔ)的值base，在發(fā)生競爭的情況下，會有一個Cell數(shù)組用于將不同線程的操作離散到不同的節(jié)點上去(會根據(jù)需要擴(kuò)容，最大為CPU核數(shù)，即最大同時執(zhí)行線程數(shù))，sum()會將所有Cell數(shù)組中的value和base累加作為返回值。

核心的思想就是將AtomicLong一個value的更新壓力分散到多個value中去，從而降低更新熱點。所以在激烈的鎖競爭場景下，LongAdder性能更好。

增加并發(fā)競爭

朋友圈網(wǎng)友 @Cafebabe 和 @普渡眾生的面癱青年 以及 @嘉俊 ，都提到同一個優(yōu)化點，那就是如何增加并發(fā)競爭。

這個問題其實我在發(fā)朋友圈之前就有想到過，心中早已經(jīng)有了答案，只不過有多位朋友能夠幾乎同時提到這一點還是很不錯的。

我們來說說問題是什么。

我們?yōu)榱颂嵘l(fā)，使用線程池創(chuàng)建了多個線程，想讓多個線程并發(fā)執(zhí)行被測試的方法。

但是，我們是在for循環(huán)中依次執(zhí)行的，那么理論上這10次update方法的調(diào)用是順序執(zhí)行的。

當(dāng)然，因為有CPU時間片的存在，這10個線程會爭搶CPU，真正執(zhí)行的過程中還是會發(fā)生并發(fā)沖突的。

但是，為了穩(wěn)妥起見，我們還是需要盡量模擬出多個線程同時發(fā)起方法調(diào)用的。

優(yōu)化的方法也比較簡單，那就是在每一個update方法被調(diào)用之前都wait一下，直到所有的子線程都創(chuàng)建成功了，再開始一起執(zhí)行。

這里就可以用到CyclicBarrier來實現(xiàn)，CyclicBarrier和CountDownLatch一樣，都是關(guān)于線程的計數(shù)器。

CountDownLatch: 一個線程(或者多個)， 等待另外N個線程完成某個事情之后才能執(zhí)行。?

CyclicBrrier: N個線程相互等待，任何一個線程完成之前，所有的線程都必須等待。

所以，最終優(yōu)化后的單測代碼如下：

//主線程根據(jù)此CountDownLatch阻塞CountDownLatch?mainThreadHolder?=?new?CountDownLatch(10);//并發(fā)的多個子線程根據(jù)此CyclicBarrier阻塞CyclicBarrier?cyclicBarrier?=?new?CyclicBarrier(10);//失敗次數(shù)計數(shù)器LongAdder?failedCount?=?new?LongAdder();//并發(fā)批量修改，只有一條可以修改成功for?(int?i?=?0;?i?<?10;?i++)?{pool.execute(()?->?{try?{//子線程等待，所有線程就緒后開始執(zhí)行cyclicBarrier.await();//調(diào)用被測試的方法String?streamNo?=?assetService.update(asset);}?catch?(Exception?e)?{//異常發(fā)生時，對失敗計數(shù)器+1System.out.println("Error?:?"?+?e);failedCount.increment();}?finally?{//主線程的阻塞器奇數(shù)-1mainThreadHolder.countDown();}});}try?{//主線程等子線程都執(zhí)行完之后查詢最新的資產(chǎn)池計劃mainThreadHolder.await();}?catch?(InterruptedException?e)?{e.printStackTrace();}//斷言，保證失敗9次，則成功一次Assert.assertEquals(failedCount.intValue(),?9);//?從數(shù)據(jù)庫中反查出最新的Asset//?再對關(guān)鍵字段做注意校驗

以上，就是關(guān)于我的一次單元測試的代碼所涉及到的知識點，以及目前所能想到的相關(guān)的優(yōu)化點。

第一次被公眾號上近20萬讀者在線CodeReview，有點小小緊張。但是還是想問一下，對于這部分代碼，你覺得還有什么可以優(yōu)化的地方嗎？

?

技術(shù)交流群

最近有很多人問，有沒有讀者交流群，想知道怎么加入。

最近我創(chuàng)建了一些群，大家可以加入。交流群都是免費的，只需要大家加入之后不要隨便發(fā)廣告，多多交流技術(shù)就好了。

目前創(chuàng)建了多個交流群，全國交流群、北上廣杭深等各地區(qū)交流群、面試交流群、資源共享群等。

有興趣入群的同學(xué)，可長按掃描下方二維碼，一定要備注：全國 Or 城市 Or 面試 Or 資源，根據(jù)格式備注，可更快被通過且邀請進(jìn)群。

▲長按掃描

往期推薦

別去外包

匯報下《Java工程師成神之路》的進(jìn)展

學(xué)妹問我，并發(fā)問題的根源到底是什么？

如果你喜歡本文,

請長按二維碼，關(guān)注?Hollis.

轉(zhuǎn)發(fā)至朋友圈，是對我最大的支持。

點個?在看?

喜歡是一種感覺

在看是一種支持

↘↘↘

總結(jié)

以上是生活随笔為你收集整理的在线求CR，你觉得我这段Java代码还有优化的空间吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。