測試多線程代碼是一個艱巨的挑戰(zhàn)。 嘗試測試并發(fā)性時獲得的第一個建議是盡可能地在代碼中隔離并發(fā)問題。 這是一般的設計建議，但在這種情況下甚至更重要。 確保首先正確地對并發(fā)構造所包裝的邏輯進行單元測試。 否則，您可能會花費很長時間嘗試找出一個并發(fā)問題，最終發(fā)現這是有缺陷的業(yè)務邏輯。

了解了這些內容之后，您就可以考慮測試并發(fā)系統(tǒng)的策略。 GOOS涵蓋了您如何做到的。 在這里，您可以找到我將要解釋的代碼：

首先，讓我們看一下被測系統(tǒng)：

public class AtomicBigCounter {private BigInteger count = BigInteger.ZERO;public BigInteger count() {return count;}public void inc() {count = count.add(BigInteger.ONE);}}

如您所見，該類不是線程安全的，因為它通過inc（）方法公開了一些狀態(tài)。 狀態(tài)不是線程安全的（您可以使用AtomicInteger而不是BigInteger進行修復）。 為了測試該類，我們將包括一個非并行和并行測試。

@Test public void canIncreaseCounter(){...}@Test public void canIncrementCounterFromMultipleThreadsSimultaneously()throws InterruptedException {MultithreadedStressTester stressTester = new MultithreadedStressTester(25000);stressTester.stress(new Runnable() {public void run() {counter.inc();}});stressTester.shutdown();assertThat("final count", counter.count(),equalTo(BigInteger.valueOf(stressTester.totalActionCount())));}

壓力測試儀將使用m個線程執(zhí)行n個循環(huán)的方法。 隨著我們的方法遞增1，我們應該看到n*m等于counter.count() 。

有趣的類是MultithreadedStressTester：

public void stress(final Runnable action) throws InterruptedException {spawnThreads(action).await();}private CountDownLatch spawnThreads(final Runnable action) {final CountDownLatch finished = new CountDownLatch(threadCount);for (int i = 0; i < threadCount; i++) {executor.execute(new Runnable() {public void run() {try {repeat(action);}finally {finished.countDown();}}});}return finished;}private void repeat(Runnable action) {for (int i = 0; i < iterationCount; i++) {action.run();}}

如果執(zhí)行該測試，您將收到不同的結果，有時甚至會通過！ 那是因為該測試不是確定性的，所以我們無法確保線程在每次執(zhí)行中如何交錯。 如果我們希望盡可能確保此測試找到可能的錯誤，則應增加線程和迭代的數量，但要權衡時間。

您可以使用Weaver使用更具確定性的方法。 為了理解它是如何工作的，讓我們用一個例子來說明它。 假設我們有一個內存中而不是線程安全的存儲：

private final Map<Level, Scores> scoresByLevel;

我們有一些服務可以訪問包裝該存儲庫的存儲庫：

1 Optional<Scores> scoresFromStore = scoreRepo.findBy(score.level());2 if(scoresFromStore.isPresent()) {3 scoreRepo.update(score.level(), score);4 } else {5 scoreRepo.save(score.level(), new Scores().add(score));6 }

該服務位于服務器中，是一個單例，每個請求都會生成一個線程，因此我們希望自動執(zhí)行該部分。 我們可以使用壓力測試非確定性方法，也可以使用Weaver。 如果我們對這個問題進行深入思考，我們就會意識到我們要測試以下各項的每個組合（例如，線程1在x時刻執(zhí)行第1行，線程2在x時刻執(zhí)行第1行，將是-> T1 / 1： T2 / 1）

• T1 / 1：T2 / 1
• T1 / 1：T2 / 2
• T1 / 1：T2 / 3
• …。
• T1 / 2：T2 / 1
• T1 / 2：T2 / 2
• T1 / 2：T2 / 3
• …。

例如，如果T1 / 5和T2 / 2尚未保存，而T2已經從商店中獲得了空分，那么我們將遇到問題。 這意味著T1將得分保存在一個級別中，然后T2將這樣做，從而破壞了邏輯。 這正是Weaver所做的，它獲取一個方法并使用兩個線程執(zhí)行上述組合。

如果我刪除了準備代碼（用@ThreadedBefore注釋），則測試代碼將如下所示：

@ThreadedMainpublic void mainThread() {scoreService.save(LEVEL_ID, SCORE_VALUE, aUser);}@ThreadedSecondarypublic void secondThread() {scoreService.save(LEVEL_ID, ANOTHER_SCORE_VALUE, aUser);}@ThreadedAfterpublic void after() {Optional<Scores> scores = scoreRepo.findBy(aLevel());assertThat(scores.isPresent()).isTrue();assertThat(scores.get().contains(aScoreWith(aUser))).isTrue();assertThat(scores.get().contains(aDifferentScoreWith(aUser))).isTrue();}@Testpublic void testThreading() {new AnnotatedTestRunner().runTests(this.getClass(), ScoreService.class);}

由于確定性，該測試將始終失敗。 如您所見，測試并發(fā)性非常困難，這就是為什么我支持現代框架的原因，這些框架試圖將麻煩隱藏在平臺中或通過不可變數據解決問題。

• 您可以在此處了解更多信息。

翻譯自: https://www.javacodegeeks.com/2015/12/testing-multithreaded-code-java.html

總結

以上是生活随笔為你收集整理的用Java测试多线程代码的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。