Thread Pool в мобильной разработке — основы, пул потоков и принцип работы

Что такое Thread Pool?

Thread Pool (пул потоков) — это архитектурный паттерн, при котором фиксированное количество потоков создаётся заранее и переиспользуется для выполнения множества задач. Вместо создания нового потока на каждую операцию (что дорого: около 1 МБ стека на поток в JVM), задачи помещаются в очередь и выполняются свободными потоками из пула. В мобильной разработке thread pool критически важен для производительности — Android и iOS ограничивают количество потоков на приложение.

Почему Thread Pool важен в мобильной разработке

Создание потока — дорогая операция: выделение стека, регистрация в системе, контекстное переключение. На мобильных устройствах с ограниченными ресурсами бесконтрольное создание потоков приводит к OOM (OutOfMemoryError) на Android и к троттлингу на iOS. Thread Pool решает обе проблемы: ограничивает максимальное количество одновременно работающих потоков и переиспользует уже созданные. Google рекомендует ExecutorService вместо raw Thread(), Apple recommends OperationQueue вместо Thread.

Как работает Thread Pool в мобильной разработке?

Thread pool работает по принципу Producer-Consumer: задачи (Runnable/Callable) помещаются в блокирующую очередь (BlockingQueue). Потоки из пула ожидают задачи в очереди и забирают их для выполнения. Алгоритм: если свободных потоков меньше corePoolSize, создаётся новый поток. Если corePoolSize достигнут, задача помещается в очередь. Если очередь заполнена и потоков меньше maximumPoolSize, создаётся дополнительный поток. При превышении maximumPoolSize задача отклоняется через RejectedExecutionHandler.

Core Pool Size vs Maximum Pool Size

Core pool size — количество потоков, которые поддерживаются в пуле даже в простое. Maximum pool size — максимальное количество потоков, которое может быть создано при переполнении очереди. Разница между ними — это дополнительные (overflow) потоки, которые создаются временно и завершаются после idle-таймаута. На мобильных устройствах рекомендуется устанавливать corePoolSize равным maximumPoolSize для избежания пиковых нагрузок от создания потоков.

Work Queue и RejectedExecutionHandler

BlockingQueue хранит задачи, ожидающие выполнения. Наиболее популярные реализации: LinkedBlockingQueue (неограниченная), ArrayBlockingQueue (ограниченная) и SynchronousQueue (без хранения — задача сразу передаётся потоку). При переполнении очереди и пула срабатывает RejectedExecutionHandler. Стандартные политики: AbortPolicy (бросает RejectedExecutionException), CallerRunsPolicy (выполняет в потоке отправителя), DiscardPolicy и DiscardOldestPolicy.

// Создание Thread Pool в Android
val threadPool = ThreadPoolExecutor(
    corePoolSize = 2,        // Минимум 2 потока
    maximumPoolSize = 4,     // Максимум 4 потока
    keepAliveTime = 30L,     // Время жизни overflow-потока
    unit = TimeUnit.SECONDS,
    workQueue = LinkedBlockingQueue<Runnable>(16),
    threadFactory = Executors.defaultThreadFactory(),
    handler = ThreadPoolExecutor.CallerRunsPolicy()
)

// Отправка задач
threadPool.execute {
    val result = api.fetchData()
    runOnUiThread { showData(result) }
}

// Завершение пула
threadPool.shutdown()
// Ожидание завершения всех задач
threadPool.awaitTermination(10, TimeUnit.SECONDS)

Thread Pool в Android: ExecutorService

Android предоставляет несколько реализаций thread pool через java.util.concurrent. Executors — фабрика с готовыми конфигурациями: newFixedThreadPool(n) (фиксированный пул), newCachedThreadPool() (неограниченный, потоки создаются по необходимости), newSingleThreadExecutor() (один поток — последовательное выполнение). Для мобильных проектов рекомендуется newFixedThreadPool с разумным лимитом (2-4 потока), так как cached пул может создать слишком много потоков.

ThreadPoolExecutor в Android

