I always dreaded asynchronous programming, but Kotlin Coroutines have transformed how we handle asynchronous programming on the JVM. Unlike traditional threading, which is resource-heavy and difficult to manage, coroutines provide a lightweight, more efficient way to handle concurrency. This enables us to write non-blocking code that is easier to read and maintain.

1. Understanding Coroutines: The Basics

Think of coroutines as your multitasking buddy: they let you juggle tasks without breaking a sweat or crashing the system. Coroutines run in threads, but unlike traditional threads, coroutines can be paused and resumed without blocking the thread they’re running on, making them much more efficient. This is achieved through the concept of suspension, which we'll explore later on.

There are a few core concepts I want to cover:

  • Scopes
  • Context and Dispatchers
  • How to start coroutines
  • Suspend Functions

2. Coroutine Scope

A CoroutineScope defines the lifecycle and context for coroutines. It manages the lifecycle of coroutines, meaning that if the scope is cancelled, all coroutines within it are also cancelled. This helps prevent memory leaks and keeps code organised by grouping coroutines into logical scopes.

There are two types of scope I want to talk about:

Global Scope

The GlobalScope lives for the entire application lifecycle. Since it is not tied to any specific lifecycle, we should use it with caution. If we use it incorrectly, it may lead to memory leaks or unwanted background work continuing after we no longer need it.

To use GlobalScope, we explicitly refer to it:

GlobalScope.launch {
    // Some code that runs in the background
}

Doing so will produce the following compiler warning:

“This is a delicate API, and its use requires care. Make sure you fully read and understand documentation of the declaration that is marked as a delicate API.”

While convenient, it is prone to causing memory leaks if coroutines are not properly managed. In order to limit those potential issues, the community recommends the usage of a custom scope.

Custom Coroutine Scope

A custom scope allows us to manage its lifecycle and control which thread we want to run our coroutines on. To do this, we define a Job - a handler that represents a unit of work, managing its lifecycle (e.g. start, cancel, complete) and tracking its execution state. With this job, we can then create a scope with the desired Dispatcher.

val someJob = Job()
val context : CoroutineContext = Dispatchers.IO + someJob
val scope = CoroutineScope(context)

By cancelling the job, we can stop all the coroutines running in that scope:

someJob.cancel()

This ensures that any coroutines launched inside the scope are also cancelled and that there are no memory leaks.

3. Contexts and Dispatchers

In the example above, we built a CoroutineScope, but we passed a CoroutineContext to it. So, what is this context? A CoroutineContext defines the configuration of a coroutine. It specifies the thread the coroutine runs on, how it handles cancellation, and how it deals with errors. Choosing the right context and dispatcher can significantly impact performance. For example, using Dispatchers.IO for network requests is more efficient than using Dispatchers.Default.

The Dispatchers control which thread a coroutine runs on. Some common dispatchers are:

  • Dispatchers.IO: Optimised for I/O-bound operations (e.g., database access, file operations, network requests).
  • Dispatchers.Default: Optimised for CPU-intensive work (e.g., computations).
  • Dispatchers.Main: Used for UI operations (e.g., in Android).

The IO and Default dispatchers share a thread pool but are optimised for different scenarios. The IO dispatcher is designed for I/O-bound tasks, such as network requests or file operations.  The threads in the IO dispatcher scale adaptively based on the number of tasks, up to 64.

On the other hand, the Default dispatcher is optimised for CPU-bound tasks, like complex computations. It maintains a fixed number of threads, equal to the number of available CPU cores, with a minimum of 2 threads and a maximum of 64.

Finally, the Main dispatcher is a dispatcher designed for UI updates. It runs on a single thread, ensuring that all updates to the UI happen on the main thread, as required by most UI frameworks.

Example:

launch(Dispatchers.IO) {
    fetchDataFromDatabase()
}

For backend development, we usually use a mix of IO and Default dispatchers.

4. Launch, async, runBlocking and withContext

