withContext(Dispatchers.IO) + use {}: правильные границы I/O‑функций

1. Паттерн I/O‑обёртки в suspend-функции

Когда вы пишете программу, вам почти всегда кажется, что главное — «что она делает». Но в корутинах появляется ещё один слой реальности: «где и как она это делает». Файловые операции на JVM чаще всего блокирующие: поток реально ждёт диск, ОС, файловую систему, иногда даже сеть (если файл на сетевом диске). Если смешать это с вычислениями и не отделить аккуратно, программа начинает «тупить» в самых неожиданных местах — как будто у неё внезапно пропала мотивация жить.

Представьте кухню: Dispatchers.Default — это повара, которые режут, жарят и думают, а Dispatchers.IO — это курьер, который стоит в очереди за продуктами. Если вы заставите поваров стоять в очереди вместо курьера, кухня остановится. И да, это звучит смешно, пока вы не увидите, как «просто чтение файла» ломает отзывчивость всей программы.

Хорошая I/O‑функция в корутинном приложении обычно выглядит очень скучно — и это комплимент. Она делает минимум: читает/пишет/проверяет файл, и возвращает результат. Вся «умная» логика остаётся снаружи. Технически это почти всегда означает: suspend fun ... = withContext(Dispatchers.IO) { ... }.

Главная идея: мы явно отмечаем границу, где начинается блокирующий мир файловой системы. Благодаря этому вы, ваш тимлид и даже вы через неделю (самый строгий ревьюер) сможете быстро понять: «ага, вот тут мы ходим в файловую систему».

Мини‑пример: проверка существования файла

Эта функция кажется слишком простой, чтобы быть отдельной… но именно такие функции потом спасают проект от хаоса, потому что дают единый стиль.

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.io.File

suspend fun fileExists(path: String): Boolean =
    withContext(Dispatchers.IO) {
        File(path).exists()
    }

Ключевая мысль: даже exists() — это обращение к файловой системе. Не всегда «тяжёлое», но блокирующее по природе.

Возвращаем значение из withContext (и почему это удобно)

withContext { ... } — это выражение. Оно возвращает то, что возвращает последний оператор блока. Это делает I/O‑функции «обычными»: их легко читать, тестировать и использовать в логике.

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.io.File

suspend fun readTextIo(path: String): String =
    withContext(Dispatchers.IO) {
        File(path).readText()
    }

Здесь можно заметить приятное: readText() сам открывает/закрывает ресурс внутри себя, поэтому use { ... } нам не нужен. Но как только вы переходите к потокам/ридерам/врайтерам — use станет вашим лучшим другом.

Ранний выход: return@withContext

Когда внутри withContext вы хотите «вернуть null» или «закончить по условию», обычный return не подходит (он попытается выйти из всей функции). Вам нужен меточный return: return@withContext.

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.io.File

suspend fun readFirstLineOrNull(path: String): String? =
    withContext(Dispatchers.IO) {
        val file = File(path)
        if (!file.exists() || !file.isFile) return@withContext null

        file.bufferedReader().readLine()
    }

Сейчас мы намеренно сделали пример «без use», чтобы увидеть проблему: bufferedReader() нужно закрывать. Исправим в следующем разделе.

3. use { ... }: гарантированно закрываем ресурсы

В файловом I/O есть старая истина: «Открыть поток легко. Закрыть поток вовремя — это уже характер». В корутинах характер особенно важен, потому что выполнение может прерываться исключениями, отменой, ранним выходом и просто ошибками.

use { ... } — это Kotlin‑идиома, которая гарантирует закрытие ресурса (примерно как try/finally, только компактнее и менее склонно к копипасте). На JVM она работает для Closeable/AutoCloseable: ридеры, райтеры, потоки.

Правильное чтение первой строки: bufferedReader().use { ... }

Теперь перепишем прошлый пример так, чтобы он не оставлял открытый ресурс.

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import kotlin.io.use
import java.io.File

suspend fun readFirstLineOrNull(path: String): String? =
    withContext(Dispatchers.IO) {
        val file = File(path)
        if (!file.exists() || !file.isFile) return@withContext null

        file.bufferedReader().use { reader ->
            reader.readLine()
        }
    }

Что здесь важно заметить: use закрывает reader даже если readLine() бросит исключение. Это тот редкий случай, когда «магия» Kotlin — на самом деле просто аккуратный finally.

Запись текста через bufferedWriter().use { ... }

Запись тоже должна быть аккуратной. writeText() и appendText() удобны, но иногда вы хотите писать построчно, или контролировать переносы строк, или просто привыкли к Writer.

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import kotlin.io.use
import java.io.File

