Почему считается неправильным называть корутины легковесными потоками?

Разбор терминологии: корутины vs потоки

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

Ключевые различия в архитектуре

1. Уровень абстракции:

• Потоки (Threads) — это низкоуровневые примитивы операционной системы, управляемые планировщиком ОС. Каждый поток имеет собственный стек, регистры контекста и привязан к ядру процессора.
• Корутины (Coroutines) — это абстракция уровня пользователя, построенная поверх обычных потоков. Они управляются не ОС, а coroutine-планировщиком (dispatcher) внутри виртуальной машины Kotlin/библиотеки.

2. Модель выполнения:

// Пример с потоками (тяжеловесными)
fun threadExample() {
    val thread = Thread {
        println("Выполняется в потоке: ${Thread.currentThread().name}")
    }
    thread.start() // Запуск нового системного потока
}

// Пример с корутинами (легковесными)
suspend fun coroutineExample() = coroutineScope {
    launch {
        println("Выполняется в корутине: ${Thread.currentThread().name}")
    }
    // Та же корутина может продолжить выполнение в ДРУГОМ потоке
    withContext(Dispatchers.IO) {
        println("Теперь в другом потоке: ${Thread.currentThread().name}")
    }
}

Почему сравнение некорректно?

Потоки имеют фиксированные системные ограничения — каждый поток потребляет значительный объем памяти (обычно 1-2 Мб стека) и создание тысяч потоков невозможно. Корутины же используют общий пул потоков, а их переключение происходит без вмешательства ОС.

Семантика приостановки (suspension) vs блокировки (blocking):

• Поток блокируется — освобождает ресурсы процессора, но остаётся занятым в памяти
• Корутина приостанавливается — полностью освобождает поток для других задач

// Блокирующий вызов в потоке
fun blockingCall() {
    Thread.sleep(1000) // Поток БЛОКИРОВАН на 1 секунду
}

// Неблокирующий вызов в корутине
suspend fun nonBlockingCall() {
    delay(1000) // Корутина ПРИОСТАНОВЛЕНА, поток свободен
}

Критические отличия на практике

1. Стоимость создания:

• Создание потока: дорогая операция (~мс), требует системных вызовов
• Создание корутины: дешёвая операция (~наносекунды), выделение памяти в куче

2. Модель параллелизма:

• Потоки следуют preemptive multitasking — ОС может вытеснить поток в любой момент
• Корутины используют cooperative multitasking — корутина сама решает, когда приостановиться

3. Композиция и отмена:

// Структурированная конкурентность в корутинах
fun structuredConcurrency() = runBlocking {
    val parentJob = launch {
        val child1 = launch { /* дочерняя корутина 1 */ }
        val child2 = launch { /* дочерняя корутина 2 */ }
    }
    parentJob.cancel() // Автоматически отменяет ВСЕ дочерние корутины
}
// В потоках такой семантики нет — отмена родителей не влияет на детей

Правильная аналогия

Корутины правильнее называть "легковесными задачами" или "асинхронными функциями с состоянием". Они представляют собой:

• Suspendable computations — вычисления с возможностью приостановки
• Continuation-passing style — стиль программирования с явной передачей продолжения
• Structured concurrency primitive — примитив структурированной конкурентности

Заключение

Название "легковесные потоки" вводит в заблуждение, поскольку:

1. Создаёт ложное впечатление, что корутины — это просто оптимизированные потоки
2. Скрывает принципиально иную модель выполнения (cooperative vs preemptive)
3. Не отражает ключевую особенность — suspend/resume семантику
4. Игнорирует концепцию структурированной конкурентности, отсутствующую у потоков

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