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

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

首先，讓我們看一下被測系統：

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

如您所見，該類不是線程安全的，因為它通過inc（）方法公開了一些狀態。 狀態不是線程安全的（您可以使用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個線程執行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();}}

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

您可以使用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 }

該服務位于服務器中，是一個單例，每個請求都會生成一個線程，因此我們希望自動執行該部分。 我們可以使用壓力測試非確定性方法，也可以使用Weaver。 如果我們對這個問題進行深入思考，我們就會意識到我們要測試以下各項的每個組合（例如，線程1在x時刻執行第1行，線程2在x時刻執行第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所做的，它獲取一個方法并使用兩個線程執行上述組合。

如果我刪除了準備代碼（用@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);}

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

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

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

總結

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

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