Now let us take a look at how to use some of the key coroutine functions in Kotlin: launch, async, runBlocking and withContext.

Launch – Fire and Forget

The launch function is a coroutine builder used when we don’t need a result from the coroutine. It starts a new coroutine and immediately returns a Job that represents the coroutine. This is useful when we want to start a background task without waiting for a result.

Example:
runBlocking{ // Wait for coroutines inside this block before continuing  
  launch(Dispatchers.IO) {
    // Perform I/O-bound work
    println("Data fetching started")
    delay(1000) // Non-blocking way of suspending a coroutine for a second
    println("Data fetching completed")
  }
}

In this example, the coroutine runs in the background and prints a message, but there is no need to await or return a result. The coroutine runs independently.

Async – For Results

When we want to start a coroutine that produces a result, we can use async. Async returns a Deferred object, which represents a promise of a future result. We can use the await() function on the Deferred object to get the result once the coroutine completes.

Example:
runBlocking {
  val result = async(Dispatchers.IO) {
    // Perform I/O-bound work and return a result
    delay(1000)
    "Data fetched"
  }.await()  // Waits for the result
  println("Received: $result")
}

In this example, the coroutine fetches data and returns a string. We then use await() to get the result from the Deferred object.

RunBlocking - Blocking builder

In the example above, both async and launch are called inside the runBlocking block. Why is this necessary? The key point is that both async and launch require a coroutine scope to be executed. The runBlocking function creates such a scope, but with a difference - it blocks the current thread until all coroutines within it have completed.

This is useful for scenarios where we want to proceed only after all coroutines have completed.

Now that we have discussed the behaviour of scope and runBlocking, can you guess the printing order of the following code?

// Blocking the thread until completion
runBlocking {
  println("Starting async work")
  launch {
    delay(1000)
    println("Launch work finished")
  }
  print("Waiting for runBlocking to finish")
}
println("Finished up async work")

Output: 

// Starting async work
// Waiting for runBlocking to finish
// Launch work finished
// Finished up async work

WithContext – Change the Coroutine’s Context

The withContext function in Kotlin Coroutines lets us switch the dispatcher or coroutine context for a specific block of code. It suspends the execution of the current coroutine and switches to the specified context. Once the code block finishes, the coroutine resumes execution in its original context. This is very useful for scenarios where we want to perform certain tasks in a different dispatcher like performing IO work on the IO dispatcher.

Example:
launch {
  println("Starting api call")
  withContext(Dispatchers.IO){
    delay(1000) // simulate some api call
  }
  println("finished API call work finished")
}

In this example, the withContext function suspends the current coroutine, switches to the IO dispatcher for the work, and then resumes on the original dispatcher once the work is complete.

5. Suspending and resuming with suspend

Suspend functions allow us to write asynchronous non-blocking code that looks like traditional sequential, blocking code. By suspending the execution of a function and resuming it later, coroutines can run without blocking threads. As it is non-blocking, it is an ideal choice for efficient concurrency. To note, suspend functions can only be called from a coroutine scope or by other suspend functions.

Example:

suspend fun makeRequest() : String {
  delay(500)
  return "Hello World"
}

In this example, delay(500) suspends the execution of the makeRequest() function for 500 milliseconds without blocking the thread.

When calling makeRequest() from a coroutine scope, it will look like normal synchronous code while actually being non-blocking.

launch {
  val response = makeRequest()
  println(response)
}

Conclusion

At first, I found coroutines overwhelming, but after diving into them, I started to realise what a flexible and powerful approach to asynchronous programming they enable. Learning how to effectively use the concepts covered in this article has greatly improved my ability to write asynchronous code that is performant, very readable and easy to write. I’m confident that by mastering these concepts, I can continue to write highly efficient, non-blocking code while maintaining clarity and maintainability. I hope that learning what I covered in this article will help you on your way to better take advantage of the great tool that Kotlin coroutines are.