Dispatchers — key concepts, types of dispatchers and how they work

What are Dispatchers?

Dispatchers are implementations of the CoroutineDispatcher interface, which are elements of CoroutineContext. They determine on which thread or thread pool the coroutine will execute. When creating a coroutine via launch or async, the dispatcher can be passed as the first parameter: launch(Dispatchers.IO) { ... }. If no dispatcher is specified, it inherits from the outer CoroutineScope.

Kotlin provides four built-in dispatchers: Main, IO, Default, Unconfined. Each dispatcher uses its own thread pool optimized for a specific type of operation. Choosing the right dispatcher determines application performance: a wrong choice leads to UI lags, idle CPU cores, or inefficient thread usage.

Dispatchers.Main: UI Thread

Dispatchers.Main is the dispatcher that executes coroutines on the Android main thread. It is designed for UI-related operations: updating TextView, calling notifyDataSetChanged, working with LiveData and StateFlow. In Android, this dispatcher is implemented via Handler (Looper.getMainLooper()).

// Correct switch to Main for UI updates
viewModelScope.launch(Dispatchers.IO) {
    val data = repository.fetchData()
    withContext(Dispatchers.Main) {
        _uiState.value = data
    }
}

If a coroutine is already on the Main dispatcher, an additional withContext(Dispatchers.Main) does not create overhead — the dispatcher checks the current thread and skips the switch. withContext is the preferred way to switch between dispatchers.

Dispatchers.IO: Network and Disk Operations

Dispatchers.IO is a dispatcher optimized for I/O operations: HTTP requests (Ktor, OkHttp), reading and writing files, working with Room or SQLDelight. It uses a pool of 64 threads by default, scalable under load. Each new I/O request can create an additional thread until the limit is reached.

Limiting Parallelism

To control the number of concurrent I/O operations, use limitedParallelism(). This function creates a new dispatcher with a limit on the number of parallel threads, preventing pool exhaustion during bulk operations.

val limitedIo = Dispatchers.IO.limitedParallelism(4)

// Load 100 files with limit of 4 concurrent operations
coroutineScope {
    val files = (1..100).map { index ->
        async(limitedIo) {
            downloadFile("file_$index")
        }
    }
    files.awaitAll()
}

Use the IO dispatcher for all operations where the coroutine spends time waiting (I/O-bound). CPU-intensive tasks on the IO dispatcher are inefficient — they occupy threads intended for I/O, reducing the system's throughput.

Dispatchers.Default: CPU-Intensive Tasks

Dispatchers.Default is the dispatcher for computation operations that load the processor: sorting, filtering, JSON parsing (Moshi, Kotlinx Serialization), image processing, calculations. The pool size equals the number of processor cores (but not less than 2). This ensures maximum CPU utilization without context switching.

suspend fun processData(input: List<RawRecord>): List<ProcessedRecord> {
    return withContext(Dispatchers.Default) {
        input
            .parallelStream()
            .map { transform(it) }
            .toList()
    }
}

Do not use Dispatchers.Default for I/O operations — this will block CPU pool threads that could be processing computational tasks. Separating IO and Default allows optimal utilization of system resources: IO threads wait for I/O, CPU threads are constantly busy with computations.

Dispatchers.Unconfined: Current Thread

Dispatchers.Unconfined is a special dispatcher that does not bind a coroutine to any pool. The coroutine starts execution in the thread where launch/async was called, and after suspension resumes in the thread that called resume. This behavior is suitable for intermediate operations that do not require a fixed context.

fun main() = runBlocking {
    launch(Dispatchers.Unconfined) {
        println("Before delay: ${Thread.currentThread().getName()}")
        delay(500L)
        println("After delay: ${Thread.currentThread().getName()}")
    }
}

In production code, Dispatchers.Unconfined is rarely used. Main use cases: lightweight transformations before passing data to another dispatcher and tests. For production workloads, use explicit dispatchers — Unconfined is unpredictable because the execution thread depends on the resume implementation.

How to Choose a Dispatcher

Dispatcher selection depends on the task type: UI operations → Main, I/O-bound → IO, CPU-bound → Default, intermediate → inherit from scope. For Android, it is recommended to launch a coroutine on the dispatcher where the main work is performed, and switch to Main via withContext before updating the UI.

• Do not run I/O operations on the Main dispatcher — this blocks the UI
• Do not run CPU-intensive tasks on the IO dispatcher — this inefficiently consumes IO pool threads
• Use limitedParallelism to control concurrency during bulk I/O operations
• Switch dispatcher using withContext, not by creating a new scope
• Inherit the dispatcher from scope if the coroutine does not require a specific pool

For complex scenarios, combine dispatchers using the + operator: Dispatchers.IO + SupervisorJob() + CoroutineExceptionHandler. This creates a CoroutineContext with a specified dispatcher, error handling, and an isolated Job hierarchy.