Simple and beginner-friendly Kotlin code examples to show the different behavior of using kotlinx.coroutines.delay() and Thread.sleep()
This is part of the Kotlin coroutines series:
- Part 1 - Kotlin Coroutines Basics - Simple Android App Demo
- Part 2 - kotlinx.coroutines.delay() vs Thread.sleep()
- Part 3 - GlobalScope vs viewModelScope vs lifecycleScope vs rememberCoroutineScope
- Part 4 - launchWhenCreated() vs launchWhenStarted() vs launchWhenResumed() vs repeatOnLifeCycle()
kotlinx.coroutines.delay() is a suspend function. It doesn't block the current thread. Thread.sleep() blocks the current thread. It means other code in this thread won't be executed until Thread.sleep() is exited.
Example 1 - kotlinx.coroutines.delay()
fun main(args: Array<String>) {
runBlocking {
run()
}
}
}
suspend fun run() {
coroutineScope {
val timeInMillis = measureTimeMillis {
val mainJob = launch {
//Job 0
launch {
print("A->")
delay(1000)
print("B->")
}
//Job 1
launch {
print("C->")
delay(2000)
print("D->")
}
//Job 2
launch {
print("E->")
delay(500)
print("F->")
}
//Main job
print("G->")
delay(1500)
print("H->")
}
mainJob.join()
}
val timeInSeconds =
String.format("%.1f", timeInMillis/1000f)
print("${timeInSeconds}s")
}
}
Main job will run first and then will be suspended by delay() suspend function, followed by Job 0 -> Job 1 -> Job 2. All jobs are suspended and kicked off at around the same time. Then, the shortest delay() will be run first. The timeinSeconds to complete all the jobs should be the longest delay() which is 2 seconds.
The output looks like this:
G->A->C->E->F->B->H->D->2.0s
This is pretty easy to understand. What if we replace delay(2000) with Thread.Sleep(2000) for Job1?
Example 2 - Thread.sleep() on Dispatchers.Main
suspend fun run() {
coroutineScope {
val timeInMillis = measureTimeMillis {
val mainJob = launch {
//Job 0
launch {
print("A->")
delay(1000)
print("B->")
}
//Job 1
launch {
print("C->")
Thread.sleep(2000)
print("D->")
}
//Job 2
launch {
print("E->")
delay(500)
print("F->")
}
//Main job
print("G->")
delay(1500)
print("H->")
}
mainJob.join()
}
val timeInSeconds =
String.format("%.1f", timeInMillis/1000f)
print("${timeInSeconds}s")
}
}
Similar to example 1 above, Main job will run first and suspended by delay() suspend function, followed by Job 0 → Job 1. Job 0 will be suspended. However, when Thread.sleep(2000) is run on Job 1, the thread will be blocked for 2 seconds. Job 2 at this time is not executed.
After 2 seconds, D will be printed out first, followed by E in Job 2. Job 2 then will be suspended. Because Main job and Job 0 are suspended less than 2 seconds, it will run immediately. Job 0 will run first because the suspend time is shorter.
After 0.5 seconds, Job 2 is resumed and completed. It will print out F.
Timestamp #1 (after 0 second)
- Main job and Job 0 are started and suspended.
- Job 1 is started and blocks the thread
Timestamp #2 (after 2 seconds)
- Job 1 is done
- Job 2 is started and suspended.
- Job 0 and Main job are resumed and done.
Timestamp #3 (after 0.5 seconds)
- Job 3 are resumed and done
So the total time consumes is around 2.5 seconds.
The output looks like this:
G->A->C->D->E->B->H->F->2.5s
Example 3 - Thread.sleep() on Dispatchers.Default/IO
Wait, what if run the run suspend function in background thread using Dispatchers.Default or Dispatchers.IO. For example:
runBlocking {
withContext(Dispatchers.Default) {
run()
}
}
The output becomes like this:
A->C->G->E->F->B->H->D->2.0s
The output is similar to Example 1 above, where Thread.sleep() doesn't seem to block the thread! Why?
When Dispatchers.Default or Dispatchers.IO is used, it is backed by a pool of threads. Each time we call launch{}, a different worker thread is created / used.
For example, here are the worker threads being used:
- Main job - DefaultDispatcher-worker-1
- Job 0 - DefaultDispatcher-worker-2
- Job 1 - DefaultDispatcher-worker-3
- Job 2 - DefaultDispatcher-worker-4
To see which thread is currently running, you can use
println("Run ${Thread.currentThread().name}")
So Thread.sleep() indeed blocks that thread, but only blocks the DefaultDispatcher-worker-3. The other jobs can still be continued to run since they're on different threads.
Timestamp #1 (after 0 second)
- Main job, Job 0, Job 1 and Job 2 are started. Sequence can be random. See Note(1) below.
- Main job, Job 0 and *Job2 * are suspended.
- *Job 1 * blocks its own thread.
Timestamp #2 (after 0.5 second)
- Job 2 is resumed and done.
Timestamp #3 (after 1 second)
- Job 0 are resumed and done
Timestamp #4 (after 1.5 seconds)
- Main job are resumed and done
Timestamp #5 (after 2 seconds)
- Job 1 are resumed and done
Because each job runs on a different thread, the job can be started at different time. So the output of A, C, E, G could be random. Thus, you see the initiat job starting sequence is different than the one in Exampe 1 above.
When to use Thread.Sleep()?
Thread.Sleep() is almost useless because most of the time we don't want to block the thread. kotlinx.coroutines.delay() is recommended.
I personally use Thread.Sleep() to simulate long-running task that block the thread. It is useful to test whether I have put the long-running task into the background thread. If I run it from the main UI thread, the UI won't be responsive.
If I call this simulateBlockingThreadTask() in the main UI thread, it will block the main UI thread. The application will crash with non-responsive UI.
private suspend fun simulateBlockingThreadTask() {
Thread.sleep(2000)
}
However, if we switch the thread to background thread using kotlinx.coroutines.withContext(), calling this simulateBlockingThreadTask() from the main UI thread won't crash the application.
private suspend fun simulateBlockingThreadTask() {
withContext(Dispatchers.Default) {
Thread.sleep(2000)
}
}
Remember to use yield()
In my previous example in Coroutines Basics blog post, I used yield() to break out the Thread.sleep() to basically allow the coroutine to be cancellable. It is generally a good practice not to block the UI thread for too long.
In the code example, I simulate both blocking and non-blocking thread tasks. The total running time is 400 milliseconds.
private suspend fun simulateLongRunningTask() {
simulateBlockingThreadTask()
simulateNonBlockingThreadTask()
}
private suspend fun simulateBlockingThreadTask() {
repeat(10) {
Thread.sleep(20)
yield()
}
}
private suspend fun simulateNonBlockingThreadTask() {
delay(200)
}
Conclusion
Thread.sleep() blocks the thread and kotlinx.coroutines.delay() doesn't.
I use Thread.sleep() to test whether I have properly put the long-running task into background thread. Other than this, I can't think of any reasons we want to use Thread.sleep().
Originally published at https://vtsen.hashnode.dev.
Top comments (0)