Модель конкурентности Swift претерпела парадигмальный сдвиг с Swift 5.5, введя структурированную конкурентность для замены устаревших паттернов Grand Central Dispatch, которые часто приводили к сиротским задачам и утечкам ресурсов. До этого разработчики вручную управляли экземплярами DispatchGroup, чтобы отслеживать параллельную работу, что требовало явной синхронизации для предотвращения условий гонки при отмене. Абстракция TaskGroup была разработана для того, чтобы инкапсулировать дерево отношений родитель-дочерний в родном виде, обеспечивая, чтобы среда выполнения сохраняла метаданные жизненного цикла, а не разработчик.
Основная проблема заключается в поддержании детерминированной иерархии, где родительские задачи могут надежно сигнализировать об отмене всем потомкам, не обращаясь к глобальным реестрам или ручным массивам слабых ссылок. Традиционные подходы, использующие OperationQueue, требуют явной регистрации и отмены обработчиков завершения, создавая хрупкое управление состоянием, которое разрушается, если обработчик завершения пропускается из-за раннего выхода. Более того, распространение отмены требует сложного опроса атомарного флага, что часто приводит к задержке реакции или чрезмерным затратам CPU.
Swift решает эту проблему, встраивая запись задачи в контекст каждой задачи, которая указывает на ее родителя, формируя инвазивный связный список, укорененный в TaskGroup. Когда вызывается addTask, среда выполнения вставляет запись дочерней задачи в этот список, атомарно регистрируя ее с обработчиком отмены родителя. Механизм отмены использует автомат, когда вызывается cancelAll(), среда выполнения проходит по этому списку, устанавливая флаг isCancelled в метаданных каждой дочерней задачи и пробуждая приостановленные исполняемые задачи. Это обеспечивает O(n) распространение, где n — это глубина дерева, избегая глобальных блокировок.
import Foundation func downloadImages(urls: [URL]) async throws -> [Data] { try await withThrowingTaskGroup(of: Data.self) { group in for url in urls { group.addTask { // Дочерняя задача автоматически проверяет отмену родителя let (data, _) = try await URLSession.shared.data(from: url) return data } } // Симуляция отмены пользователем group.cancelAll() var results: [Data] = [] for try await data in group { results.append(data) } return results } }
Приложение для обработки медиа нужно было создать эскизы для 10,000 изображений, позволяя пользователям отменять процесс в полете. Инженерная команда первоначально использовала подход с DispatchGroup, отслеживая активные объекты URLSessionDataTask в безопасном для потоков NSHashTable для обеспечения отмены.
Первое решение использовало DispatchGroup с DispatchSemaphore для ограничения параллелизма. Хотя это работало, требовалась сложная логика для удаления завершенных задач из набора для отмены. Произошли условия гонки, когда задачи завершались между сигналом отмены и перечислением набора, что приводило к ссылкам на освобожденные объекты. Этот подход также приводил к утечкам памяти, когда контроллер представления закрывался, поскольку уведомления DispatchGroup сильно удерживали делегата.
Второй подход использовал Combine's FlatMap с PassthroughSubject для отмены. Это обеспечивало лучшую составимость, но вводило значительные накладные расходы по памяти из-за распределения цепочки публикаций. Распространение отмены требовало хранения токенов AnyCancellable в коллекции, требующей ручной очистки. Декларативная абстракция скрывала реальную иерархию задач, затрудняя отладку, когда сигналы отмены не распространялись через цепочку операторов.
Команда перешла на TaskGroup в Swift. Это устранило необходимость вручную управлять NSHashTable, поскольку среда выполнения автоматически связывала каждую задачу по созданию эскизов с доменом отмены группы. Когда пользователь нажимал отмену, контроллер представления вызывал group.cancelAll(), что атомарно сигнализировало всем работающим задачам прекратить выполнение в следующей точке приостановки await. Это решение гарантировало, что никаких сиротских задач не продолжали обрабатывать после освобождения представления, а детерминированная область видимости withThrowingTaskGroup обеспечивала автоматическую очистку, даже если функция выдавала ошибку.
Задержка отмены сократилась с среднего значения 500 мс (ожидание ручного перечисления набора) до менее 10 мс (прямое прохождение по связанному списку). Профилирование памяти показало ноль утечек объектов Task после отмены, а кодовая база уменьшилась на 40 строк кода синхронизации.
Как TaskGroup обрабатывает ситуацию, когда дочерняя задача игнорирует отмену и продолжает выполняться бесконечно?
Кандидаты часто считают, что TaskGroup насильственно завершает задачи или вводит исключения. На самом деле, отмена в Swift является совместной: среда выполнения устанавливает флаг isCancelled в контексте задачи, но задача продолжает выполняться, пока не достигнет точки приостановки или явно не проверит Task.isCancelled. Дочерняя задача должна периодически опрашивать Task.checkCancellation() или полагаться на API, учитывающие отмену. Если задача выполняет тесный цикл, привязанный к CPU, без точек приостановки, она блокирует завершение группы на неопределенное время. Чтобы этого избежать, длительные вычисления должны использовать Task.yield() или разбивать работу на части с проверкой флагов отмены.
Почему добавление задачи в TaskGroup после вызова cancelAll() все равно приводит к немедленной отмене этой новой задачи?
Многие предполагают, что cancelAll() — это одноразовый сигнал, отправляемый только существующим дочерним задачам. Тем не менее, реализация Swift помечает саму TaskGroup как отмененную в ее статусной записи. Когда впоследствии вызывается addTask, среда выполнения атомарно проверяет состояние отмены группы во время создания задачи; если отменено, новая дочерняя задача создается с предварительно установленным флагом isCancelled. Это гарантирует, что поздно добавленные задачи не могут выйти за пределы домена отмены, поддерживая структурную гарантию, что отмененная область не может выдать новые допустимые результаты. Это предотвращает условия гонки, когда задачи, добавленные во время завершения отмены, пробиваются сквозь.
В чем фундаментальное различие между структурированной конкурентностью TaskGroup и задачей, созданной с помощью Task.init, в отношении управления памятью захваченных переменных?
Кандидаты часто упускают из виду, что дочерние задачи TaskGroup наследуют изоляцию акторов и приоритет родительского контекста, но более критично, они продлевают срок службы захваченных переменных только до выхода из области группы. Напротив, неструктурированные объекты Task, созданные с помощью Task { ... }, персистируют за пределами срока службы создающей области, потенциально захватывая self на неопределенное время. Это означает, что в TaskGroup, если вы захватываете self в addTask, вам не нужно использовать [weak self], потому что задача не может пережить блок withThrowingTaskGroup. Тем не менее, разработчики часто ошибочно применяют шаблоны [weak self] из неструктурированных задач, что делает код ненужным образом сложным и потенциально вводит ошибки ссылок на ноль, если они полагаются на self, находящийся в наличии для завершения.