Конструкции типа while(true) или for(;;) довольно опасные. Когда люди их пишут, то всегда надеются на то, что сработает условие выхода из цикла. Однако, на самом деле, как бы мы ни были уверены, такие конструкции лучше избегать.

В любом программном продукте есть баги, и те инварианты, на которые идёт расчёт, могут просто не сработать. Решение? Читайте в переводе от команды Spring АйО, где автор указывает примеры того, как с этими конструкциями поступили в Jooq и как с ними работает один из департаментов University of California.

Мудрый человек однажды сказал:

Всё, что может пойти не так — пойдёт не так. — Мерфи

Некоторые программисты — мудрые люди, и один из них однажды сказал:

Хороший программист — это тот, кто смотрит по обеим сторонам, переходя улицу с односторонним движением. — Даг Линдер

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

for (;;) {
    // что-то
}

while (1) {
    // что-то
}

10 что-то  
20 GOTO 10

Хотите доказательств? Поиск по GitHub по запросу while(true) даёт тысячи совпадений: https://github.com/search?q=while+true&type=Code

Никогда не используйте потенциально бесконечные циклы

В информатике есть интересная проблема под названием «Проблема остановки» / “The Halting Problem”. Одна из особенностей данной проблемы заключается в том, что Алан Тьюринг много лет назад доказал, что эта проблема неразрешима. Со стороны и с высоты опыта нам, разработчикам, часто кажется, что это не так и мы всё контролируем.

Например, можно быстро понять, что выполнение следующего кода  будет бесконечным:

for (;;) continue;

…а вот эта программа завершится всегда:

for (;;) break;

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

Учимся на практике

В jOOQ недавно познакомились с проблемой остановки на собственном опыте. До исправления тикета #3696, мы использовали обходной путь для бага (или недоработки) в JDBC-драйвере SQL Server.

Эта ошибка приводила к тому, что цепочки исключений SQLException не сообщались корректно, например, когда следующий триггер выбрасывает несколько ошибок:

CREATE TRIGGER Employee_Upd_2 ON EMPLOYEE FOR UPDATE
AS
BEGIN
    RAISERROR('Employee_Upd_2 Trigger called...',16,-1)
    RAISERROR('Employee_Upd_2 Trigger called...1',16,-1)
    RAISERROR('Employee_Upd_2 Trigger called...2',16,-1)
    RAISERROR('Employee_Upd_2 Trigger called...3',16,-1)
    RAISERROR('Employee_Upd_2 Trigger called...4',16,-1)
    RAISERROR('Employee_Upd_2 Trigger called...5',16,-1)
END
GO

Чтобы поведение было единым для всех СУБД, мы явно «потребляли» эти исключения:

consumeLoop: for (;;) {
    try {
        if (!stmt.getMoreResults() && 
             stmt.getUpdateCount() == -1)
            break consumeLoop;
    }
    catch (SQLException e) {
        previous.setNextException(e);
        previous = e;
    }
}

Для большинства наших клиентов это работало, потому что цепочка исключений, как правило, конечна и небольшая. Даже в приведённом выше примере количество ошибок часто варьируется от 1 до 5. Я только что сказал… «как правило»?

Как уже было сказано выше: их может быть от 1 до 5. Но может быть и 1000. Или миллион. Или, что ещё хуже — бесконечное количество. Именно это случилось в тиките #3696, когда один из клиентов использовал jOOQ с SQL Azure.

В идеальном мире не может быть бесконечного количества SQLException, но наш мир далёк от идеала, и в SQL Azure тоже был баг (возможно, всё ещё есть), который снова и снова выбрасывал одну и ту же ошибку. Это привело к OutOfMemoryError, поскольку jOOQ создавал огромную цепочку исключений. Это всё же лучше, чем бесконечный цикл — по крайней мере, исключение легко отследить и обойти. А вот бесконечный цикл мог бы полностью заблокировать сервер для всех пользователей клиента.

Исправление выглядит теперь так:

consumeLoop: for (int i = 0; i < 256; i++) {
    try {
        if (!stmt.getMoreResults() && 
             stmt.getUpdateCount() == -1)
            break consumeLoop;
    }
    catch (SQLException e) {
        previous.setNextException(e);
        previous = e;
    }
}

В духе популярного высказывания:

640 КБ должно хватить всем

Единственное исключение

Как показал этот неловкий пример — всё, что может пойти не так, обязательно пойдёт не так. В контексте потенциально бесконечных циклов важно понимать, что такая ошибка может вывести из строя весь сервер.

В Лаборатории реактивного движения (Jet Propulsion Laboratory) при Калифорнийском технологическом институте эту проблему специально адресовали в гайдлайнах для написания кода:

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

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

 /* @non-terminating@ */

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

Заключение

Пройдитесь по своему коду уже сегодня и найдите все случаи while (true), for (;;) или do {} while (true);. Внимательно проверьте, могут ли они завершиться — с помощью break, throw, return или continue для внешнего цикла.

Скорее всего, вы (или кто-то до вас) писали этот код с мыслью:

… да ладно, этого не произойдёт.

Потому что мы все знаем, что происходит, когда думаешь, что ничего не произойдёт.

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.