Как я могу эффективно протестировать (модуль / интеграция) параллельный код в Java?

Question

Я видел этот пост уже на SO, но он все еще напрашивается, по крайней мере, для Java. Кажется, что это должно быть насущной проблемой для любого приложения (я тестирую веб-приложение для этого случая использования), которое является многопоточным. Как вы, ребята, справились с этим таким образом, чтобы ваши потоки могли чередоваться, что по сути означает тестирование поведения случайных потоков.

Answer 1

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

Также стоит запустить статический анализатор кода. Они обнаружат (среди прочего) несогласованную синхронизацию переменных и немедленно выделят области для беспокойства. FindBugs является одним из таких инструментов.

Answer 2

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

Доказать отрицание трудно или невозможно. Вы не можете доказать, что у вас нет проблемы параллелизма. Все, что вы можете сделать, это настроить свои тесты, чтобы выполнить его как можно более тщательно.

Answer 3

Я предлагаю вам получить Java-параллелизм на практике - он не только говорит вам, как избежать условий гонки, в первую очередь, есть раздел о тестировании параллелизма.

Также для Java доступны инструменты статического анализа параллелизма - к сожалению, хотя я знаю, что они есть, я не смог их оценить.

Answer 4

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

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

Answer 5

Мой ответ на этот вопрос заключается в том, чтобы избежать создания ситуаций, в которых вы можете испытывать гоночные условия при разумном использовании интеллектуального дизайна и существующих технологий. Например, если ваше приложение MT использует автономные рабочие элементы, вы можете встроить JMS-брокер в свое приложение для использования в качестве механизма связи между потоками. Аналогично с системными ресурсами, которые могут зависеть от состояния гонки, не делайте эти части многопоточными. Если у вас есть файлы, которые нужно записать, сделайте так, чтобы один поток отвечал за их запись с использованием информации, передаваемой через подсистему JMS.

В конечном счете, нет способа раскраски по номерам для тестирования кода MT, чтобы убедиться, что он не уязвим для состояния гонки.

Answer 6

Хороший способ проверить это - убедиться, что у вас есть доступ к машине с несколькими процессорами, а затем запустить тест как можно дольше / с как можно большим количеством итераций. Например, если у вас есть многопоточный алгоритм потребителя производителя, заполните очередь списком хорошего размера и используйте в 2 раза больше потоков, чем вы могли бы использовать в производстве. Это должно, по крайней мере, дать вам возможность чаще сталкиваться с проблемой гонки или проблемой синхронизации. Затем запустите этот тест в ежедневной сборке.