Coroutines Basics

Introduction

Coroutines are Kotlin's answer to writing asynchronous, non-blocking code without the deeply nested callbacks that plague callback-based async code, and without the heavy resource cost of spawning a full OS thread per task. They became stable in Kotlin 1.3 (2018) and are now the standard way to handle concurrency in Kotlin, from Android apps to backend services.

This lesson introduces the core building blocks: `suspend` functions, the `launch` and `async` coroutine builders, `runBlocking`, structured concurrency, and `Dispatchers` for choosing where coroutines run.

The Problem Coroutines Solve

Imagine a function that needs to fetch data from a network call, then a database, then process the results — each step takes real time and shouldn't block the thread it runs on while waiting. Traditionally, you either block a thread (wasteful, and threads are expensive — typically limited to a few thousand per process) or use callbacks (which nest deeply and become hard to read and reason about, sometimes called "callback hell"). Coroutines let you write this code sequentially, top to bottom, while the compiler transforms it under the hood into non-blocking code that suspends and resumes without tying up a full thread while waiting.

suspend Functions

A function marked `suspend` can pause its execution at certain points (typically while waiting on I/O) without blocking the underlying thread, then resume later exactly where it left off. A `suspend` function can only be called from another `suspend` function, or from inside a coroutine — this restriction is enforced by the compiler, so you always know exactly where suspension is possible.

import kotlinx.coroutines.delay

suspend fun fetchUserName(): String {
    delay(1000)              // simulates a non-blocking network call
    return "Priya"
}

`delay()` is coroutines' non-blocking equivalent of `Thread.sleep()` — it suspends the coroutine without blocking the thread it was running on, freeing that thread to do other work in the meantime.

Getting Set Up

Coroutines are not part of the Kotlin standard library itself — they require the `kotlinx-coroutines-core` library, maintained by JetBrains. In a Gradle project, add it as a dependency.

// build.gradle.kts
dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.0")
}

runBlocking and launch

`runBlocking` starts a coroutine and blocks the current thread until it completes — it exists mainly to bridge regular blocking code (like a `main` function) into the coroutine world, and is commonly used in examples and tests. `launch` starts a new coroutine that runs concurrently and does not return a result.

import kotlinx.coroutines.*

fun main() = runBlocking {
    println("Start")

    launch {
        delay(1000)
        println("Coroutine finished after 1 second")
    }

    println("End of main (coroutine still running in the background)")
}

Notice the order: `launch` starts the coroutine and immediately continues running the rest of `main`, without waiting. The delayed message prints last, once its one-second delay elapses — this is exactly the non-blocking behavior coroutines are designed to provide.

async and await

Unlike `launch`, `async` starts a coroutine that produces a result, returned as a `Deferred<T>`. Calling `.await()` on it suspends until that result is ready. This is the standard pattern for running multiple independent operations concurrently and then combining their results.

import kotlinx.coroutines.*

suspend fun fetchScore(): Int {
    delay(500)
    return 42
}

suspend fun fetchBonus(): Int {
    delay(300)
    return 8
}

fun main() = runBlocking {
    val score = async { fetchScore() }
    val bonus = async { fetchBonus() }

    println("Total: ${score.await() + bonus.await()}")
}

Because both `async` calls start immediately and run concurrently, the total time here is roughly 500ms (the longer of the two), not 800ms (their sum) — a sequential pair of plain `suspend fun` calls without `async` would have taken the full 800ms instead.

Structured Concurrency

Kotlin coroutines follow a principle called structured concurrency: every coroutine runs inside a `CoroutineScope`, and a parent scope will not complete until all the coroutines launched inside it have finished. This prevents coroutines from silently leaking or outliving the context that started them — if the parent scope is cancelled, every coroutine launched inside it is automatically cancelled too.

Dispatchers

A `Dispatcher` determines which thread (or thread pool) a coroutine runs on. You choose a dispatcher explicitly rather than managing threads by hand.

import kotlinx.coroutines.*

suspend fun loadFromNetwork(): String = withContext(Dispatchers.IO) {
    delay(500)
    "Downloaded data"
}

fun main() = runBlocking {
    println(loadFromNetwork())
}

Coroutines vs Threads

A coroutine is far lighter weight than an OS thread — you can comfortably run tens of thousands of coroutines concurrently, where a similar number of raw threads would exhaust system resources. Multiple coroutines can share and take turns on the same small pool of underlying threads, since a suspended coroutine releases its thread instead of blocking it.

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

You now understand the core building blocks of Kotlin coroutines — suspend functions, launch, async/await, and dispatchers. Next, in the final lesson of this course, you'll wrap up with idiomatic Kotlin best practices and where to go from here.