Любые удовлетворительные подходы к безопасности потоков модульного тестирования в Java?

Забудьте о хороших результатах тестирования на наличие проблем параллелизма. Попытайтесь уменьшить синхронизацию и уменьшить проблему. Затем используйте максимально возможную библиотечную поддержку для синхронизации. И только если вы действительно это сделали, попробуйте справиться с параллелизмом самостоятельно. Когда вы знаете, что каждый воркер делает свою работу правильно, и все ваши мысли говорят вам, что вы решили проблему параллелизма, тогда сгенерируйте интересную нагрузку. Платформы модульного тестирования и их расширения могут выполнять эту работу, но знайте, что вы больше не тестируете какие-либо модули. (Помните, вы уже рассмотрели эту часть)

Если ваша модель параллелизма усложняется, воспользуйтесь подходящими для этого инструментами, такими как SPIN.

Java Concurrency in Practice содержит полезную информацию о том, как писать тесты для решения проблем параллелизма. Однако они не являются настоящими модульными тестами. Почти невозможно написать настоящий модульный тест для решения проблемы параллелизма.

В основном это сводится к этому. Создайте кучу тестовых потоков и запустите их. Каждая нить должна

• дождитесь защелки обратного отсчета
• повторно вызывать некоторый метод, который изменяет рассматриваемое изменяемое состояние
• обратный отсчет до второй защелки и выход

Поток junit создает все потоки и запускает их, затем отсчитывает первую защелку один раз, чтобы отпустить их все, затем ждет вторую защелку, затем делает некоторые утверждения об изменяемом состоянии.

Даже в большей степени, чем для других типов ошибок, проще написать ошибочный модульный тест для ошибки параллелизма после обнаружения ошибки.

Есть две основные проблемы, которые вы должны решить. Во-первых, это: как вы генерируете конфликт потоков? Во-вторых, как вы проверяете свой тест?

Первый прямолинеен. Используйте большой молоток. Напишите некоторый код, способный обнаружить случай, когда один поток наступает на другой, и запустите этот код 50 раз или около того в 50 последовательных потоках. Вы можете сделать это с помощью защелки обратного отсчета:

public void testForThreadClash() {
  final CountDownLatch latch = new CountDownLatch(1);
  for (int i=0; i<50; ++i) {
    Runnable runner = new Runnable() {
      public void run() {
        try {
          latch.await();
          testMethod();
        } catch (InterruptedException ie) { }
      }
    }
    new Thread(runner, "TestThread"+i).start();
  }
  // all threads are waiting on the latch.
  latch.countDown(); // release the latch
  // all threads are now running concurrently.
}

Ваш testMethod() должен генерировать ситуацию, когда без синхронизированного блока какой-то поток будет наступать на данные другого потока. Он должен быть в состоянии обнаружить этот случай и выдать исключение. (Приведенный выше код этого не делает. Скорее всего, исключение будет сгенерировано в одном из тестовых потоков, и вам нужно добавить механизм, который обнаружит его в основном потоке, но это отдельная проблема. Я оставил это для простоты, но вы можете сделать это с помощью второй защелки, которую тест может преждевременно сбросить при возникновении исключения.)

Второй вопрос сложнее, но есть простое решение. Вопрос в следующем: откуда вы знаете, что ваш молот вызовет столкновение? Конечно, в вашем коде есть синхронизированные блоки для предотвращения конфликтов, поэтому вы не можете ответить на вопрос. Но вы можете. Просто удалите синхронизированные ключевые слова. Поскольку именно синхронизированное ключевое слово делает ваш класс потокобезопасным, вы можете просто удалить их и повторно запустить тест. Если тест действителен, теперь он не пройден.

Когда я впервые написал код выше, он оказался недействительным. Я никогда не видел столкновения. Так что это (пока) недействительный тест. Но теперь мы знаем, как получить четкий ответ на второй вопрос. Мы получаем неправильный ответ, но теперь мы можем изменить тест, чтобы сгенерировать ошибку, которую мы ищем. Вот что я сделал: я просто провел тест 100 раз подряд.

for (int j=0; j<100; ++j) {
  testForThreadClash();
}

Теперь мой тест надежно провалился примерно на 20-й итерации или около того. Это подтверждает, что мой тест действителен. Теперь я могу восстановить ключевое слово synchronized и повторно запустить тест, будучи уверенным, что он скажет мне, является ли мой класс потокобезопасным.

В некоторых случаях я обнаружил, что могу вызвать конкретное проблематичное чередование вызовов потенциально небезопасного для потоков класса, используя несколько потоков, которые синхронизируются друг с другом, возможно, с использованием CountDownLatch или какого-либо подобного механизма параллелизма. Однако иногда это просто не работает, например, если вы пытаетесь проверить, что произойдет, если два потока одновременно используют один и тот же метод.

Вот интересная статья (хотя я мало что знаю об этом инструменте): http://today.java.net/pub/a/today/2003/08/06/multithreadedTests.html

Нет ничего плохого в модульном тестировании многопоточного кода, если многопоточность является точкой кода, который вы тестируете (подумайте о параллельных структурах данных). Общий подход состоит в том, чтобы заблокировать основной тестовый поток, выполнять утверждения в отдельных потоках, захватывать и повторно выдавать любые неудачные утверждения в основном потоке, в противном случае разблокировать основной тестовый поток, чтобы тест мог завершиться. Это довольно просто сделать с помощью ConcurrentUnit:

@Test
public void shouldDeliverMessage() throws Throwable {
  final Waiter waiter = new Waiter();

  messageBus.registerHandler(message -> {
    // Called on separate thread
    waiter.assertEquals(message, "foo");

    // Unblocks the waiter.await call
    waiter.resume();
  };

  messageBus.send("foo");

  // Wait for resume() to be called
  waiter.await(1000);
}

Ключевым моментом здесь является то, что любые неудачные утверждения в любом потоке будут повторно выброшены waiter в основной поток, позволяя тесту пройти или не пройти, как и должно быть.