Какие знаешь проблемы отмены корутины?

Проблемы отмены корутин в Kotlin

Отмена корутин — критически важный механизм, но с несколькими subtle проблемами, которые могут привести к утечкам памяти, блокировкам и неожиданному поведению. Вот основные проблемы и их решения:

1. Невозможность отмены внутри блокирующего кода

Корутины кооперативны — они должны проверять статус отмены. Блокирующий вызов (например, Thread.sleep(), блокирующие IO) не прерывается автоматически.

// ПРОБЛЕМА: эта корутина не отменится немедленно
fun problematicCancellation() = runBlocking {
    val job = launch {
        Thread.sleep(5000) // Блокирующий sleep, игнорирует отмену
        println("Это выполнится, даже если отменили раньше!")
    }
    delay(100)
    job.cancelAndJoin()
}

Решение: Использовать delay() вместо Thread.sleep() или обернуть блокирующий код в withContext(NonCancellable).

2. Игнорирование исключений отмены

При отмене корутина бросает CancellationException. Если этот exception перехватывается и не перебрасывается, корутина может продолжить выполнение.

// ПРОБЛЕМА: корутина не прерывается из-за перехвата CancellationException
suspend fun dangerousTask() {
    try {
        repeat(1000) { i ->
            delay(100)
            println(i)
        }
    } catch (e: Exception) { // Перехватывает ВСЕ исключения, включая CancellationException
        println("Просто логируем: ${e.message}")
        // Не перебрасываем CancellationException!
    }
    println("Корутина продолжится после отмены!") // Неожиданное поведение
}

Решение: Всегда перебрасывать CancellationException:

suspend fun safeTask() {
    try {
        repeat(1000) { i ->
            delay(100)
            println(i)
        }
    } catch (e: CancellationException) {
        throw e // Обязательно перебрасываем!
    } catch (e: Exception) {
        println("Другие исключения: ${e.message}")
    }
}

3. Утечки ресурсов при отмене

Если корутина захватывает ресурсы (файлы, сетевые соединения, транзакции БД), при отмене они могут не освободиться.

// ПРОБЛЕМА: файл может остаться открытым при отмене
suspend fun writeToFileWithLeak() {
    val file = File("data.txt").bufferedWriter()
    try {
        repeat(100) {
            delay(50)
            file.write("Data $it\n")
        }
    } finally {
        // Если корутину отменили ДО этого блока, файл останется открытым
        file.close()
    }
}

Решение: Использовать try-finally с проверкой isActive или use() для ресурсов:

suspend fun writeToFileSafely() {
    File("data.txt").bufferedWriter().use { file -> // Автоматическое закрытие
        repeat(100) {
            if (!isActive) throw CancellationException()
            delay(50)
            file.write("Data $it\n")
        }
    }
}

4. Проблемы с родительскими корутинами

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

// ПРОБЛЕМА: родительская корутина ждёт завершения некооперативной дочерней
fun parentChildProblem() = runBlocking {
    val parentJob = launch {
        launch {
            Thread.sleep(3000) // Некооперативная
            println("Дочерняя завершилась")
        }
        println("Родительская завершилась")
    }
    delay(100)
    parentJob.cancelAndJoin() // Будет ждать 3 секунды!
}

5. Race conditions при отмене

Состояние гонки может возникнуть, если несколько корутин пытаются отменить/перезапустить одну и ту же job.

// ПРОБЛЕМА: состояние гонки между отменой и перезапуском
var job: Job? = null

fun raceConditionExample() = runBlocking {
    job = launch {
        // Длительная операция
    }
    
    // Два параллельных вызова:
    launch { job?.cancel() }      // Может отменить
    launch { job = launch { /* перезапуск */ } } // Может перезапустить
    // Результат непредсказуем
}

Решение: Использовать Mutex или атомарные операции:

val mutex = Mutex()
suspend fun safeCancelAndRestart() {
    mutex.withLock {
        job?.cancelAndJoin()
        job = launch { /* новая операция */ }
    }
}

6. Отмена в finally-блоках

По умолчанию, при входе в finally блок после отмены, корутина уже находится в отменённом состоянии, и любые suspend-вызовы бросят CancellationException.

// ПРОБЛЕМА: suspend-вызовы в finally блоке после отмены
suspend fun problematicFinally() {
    try {
        // Длительная операция
    } finally {
        println("Cleaning up...")
        delay(100) // Выбросит CancellationException!
        println("Это никогда не выполнится")
    }
}

Решение: Использовать withContext(NonCancellable) для suspend-вызовов в finally:

suspend fun safeFinally() {
    try {
        // Длительная операция
    } finally {
        withContext(NonCancellable) {
            println("Cleaning up...")
            delay(100) // Теперь безопасно
            println("Ресурсы освобождены")
        }
    }
}

Лучшие практики для избежания проблем:

• Всегда проверяйте isActive в длительных циклах
• Используйте yield() для периодической проверки отмены
• Для блокирующего кода используйте suspendCancellableCoroutine
• Ресурсы освобождайте в finally блоках с NonCancellable
• Избегайте перехвата CancellationException без повторного выброса
• Используйте structured concurrency для управления жизненным циклом корутин

Правильная обработка отмены корутин требует внимания к деталям, но обеспечивает стабильность и эффективность асинхронного кода.