协程技术疑问：在runBlocking中使用launch是否有必要？

Great question! Let's break down what's happening here and why that launch isn't as useless as it seems at first glance.

先搞懂为什么两种写法输出相同 #

First off, you're right that runBlocking starts a top-level coroutine, and it runs on the thread that calls it (in your case, the main thread).

In your first snippet, when you call launch inside runBlocking, by default it inherits the parent coroutine's context—meaning it runs on the same main thread as the runBlocking coroutine. The delay(2000L) is a suspend function, so it pauses only the launch coroutine, not the entire main thread. If your full code had something like:

runBlocking {
    launch {
        delay(2000L)
        Log.i(TAG, "World!")
        Log.i(TAG, Thread.currentThread().name)
    }
    Log.i(TAG, "Hello,") // This runs immediately
}

You'd actually see "Hello," log first, then 2 seconds later "World!" and "main". But in your test, the output order ended up the same—probably because your "Hello," was placed after the launch block in a way that made it wait, or a quirk of logging timing.

When you commented out launch, you moved all that code directly into the runBlocking coroutine. The delay(2000L) pauses this top-level coroutine, then logs the same messages, followed by "Hello,". Since everything's running on main either way, the thread name stays the same.

So what's the point of that launch? #

It's all about concurrency—even if it doesn't look like it in this specific scenario.

1. It enables parallel execution of coroutines #

The launch creates a child coroutine that runs concurrently with the parent runBlocking coroutine. Let's adjust your example to make this obvious:

runBlocking {
    launch {
        delay(2000L)
        Log.i(TAG, "World!")
        Log.i(TAG, Thread.currentThread().name)
    }
    Log.i(TAG, "Hello,") // Runs right away, no waiting for the delay
    delay(3000L) // Keep the parent coroutine alive long enough to see the child's log
}

Now you'll clearly see "Hello," log first, then 2 seconds later "World!" shows up. Without launch, all code runs sequentially: you'd wait 2 seconds, log "World!", then log "Hello,"—no concurrency at all.

2. It lets you switch dispatchers easily #

The real power of launch shines when you specify a different dispatcher. For example, if you want to run the child coroutine on a background thread:

runBlocking {
    launch(Dispatchers.IO) {
        delay(2000L)
        Log.i(TAG, "World!")
        Log.i(TAG, Thread.currentThread().name) // Will be something like DefaultDispatcher-worker-1
    }
    Log.i(TAG, "Hello,") // Still runs on main
}

Now the thread names will differ, and you're leveraging true multi-threaded concurrency—all while keeping your code clean and avoiding manual thread management.

3. It's the building block for coroutine hierarchies #

launch creates a child job tied to the parent runBlocking job. This means if the parent coroutine cancels, all child coroutines cancel automatically. It's a safe way to manage concurrent tasks without worrying about orphaned threads or leaks.

Wrap-up #

In your specific test case, the launch seemed redundant because it inherited the parent's context and you didn't have obvious concurrent logic. But it's far from useless: it's the primary way to start new concurrent coroutines, manage their execution context, and build safe, scalable coroutine hierarchies.

内容的提问来源于stack exchange，提问作者cluster1