ThreadPoolExecutor (TPE) — полная реализация ExecutorService с настраиваемыми параметрами. На Android TPE используется внутри AsyncTask, IntentService и JobIntentService. Параметры corePoolSize, maximumPoolSize, keepAliveTime, BlockingQueue и RejectedExecutionHandler позволяют тонко настроить поведение пула. Рекомендации для Android: corePoolSize = количество ядер CPU - 1 (для IO-bound задач) или количество ядер (для CPU-bound задач). Для типовых приложений — 2-4 потока.

// Готовые конфигурации Executors
// 1. Фиксированный пул на 3 потока
val fixedPool = Executors.newFixedThreadPool(3)

// 2. Кешированный пул (не рекомендуется для мобильных)
val cachedPool = Executors.newCachedThreadPool()

// 3. Одиночный поток (сериализация)
val singlePool = Executors.newSingleThreadExecutor()

// 4. Планировщик (периодические задачи)
val scheduler = Executors.newScheduledThreadPool(2)

// Использование с Callable и Future
val future: Future<String> = fixedPool.submit(Callable {
    "Result: ${api.call()}"
})
// Получение результата (блокирует поток)
val result = future.get(5, TimeUnit.SECONDS)

// Завершение пула
fixedPool.shutdownNow()

CoroutineDispatcher как thread pool

Kotlin корутины предоставляют CoroutineDispatcher — абстракцию, аналогичную thread pool. Dispatchers.IO использует пул из 64 потоков (ограниченных). Dispatchers.Default — пул, равный количеству ядер CPU. CoroutineDispatcher не требует ручного shutdown и управляется автоматически. Для тонкой настройки создайте собственный ExecutorCoroutineDispatcher через Executors.newFixedThreadPool(2).asCoroutineDispatcher(). Корутины не заменяют thread pool, а оборачивают его.

Thread Pool в iOS: OperationQueue и GCD

iOS предоставляет два основных механизма для управления thread pool: OperationQueue (высокоуровневый API на основе GCD) и GCD DispatchQueue (низкоуровневый C-API). OperationQueue инкапсулирует thread pool через свойство maxConcurrentOperationCount. По умолчанию OperationQueue использует system-defined maximum (зависит от загрузки системы). DispatchQueue.global() предоставляет concurrent очередь с системным пулом потоков.

OperationQueue и maxConcurrentOperationCount

OperationQueue управляет пулом потоков через maxConcurrentOperationCount. Значение 1 создаёт serial очередь (аналог single thread pool). Значение больше 1 — concurrent пул с указанным лимитом. По умолчанию maxConcurrentOperationCount = NSOperationQueueDefaultMaxConcurrentOperationCount (системный оптимум, обычно 4-8 потоков). Operation поддерживает зависимости, приоритеты и отмену. Каждая операция выполняется на любом свободном потоке из системного пула.

// OperationQueue с пулом на 3 потока
let queue = OperationQueue()
queue.maxConcurrentOperationCount = 3
queue.qualityOfService = .utility

// Создание операций
let operation1 = BlockOperation {
    let data = fetchData(from: url1)
    DispatchQueue.main.async { updateUI(data) }
}

let operation2 = BlockOperation {
    let data = fetchData(from: url2)
    DispatchQueue.main.async { updateUI(data) }
}

// Зависимость: operation2 ждёт operation1
operation2.addDependency(operation1)

// Добавление в очередь
queue.addOperations([operation1, operation2], waitUntilFinished: false)

// Отмена всех операций
queue.cancelAllOperations()

GCD DispatchQueue как thread pool

DispatchQueue — это thread pool от Apple. Concurrent очередь (qos: .utility) использует системный пул потоков, оптимизированный для текущей загрузки устройства. Разные QoS (userInteractive, userInitiated, utility, background) отображаются на разные пулы с разным приоритетом. DispatchGroup позволяет синхронизировать несколько задач. DispatchWorkItem поддерживает отмену и qualityOfService. Для тонкого контроля создавайте собственные concurrent очереди через DispatchQueue(label: qos: attributes: .concurrent).

// GCD DispatchQueue как thread pool
let customQueue = DispatchQueue(
    label: "com.app.background",
    qos: .utility,
    attributes: .concurrent,
    autoreleaseFrequency: .workItem
)

