Job lifecycle and cancellation in Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this coroutine job cancellation code?

Consider the following Kotlin code using coroutines. What will be printed when this code runs?

Kotlin

import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch {
        repeat(3) { i ->
            println("Working on $i ...")
            delay(100L)
        }
    }
    delay(250L)
    job.cancel()
    job.join()
    println("Done")
}

A Working on 0 ...\nWorking on 1 ...\nDone

B Working on 0 ...\nWorking on 1 ...\nWorking on 2 ...\nDone

C Working on 0 ...\nDone

D Done

💡 Hint

Think about when the job is cancelled and how many iterations complete before cancellation.

The job starts and prints 'Working on 0 ...' (~0ms), 'Working on 1 ...' (~100ms), and 'Working on 2 ...' (~200ms), each followed by a 100ms delay. After 250ms, the job is cancelled during the third delay, so no further iterations run. Then 'Done' is printed.

🧠 Conceptual

intermediate

Which state does a Job enter after calling cancel() but before completion?

In Kotlin coroutines, after you call cancel() on a Job but before it finishes, what is the Job's state?

A Active

B Cancelled

C New

D Completing

💡 Hint

Think about the transition phase between active and fully cancelled.

After cancel() is called, the Job enters the 'Completing' state while it finishes its cancellation process. It is not yet fully 'Cancelled' until completion.

🔧 Debug

advanced

Why does this coroutine not cancel as expected?

Examine the code below. The job.cancel() is called, but the coroutine keeps running. Why?

Kotlin

import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch {
        for (i in 1..5) {
            Thread.sleep(100L)
            println("Working $i")
        }
    }
    delay(250L)
    job.cancel()
    job.join()
    println("Finished")
}

A delay() inside the coroutine is missing, so cancellation is ignored.

B Thread.sleep blocks the thread and prevents cancellation checks inside the coroutine.

C The coroutine is not cancellable because it uses launch instead of async.

D job.cancel() was called too late after the coroutine finished.

💡 Hint

Consider how blocking calls affect coroutine cancellation.

Thread.sleep blocks the thread and does not check for cancellation, so the coroutine cannot be cancelled during that sleep. Using delay instead allows cancellation.

📝 Syntax

advanced

Which option correctly cancels a Job and waits for its completion?

Select the Kotlin code snippet that cancels a Job and waits until it finishes properly.

A

job.cancel()
job.join()

B

job.cancel()
job.cancelAndJoin()

C job.cancelAndJoin()

D

job.join()
job.cancel()

💡 Hint

Look for the built-in function that combines cancel and join.

cancelAndJoin() cancels the job and suspends until it completes. Calling cancel() then join() separately works but is less concise. Option C is the idiomatic way.

🚀 Application

expert

How many times will 'Task running' print before cancellation?

Given the code below, how many times will 'Task running' be printed before the job is cancelled?

Kotlin

import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch {
        repeat(10) { i ->
            if (!isActive) return@launch
            println("Task running $i")
            delay(50L)
        }
    }
    delay(230L)
    job.cancelAndJoin()
    println("Job cancelled")
}

A 5

B 6

C 4

D 7

💡 Hint

Calculate how many 50ms delays fit into 230ms before cancellation.

Each iteration delays 50ms. After 230ms, about 4 full iterations complete and the 5th starts. The 5th prints before cancellation, so total prints are 5.