Bird
Raised Fist0
Kotlinprogramming~10 mins

Why structured concurrency prevents leaks in Kotlin - Test Your Understanding

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to launch a coroutine within a structured scope.

Kotlin
fun main() = runBlocking {
    launch [1] {
        println("Hello from coroutine")
    }
}
Drag options to blanks, or click blank then click option'
A() -> Unit
B{}
C()
D{ }
Attempts:
3 left
💡 Hint
Common Mistakes
Using parentheses instead of curly braces for the coroutine body.
Trying to pass a function type instead of a lambda block.
2fill in blank
medium

Complete the code to cancel all child coroutines when the parent coroutine is cancelled.

Kotlin
fun main() = runBlocking {
    val job = launch {
        launch {
            repeat(1000) { i ->
                println("Coroutine $i is working")
                delay(500)
            }
        }
    }
    delay(1300)
    job.[1]()
    println("Main coroutine ends")
}
Drag options to blanks, or click blank then click option'
Astop
Bterminate
Ccancel
Dend
Attempts:
3 left
💡 Hint
Common Mistakes
Using stop() or terminate() which do not exist.
Not cancelling the job, causing coroutines to leak.
3fill in blank
hard

Fix the error in the code to ensure child coroutines are properly scoped and do not leak.

Kotlin
fun main() {
    val scope = CoroutineScope(Dispatchers.Default)
    scope.launch {
        launch [1] {
            delay(1000)
            println("Child coroutine done")
        }
    }
    Thread.sleep(1500)
}
Drag options to blanks, or click blank then click option'
Ascope
Bthis
CGlobalScope
DrunBlocking
Attempts:
3 left
💡 Hint
Common Mistakes
Using GlobalScope which creates unstructured coroutines that can leak.
Using runBlocking inside launch which is incorrect.
4fill in blank
hard

Fill both blanks to create a structured coroutine scope that automatically cancels child coroutines on failure.

Kotlin
fun main() = runBlocking {
    val handler = CoroutineExceptionHandler { _, exception ->
        println("Caught $exception")
    }
    val job = [1](handler) {
        launch {
            throw RuntimeException("Error in child")
        }
    }
    job.[2]()
}
Drag options to blanks, or click blank then click option'
AsupervisorScope
Bcancel
CcoroutineScope
Dstart
Attempts:
3 left
💡 Hint
Common Mistakes
Using supervisorScope which does not cancel siblings on failure.
Using start() which is not a cancellation function.
5fill in blank
hard

Fill all three blanks to create a map of word lengths only for words longer than 3 characters using dictionary comprehension style.

Kotlin
val words = listOf("cat", "house", "dog", "elephant")
val lengths = mapOf([1] to [2] for [3] in words if it.length > 3)
Drag options to blanks, or click blank then click option'
Aword
Bword.length
Dit
Attempts:
3 left
💡 Hint
Common Mistakes
Using it without defining it in the loop.
Mixing up keys and values in the map.

Practice

(1/5)
1. What is the main reason structured concurrency helps prevent resource leaks in Kotlin?
easy
A. It requires manual task cancellation by the programmer.
B. It automatically frees memory after each line of code.
C. It disables background tasks after 5 seconds.
D. It ensures all tasks start and finish together, avoiding orphaned tasks.

Solution

  1. Step 1: Understand structured concurrency concept

    Structured concurrency groups related tasks so they start and finish as a unit.
  2. Step 2: Link grouping to resource management

    This grouping prevents tasks from running forever and leaking resources by ensuring no orphaned tasks remain.
  3. Final Answer:

    It ensures all tasks start and finish together, avoiding orphaned tasks. -> Option D
  4. Quick Check:

    Grouping tasks = prevents leaks [OK]
Hint: Think: tasks grouped start and end together [OK]
Common Mistakes:
  • Confusing automatic memory freeing with concurrency
  • Believing tasks stop after fixed time automatically
  • Assuming manual cancellation is always required
2. Which Kotlin syntax correctly starts a structured concurrency block using coroutineScope?
easy
A. launch { coroutineScope { /* task */ } }
B. coroutineScope() -> launch { /* task */ }
C. coroutineScope { launch { /* task */ } }
D. launch coroutineScope { /* task */ }