suspend fun writeLinesIo(path: String, lines: List<String>) {
    withContext(Dispatchers.IO) {
        val file = File(path)
        file.parentFile?.mkdirs()

        file.bufferedWriter().use { w ->
            for (line in lines) w.appendLine(line)
        }
    }
}

Обратите внимание на parentFile?.mkdirs(): это маленькая деталь, которая превращает программу из «падает на ровном месте» в «работает предсказуемо».

Вложенные use: нормально ли это?

Да, нормально. Иногда это выглядит как матрёшка, но это честная матрёшка: внешний ресурс закроется, внутренний тоже закроется. Например, если вы хотите «прочитать первую строку одного файла и дописать её в другой».

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import kotlin.io.use
import java.io.File

suspend fun copyFirstLine(from: String, to: String) {
    withContext(Dispatchers.IO) {
        File(from).bufferedReader().use { r ->
            File(to).bufferedWriter().use { w ->
                w.appendLine(r.readLine() ?: "")
            }
        }
    }
}

Этот пример специально простой. Большие копирования «по кускам» и отменяемость мы будем делать в следующих лекциях дня, чтобы не смешивать темы.

4. Разделяем I/O и обработку

Самая частая ошибка новичка (и иногда даже опытного разработчика, который «просто хотел побыстрее») — сделать «всё внутри withContext(Dispatchers.IO)». Файл прочитал, распарсил, посчитал статистику, отсортировал, отформатировал отчёт, записал отчёт… и вроде работает. Но это плохая архитектура: вы теряете контроль, где I/O, а где CPU, и начинаете случайно выполнять вычисления в IO‑пуле.

Правильнее мыслить так: I/O‑функция должна трогать файловую систему, но не должна быть «кухней всего блюда». Она приносит продукты, а готовит повар.

Плохой пример: «всё в одном месте»

Здесь мы намеренно делаем пример «неправильным», чтобы вы увидели проблему: смешали чтение файла и тяжёлую обработку.

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.io.File

suspend fun countLongLinesWrong(path: String): Int =
    withContext(Dispatchers.IO) {
        val lines = File(path).readLines()
        lines.count { it.trim().length >= 80 }
    }

Формально это работает. Но теперь CPU‑работа (trim(), length, count) живёт в IO‑контексте. Иногда это мелочь, иногда — начало больших тормозов.

Хороший пример: «сначала прочитали, потом посчитали»

Разделим на два слоя: I/O слой возвращает данные, доменный слой считает.

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.io.File

suspend fun readLinesIo(path: String): List<String> =
    withContext(Dispatchers.IO) { File(path).readLines() }

suspend fun countLongLines(path: String): Int {
    val lines = readLinesIo(path)
    return lines.count { it.trim().length >= 80 }
}

Да, стало на пару строк длиннее. Зато теперь у вас есть чёткое разделение: readLinesIo — про файлы, countLongLines — про логику. Если вы позже захотите оптимизировать обработку, кешировать, менять источник данных — вы не будете выковыривать это из «монолита».

Мини‑таблица: как проверять себя «на глаз»

После этого раздела удобно иметь короткое правило самопроверки:

Таблица простая, но в реальном проекте именно она экономит часы «почему оно тормозит».

5. Практика: File Organizer и аккуратный I/O‑слой

Чтобы примеры не были «в вакууме», представим, что у нас уже есть консольное приложение File Organizer из прошлых мини‑проектов: оно обходит директорию, выбирает файлы и раскладывает их по папкам. Сегодня мы не будем параллелить и не будем делать отмену — наша цель проще: оформить чистые I/O‑утилиты, которыми потом удобно пользоваться.

Пусть у нас есть два вспомогательных файла: organizer.ignore (список расширений, которые игнорируем) и organizer.log (журнал событий).

Читаем ignore‑лист как Set<String>

Сделаем функцию, которая читает строки, чистит пробелы и приводит к понятному виду. Важно: файловую часть держим в Dispatchers.IO, а «нормализацию» можно делать и снаружи — но тут она лёгкая, поэтому мы сделаем аккуратно и всё равно читаемо.

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.io.File

suspend fun readIgnoreExtensions(path: String): Set<String> =
    withContext(Dispatchers.IO) {
        val file = File(path)
        if (!file.exists()) return@withContext emptySet()

        file.readLines()
            .map { it.trim().lowercase() }
            .filter { it.isNotEmpty() && !it.startsWith("#") }
            .toSet()
    }

Здесь мы допустили небольшую обработку внутри IO, потому что она буквально «прибирает» входные строки и не превращает функцию в комбайн. Если бы там была тяжёлая статистика, сортировки на десятки тысяч строк и т.д. — выносили бы наружу.

Логирование: appendLine как отдельная I/O‑операция

Логи — это классика: вы пишете один appendText(...) в середине программы, потом второй, потом третий… и внезапно логирование размазано по проекту. Лучше сделать одну маленькую I/O‑утилиту.

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.io.File

suspend fun appendLogLine(path: String, line: String) {
    withContext(Dispatchers.IO) {
        val file = File(path)
        file.parentFile?.mkdirs()
        file.appendText(line + "\n")
    }
}

Да, это «всего две операции». Но именно так строятся проекты, которые не разваливаются: маленькие понятные кирпичики вместо «ну я тут быстренько».

Использование в main: runBlocking только на входе

Очень важная дисциплина: runBlocking живёт в main, а не в helper‑функциях. Helper‑функции должны быть suspend.

import kotlinx.coroutines.runBlocking

fun main() = runBlocking {
    val ignore = readIgnoreExtensions("config/organizer.ignore")
    println("Ignore: $ignore") // Ignore: [...]

    appendLogLine("logs/organizer.log", "Organizer started")
    println("Log written") // Log written
}

Такой main легко расширять: позже вы добавите обход файлов, параллельную обработку и отчёты, не ломая базовую архитектуру.

Где ставить withContext, а где — нет

Когда вы только начинаете, хочется найти «волшебное правило»: например, «вся функция в withContext(IO)». Но правильнее мыслить чуть иначе: withContext(Dispatchers.IO) ставится вокруг именно тех строк кода, которые трогают файловую систему. Не «вокруг функции», не «вокруг модуля», а вокруг конкретного блока I/O.

Нормальная схема потока управления

Чтобы закрепить картинку в голове, удобно представить это так:

flowchart TD
    A[main/runBlocking] --> B[Сценарий/логика]
    B --> C["withContext(Dispatchers.IO)"]
    C --> D[File API / Streams / Readers]
    D --> C
    C --> B
    B --> A

Смысл схемы: логика зовёт I/O‑кирпичик, I/O‑кирпичик «ныряет» в IO‑диспетчер, делает дело и возвращает результат обратно в логику.

Почему не стоит держать withContext(IO) «слишком широким»

Если вы напишете так: «вся команда organize работает в IO‑контексте», вы лишите себя возможности ясно отделить вычисления от файлов. Иногда это приведёт к тому, что CPU‑часть окажется в IO‑пуле (который вообще-то предназначен для ожидания I/O), и производительность станет непредсказуемой.

Грубо говоря: широкий withContext(IO) превращает IO‑контекст в мусорное ведро «для всего, что не знаю куда положить». А мы как раз учимся делать наоборот: раскладывать по полкам.

6. Типичные ошибки: Dispatchers.IO и use { ... }

Ошибка №1: делать runBlocking внутри helper‑функции, «потому что так проще вызвать suspend».
Это выглядит как лайфхак, но по сути вы сами себе вставляете палку в колесо: блокируете поток, ломаете structured concurrency и получаете странные подвисания в неожиданных местах. Если функция делает I/O — пусть она будет suspend, а запуск корутинного мира остаётся в main.

Ошибка №2: открывать bufferedReader()/inputStream() и забывать закрыть, потому что «ну оно же маленькое».
Маленькое сегодня — не значит маленькое завтра. Утечки файловых дескрипторов копятся, и в какой-то момент ОС скажет «хватит» (обычно самым неприятным образом). use { ... } — это не украшение, а страховка: ресурс закроется при любом исходе, включая исключения.

Ошибка №3: пихать тяжёлую обработку внутрь withContext(Dispatchers.IO), потому что «это же всё про файл».
Файл — это источник данных, но сортировки, агрегации и сложный разбор — это CPU‑работа. Если держать её в IO‑контексте, вы получите код, который сложно оптимизировать и сложно анализировать. Разделяйте: прочитали в IO, обработали снаружи.

Ошибка №4: делать I/O‑функцию «универсальным комбайном», который и читает, и валидирует, и печатает, и логирует.
Такой код быстро становится нечитаемым: у него десять причин измениться, и каждая новая фича добавляет ещё одну ветку. Гораздо спокойнее иметь несколько маленьких функций: readLinesIo, appendLogLine, writeLinesIo. Да, их больше. Зато каждая понятна и предсказуема.

Ошибка №5: забывать про return@withContext и пытаться использовать обычный return внутри блока.
Это частый «первый удар компилятора по голове» в корутинах. Если внутри withContext нужно выйти раньше, используйте return@withContext. Это не каприз Kotlin, а способ сделать управление потоком явным и безопасным.

Ошибка №6: смешивать подготовку директорий (mkdirs) и запись так, что при ошибке получается полурабочее состояние.
Даже в простых функциях полезно придерживаться дисциплины: сначала создать директорию (если нужно), затем открыть writer в use, затем писать. Вы так снижаете шанс оставить систему в странном промежуточном состоянии, особенно когда позже добавится отмена и параллельность.