При проектировании сложных алгоритмов во встроенном языке «1С:Предприятие 8» перед разработчиком часто встает классическая дилемма: использовать понятную и элегантную рекурсию или написать более громоздкий, но надежный цикл. Особенно остро этот вопрос заявляет о себе при обработке иерархических структур данных — деревьев значений, справочников с неограниченной вложенностью, XML/JSON-документов или сложных спецификаций номенклатуры. В этой статье мы подробно разберем внутренние механизмы платформы, сравним потребление памяти циклами и рекурсией, выясним причины критических сбоев и научимся безопасно заменять рекурсивные вызовы итерационными методами.
Для того чтобы понять, почему рекурсия и циклы ведут себя в оперативной памяти совершенно по-разному, давайте проанализируем архитектуру управления памятью в операционных системах и самой платформе «1С». Любая выполняющаяся программа распределяет данные между двумя основными областями: системным стеком (Stack) и динамической памятью (Кучей / Heap).
Стек — это структура данных, работающая по принципу LIFO (Last In, First Out — «последним пришел, первым ушел»). Он выделяется операционной системой для каждого потока (thread) индивидуально и имеет жестко ограниченный размер. По умолчанию в Windows и Linux для потоков приложений, включая процессы «1С» (1cv8.exe, 1cv8c.exe, rphost.exe), размер системного стека составляет ровно 1 Мегабайт. Увеличить этот лимит стандартными средствами встроенного языка невозможно.
Куча — это огромный массив свободной оперативной памяти компьютера или сервера. В ней создаются динамические объекты: таблицы значений, массивы, структуры, прикладные объекты базы данных и длинные строки. Лимиты кучи определяются исключительно доступной физической памятью (RAM) и разрядностью операционной системы.
Давайте проанализируем, как эти области памяти ведут себя при выполнении циклов и рекурсии:
Давайте разберем по шагам, сколько памяти расходуется на один уровень вложенности рекурсии. На основе практических тестов с использованием системных утилит мониторинга памяти (таких как VmMap) было установлено, что в современных релизах платформы «1С:Предприятие 8.3» на один шаг рекурсии тратится примерно от 1.5 до 2.5 Кбайт стека.
Проведем несложный математический расчет. Если общий размер стека потока равен 1024 Кбайт (1 Мб), а один вызов забирает около 1.5 Кбайт, то предельно допустимый лимит глубины рекурсии составит:
1024 Кбайт / 1.5 Кбайт ≈ 680 уровней вложенности.
В зависимости от версии платформы и режима выполнения эти цифры могут незначительно меняться:
Главная опасность глубокой рекурсии в 1С заключается в характере обработки ошибки переполнения стека (Stack Overflow). Разработчики привыкли, что практически любую нештатную ситуацию в коде можно локализовать с помощью конструкции Попытка ... Исключение. Однако в случае со стеком это правило не работает.
Переполнение стека — это системное исключение уровня операционной системы (Hardware Exception), а не встроенного языка. Когда лимит в 1 Мб исчерпан, операционная система мгновенно прекращает работу процесса. Платформа 1С не успевает обработать это событие, записать лог в технологический журнал или выдать штатное сообщение об ошибке.
Происходит следующее:
rphost.exe. Это приводит к тому, что все остальные пользователи, чьи сеансы обслуживались данным процессом rphost.exe, также получат аварийный разрыв соединения и потеряют несохраненные данные.Поэтому фирма «1С» в своих официальных стандартах разработки настоятельно рекомендует избегать алгоритмов, глубина рекурсии в которых потенциально может превысить несколько десятков уровней.
Существует распространенное заблуждение, что если передавать в рекурсивную функцию много параметров, то стек переполнится значительно быстрее. Эксперименты показывают, что добавление новых аргументов в функцию практически не влияет на предельную глубину рекурсии в 1С.
Выясним причину этого явления. Во встроенном языке все сложные типы данных (объекты, структуры, таблицы значений, массивы) передаются в процедуры и функции по ссылке (передаются указатели на адреса в оперативной памяти кучи), а не копированием самих данных. Таким образом, в стековом фрейме создается лишь маленькая запись адреса (указателя), размер которой фиксирован.
Однако разрядность платформы играет критическую роль:
Как результат: на 64-разрядных серверах и клиентах 1С лимит безопасной глубины рекурсии всегда ниже, чем на 32-разрядных системах при абсолютно одинаковом коде.
Что же делать, если перед нами стоит задача гарантированно обойти сложную иерархическую структуру произвольной глубины, не рискуя уронить рабочий процесс сервера? Для этого применяется паттерн проектирования, который разработчики называют «эмуляцией стека» или «рекурсией без рекурсии».
Суть метода заключается в том, что мы отказываемся от вызова функций из самих себя. Вместо этого мы используем обычный цикл Пока, а системный стек вызовов заменяем обычным прикладным объектом Массив, который создается в куче (динамической памяти). Поскольку куча ограничена только физической RAM компьютера, мы можем безболезненно обрабатывать миллионы уровней вложенности.
Давайте разберем по шагам классический пример. Представим, что нам необходимо обойти дерево групп и элементов справочника «Номенклатура» (или любую другую древовидную структуру) и собрать все элементы в один плоский список.
Рассмотрим стандартный рекурсивный вариант, который опасен для использования при больших объемах данных:
Процедура ОбведиДеревоРекурсивно(ТекущаяГруппа, Результат)
// Получаем подчиненные элементы и группы
Выборка = Справочники.Номенклатура.Выбрать(ТекущаяГруппа);
Пока Выборка.Следующий() Цикл
Если Выборка.ЭтоГруппа Тогда
// РЕКУРСИВНЫЙ ВЫЗОВ — потенциальная точка отказа при глубокой иерархии!
ОбведиДеревоРекурсивно(Выборка.Ссылка, Результат);
Иначе
Результат.Добавить(Выборка.Ссылка);
КонецЕсли;
КонецЦикла;
КонецПроцедуры
А теперь давайте перепишем этот алгоритм, применив паттерн эмуляции стека (LIFO) с помощью объекта Массив. Мы превратим рекурсию в надежный и производительный цикл:
Функция ПолучитьВсеЭлементыИтеративно(СтартоваяГруппа)
Результат = Новый Массив;
// Создаем свой собственный "стек" в куче памяти
СтекГрупп = Новый Массив;
СтекГрупп.Добавить(СтартоваяГруппа);
// Основной цикл выполняется, пока в нашем стеке есть необработанные папки
Пока СтекГрупп.Количество() > 0 Цикл
// Извлекаем последний элемент из стека (принцип LIFO)
ИндексПоследнего = СтекГрупп.Количество() - 1;
ТекущаяГруппа = СтекГрупп[ИндексПоследнего];
СтекГрупп.Удалить(ИндексПоследнего);
// Выбираем данные только для одной текущей группы
Выборка = Справочники.Номенклатура.Выбрать(ТекущаяГруппа);
Пока Выборка.Следующий() Цикл
Если Выборка.ЭтоГруппа Тогда
// Вместо вызова процедуры помещаем новую папку в наш стек в куче
СтекГрупп.Добавить(Выборка.Ссылка);
Иначе
// Полезная работа: собираем элементы
Результат.Добавить(Выборка.Ссылка);
КонецЕсли;
КонецЦикла;
КонецЦикла;
Возврат Результат;
КонецФункции
Проанализируем преимущества, которые мы получаем при отказе от рекурсии в пользу эмуляции стека в цикле:
rphost.exe.Выполнить()), где создание полноценных рекурсивных локальных процедур синтаксически невозможно.Подводя итог нашему исследованию, можно сделать однозначный вывод: для оптимизации потребления памяти и обеспечения стабильности корпоративных систем на базе «1С:Предприятие 8» циклы всегда предпочтительнее рекурсии. Используйте рекурсию только тогда, когда вы абсолютно уверены, что глубина вложенности данных гарантированно ограничена жесткими рамками (не более 15–20 уровней), а во всех остальных случаях отдавайте предпочтение итерационным циклам с эмуляцией стека в динамической памяти.