// Отправка задач в пул
customQueue.async { self.processFile(file1) }
customQueue.async { self.processFile(file2) }

// DispatchGroup для синхронизации
let group = DispatchGroup()
let pool = DispatchQueue.global(qos: .utility)

pool.async(group: group) { fetchData() }
pool.async(group: group) { processImage() }

group.notify(queue: .main) {
    self.showResult() // Обе задачи завершены
}

// Ограничение concurrency через semaphore
let semaphore = DispatchSemaphore(value: 3)
for url in urls {
    pool.async {
        semaphore.wait()
        download(url)
        semaphore.signal()
    }
}

Параметры настройки Thread Pool

Конфигурация thread pool напрямую влияет на производительность приложения. Неверные параметры приводят к недоутилизации CPU (слишком мало потоков) или перегрузке системы (слишком много). Для мобильных приложений оптимальные значения отличаются от серверных из-за ограниченных ресурсов и энергопотребления. Основные параметры: corePoolSize, maxPoolSize, queue capacity и keepAliveTime.

Расчёт оптимального размера пула

Формула для IO-bound задач: corePoolSize = количество ядер CPU × 2 (потоки ожидают ввод-вывод). Для CPU-bound задач: corePoolSize = количество ядер CPU (потоки постоянно загружены вычислениями). На современных мобильных устройствах (6-8 ядер) это даёт 6-8 потоков для CPU-bound и 12-16 для IO-bound. Практические тесты показывают, что для типового мобильного приложения 3-4 потока оптимальны — больше потоков увеличивают энергопотребление без прироста производительности.

Queue Capacity и поведение при переполнении

Размер очереди задач (work queue) определяет, сколько задач может ожидать выполнения. Неограниченная очередь (LinkedBlockingQueue без лимита) может привести к OOM при быстром поступлении задач. Ограниченная очередь (ArrayBlockingQueue с фиксированным размером) отклоняет задачи при переполнении. Для мобильных приложений рекомендуется ArrayBlockingQueue с ёмкостью 16-32 задачи. CallerRunsPolicy — лучший RejectedExecutionHandler для мобильных: он замедляет отправителя (pressure back) вместо потери задачи.

Типовые ошибки при работе с пулом потоков

Разработчики мобильных приложений часто допускают ошибки при использовании thread pool, которые приводят к падениям, утечкам памяти и нестабильной работе. Наиболее частые: невызов shutdown() для ExecutorService, создание нового пула на каждую операцию, слишком большой пул, deadlock между задачами, использование CachedThreadPool на Android.

Deadlock в Thread Pool

Deadlock возникает, когда задача в пуле ожидает результат другой задачи из того же пула, но все потоки заняты ожиданием. Пример: задача А отправляет задачу Б в тот же пул и вызывает future.get() — если пул исчерпан, задача А ждёт задачу Б, а задача Б не может выполниться, так как нет свободных потоков. Решение: используйте отдельные пулы для разных уровней задач или async callback вместо блокирующего .get().

// Deadlock в Thread Pool
val pool = Executors.newFixedThreadPool(1)

// Задача А ждёт задачу Б — deadlock!
val futureA = pool.submit {
    // Эта задача никогда не выполнится
    val futureB = pool.submit { 42 }
    futureB.get() // Блокируется навсегда
}

// Исправление: отдельные пулы
val workerPool = Executors.newFixedThreadPool(2)
val callbackPool = Executors.newSingleThreadExecutor()

workerPool.submit {
    callbackPool.submit {
        // Выполняется в отдельном пуле — deadlock невозможен
    }
}

// Или используйте CompletableFuture
workerPool.submit {
    CompletableFuture
        .supplyAsync { 42 }
        .thenAccept { result ->
            println(result)
        }
}

Незавершённый пул и утечки

ExecutorService, созданный в Activity, должен быть завершён в onDestroy(). Если этого не сделать, потоки будут висеть в памяти даже после уничтожения Activity. Решение: сохраняйте пул в Application scope или ViewModel, а не в Activity. Для корутин используйте viewModelScope или lifecycleScope. Если пул создан внутри Activity, обязательно вызовите pool.shutdown() в onDestroy(). Для Test использовать es.shutdownNow() для немедленной остановки.