Solution

  1. Step 1: Recall coroutineScope usage

    In Kotlin, coroutineScope is a suspending function that takes a lambda block where child coroutines run.
  2. Step 2: Identify correct syntax

    The correct syntax is coroutineScope { launch { /* task */ } } which starts a structured block with a child coroutine.
  3. Final Answer:

    coroutineScope { launch { /* task */ } } -> Option C
  4. Quick Check:

    coroutineScope with lambda block = coroutineScope { launch { /* task */ } } [OK]
Hint: coroutineScope takes a lambda block with launch inside [OK]
Common Mistakes:
  • Using parentheses incorrectly with coroutineScope
  • Placing launch outside coroutineScope block
  • Omitting braces for lambda block
3. What will be the output of this Kotlin code snippet?
runBlocking {
  launch {
    delay(100)
    println("Task done")
  }
  println("Start")
}
medium
A. Start
B. Start\nTask done
C. Task done\nStart
D. No output

Solution

  1. Step 1: Analyze runBlocking and launch behavior

    runBlocking blocks the main thread until all child coroutines complete. The launch coroutine delays 100ms before printing.
  2. Step 2: Trace output order

    "Start" prints immediately, then after 100ms delay, "Task done" prints. So output is "Start" then "Task done".
  3. Final Answer:

    Start\nTask done -> Option B
  4. Quick Check:

    runBlocking waits, launch delays, prints after Start [OK]
Hint: runBlocking waits for launch; delay prints after Start [OK]
Common Mistakes:
  • Assuming launch runs before println("Start")
  • Thinking delay blocks main thread
  • Expecting no output due to delay
4. Identify the error in this Kotlin code that breaks structured concurrency:
fun main() = runBlocking {
  GlobalScope.launch {
    delay(1000)
    println("Leaked task")
  }
  println("Main done")
}
medium
A. Using GlobalScope.launch causes the task to run outside structured concurrency.
B. Missing delay before println("Main done").
C. runBlocking cannot be used with launch.
D. println("Leaked task") is outside coroutine scope.

Solution

  1. Step 1: Understand GlobalScope effect

    GlobalScope.launch starts a coroutine not tied to the current scope, so it can outlive runBlocking.
  2. Step 2: Link to structured concurrency principles

    This breaks structured concurrency because the launched task can leak and run after main finishes, causing resource leaks.
  3. Final Answer:

    Using GlobalScope.launch causes the task to run outside structured concurrency. -> Option A
  4. Quick Check:

    GlobalScope.launch breaks structured concurrency [OK]
Hint: GlobalScope.launch runs outside structured concurrency [OK]
Common Mistakes:
  • Thinking delay is required before printing main done
  • Believing runBlocking disallows launch
  • Misunderstanding println placement
5. You want to run multiple tasks concurrently but ensure none leak after completion. Which Kotlin approach best applies structured concurrency to prevent leaks?
hard
A. Use coroutineScope or supervisorScope to launch child coroutines inside a suspending block.
B. Launch all tasks with GlobalScope.launch and manually cancel them later.
C. Run tasks sequentially without coroutines to avoid leaks.
D. Use runBlocking only for all tasks without launching coroutines.

Solution

  1. Step 1: Identify structured concurrency tools

    coroutineScope and supervisorScope provide structured concurrency by grouping child coroutines and waiting for their completion.
  2. Step 2: Compare with other options

    GlobalScope.launch risks leaks, sequential runs lose concurrency benefits, and runBlocking alone doesn't manage child coroutines properly.
  3. Final Answer:

    Use coroutineScope or supervisorScope to launch child coroutines inside a suspending block. -> Option A
  4. Quick Check:

    coroutineScope groups tasks safely [OK]
Hint: Use coroutineScope or supervisorScope for safe concurrency [OK]
Common Mistakes:
  • Relying on GlobalScope.launch without cancellation
  • Avoiding concurrency to prevent leaks
  • Misusing runBlocking without child coroutines
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard