Structured Concurrency in Kotlin
Structured concurrency treats async operations like code blocks: a parent task's lifetime contains its children. In Kotlin, a CoroutineScope ensures if the parent is cancelled, all its child coroutines are too.
Why it exists
Unmanaged concurrency is chaotic. Without structure, it's easy to launch background tasks that are never cancelled, leading to resource leaks, memory pressure, and work that continues long after it's needed, like a network request finishing after the user has left the screen. Structured concurrency enforces lifetime management for concurrent work.
The mental model
Think of a function call stack. When a function A calls B, A cannot return until B has returned. Structured concurrency applies this same principle to concurrent tasks. A parent scope cannot complete until all its child coroutines have completed. If the parent scope is cancelled, it propagates cancellation down to all its children.
How it works
In Kotlin, this is implemented via CoroutineScope. Every coroutine builder, like launch or async, is an extension on CoroutineScope and starts a new coroutine as a child of that scope. The scope maintains a job hierarchy. Cancelling the parent's job automatically cancels all children's jobs. Functions like withContext create a new scope that inherits from the outer scope, maintaining the parent-child structure.
When to use it
Almost always, for any coroutine that has a defined lifecycle tied to a component. On Android, this means using lifecycleScope for UI-related work or viewModelScope for ViewModel tasks. These scopes are automatically cancelled when the Activity/Fragment or ViewModel is destroyed, preventing leaks and crashes.
When not to use it
The main anti-pattern is using GlobalScope. This creates top-level, unstructured coroutines that are not children of any specific job. They are not cancelled automatically and can easily leak resources. The rare exception is for application-wide tasks that must outlive any component, but even these are better managed with a custom application-level scope.
One canonical example
An Android ViewModel fetches user data and an avatar in two separate coroutines. Both are launched in viewModelScope. If the user navigates away before the tasks complete, the ViewModel is cleared, viewModelScope is cancelled, and both the data fetch and avatar download are automatically cancelled. This prevents a crash from trying to update a non-existent UI and stops wasting network and CPU resources.
Interview question
Which problem does Kotlin's Structured Concurrency primarily aim to solve?
- a.Avoiding UI freezes caused by CPU-bound tasks on the main thread.
- b.Synchronizing shared mutable state in concurrent operations.
- c.Managing thread pools and their associated overhead.
- d.Preventing resource leaks from uncancelled background tasks.Correct
Why? this is the answer
Structured concurrency's main purpose is to enforce lifetime management for concurrent work, preventing resource leaks and unnecessary work by ensuring background tasks are cancelled when no longer needed. While other options are valid concurrency concerns, they are not the primary problem addressed by structured concurrency itself.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kotlin — each one lists the topics its interview covers.
See open roles