Job詳解：
在上一次https://www.cnblogs.com/webor2006/p/11725866.html中拋出了一個問題：
所以咱們將delay去掉，需要改造一下，先把主線程的delay給注釋掉：
那怎么做呢？這里先來看一下GlobalScope.launch()方法的返回值：
咱們先來回顧一下之前Job的理論描述：
簡單看一下官方的對它的說明：
其它的就暫且不讀了，那能拿到Job是不是可以通過它來達到我們精准等待協程執行完的目的呢？所以首先咱們來獲取它的返回值：
那重點就是怎么通過這個Job來達到我們的目的了， 其實它里面有一個跟咱們線程中一樣的join()方法，不過實現肯定不同啦，瞅瞅：
所以咱們試試：
下面來運行一下看效果：
確實是如此，這次“Kotlin Coroutines”和"World"幾乎是同時間輸出了。
協程作用域：
先來回顧一下咱們之前的代碼:
也就是我們用GlobalScope.lauch()構造的協程中的代碼是依附於主線程，如果主線程退出了，其協程也退出了，但是！！看下面這個代碼就會顛覆這個效果了，如下：
運行：
發現此時“hello”在輸出之后，還在等待后台協程在“Kotlin Coroutines”輸出完之后再退出，這是為啥呢？這里就涉及到了“協程作用域”的概念好，下面先來看下理論：
“每一個協程構建器（包括runBlocking）都會向其代碼塊作用域中添加一個CoroutineScope實例，我們可以在該作用域中啟動協程，而無需顯示將其join到一起，這是因為外部協程（在上面的示例中就是runBlocking）會等待該作用域中的所有啟動的協程全部完成后才會完成。”
也就是說：
而回到之前的這段代碼：
而如果不用GlobalScope，而直接調用launch，它其實創建的Scope就是runBlocking所創建的CoroutineScope實例了，此時外部的協程就會等待里面的協程了，還是比較難理解的，所以我們就可以利用這個特性來比較巧妙的來達到文章開頭想要實現的那個效果。