協程的引入

注意：kotlin中的協程在1.1中還是實驗性的（小編理解為，先不要用）
⼀些 API 啟動⻓時間運⾏的操作（例如⽹絡 IO、⽂件 IO、CPU 或 GPU 密集型任務等），並要求調⽤者阻塞直到它們完成。協程提供了⼀種避免阻塞執行緒並用更廉價、更可控的操作替代執行緒阻塞的⽅法：協程掛起

協程通過將複雜性放⼊庫來簡化非同步程式設計。程式的邏輯可以在協程中順序地表達，而底層庫會為我們解決其非同步性。該庫可以將使用者程式碼的相關部分包裝為回撥、訂閱相關事件、在不同執行緒（甚至不同機器！）上排程執行，而程式碼則保持如同順序執行⼀樣簡單
上面的語言小編理解為：
1. 我們程式設計要實現攜程，kotlin已經把實現的複雜性轉移給一個底層的庫
2. 我們實現就像我們寫一個Java的同步方法一樣，使用一個關鍵字標記就好
3. 底層的庫會幫我們實現協程的排程

許多在其他語言中可用的非同步機制可以使⽤ Kotlin 協程實現為庫。這包括源於 C# 和 ECMAScript 的 async/await、源於 Go 的 管道 和 select 以及源於 C# 和 Python 生成器/yield。關於提供這些結構的庫請參⻅其下⽂描述。

阻塞 vs 掛起

基本上，協程計算可以被掛起而無需阻塞執行緒。執行緒阻塞的代價通常是昂貴的，尤其在高負載時，因為只有相對少量執行緒實際可用，因此阻塞其中⼀個會導致⼀些重要的任務被延遲。

另⼀方面，協程掛起幾乎是無代價的。不需要上下文切換或者 OS 的任何其他干預。最重要的是，掛起可以在很大程度上由使用者庫控制：作為庫的作者，我們可以決定掛起時發生什麼並根據需求優化/記日誌/截獲。

另⼀個區別是，協程不能在隨機的指令中掛起，而只能在所謂的掛起點掛起，這會呼叫特別標記的函式。
get一下上面的資訊：
1. 協程不阻塞，執行緒會有阻塞狀態（Java的執行緒在等待同步鎖，IO，或者呼叫sleep()方法後等方式進入阻塞，阻塞後的執行緒有要進入就緒狀態才能喲執行的機會，這繁瑣的呼叫方式可能會讓任務延遲），而協程是計算可以被掛起（不明白這句話，什麼是可以計算被掛起）。
2. 協程不需要上下文切換或者 OS 的任何其他干預，而且使用者的控制權大大加大。

掛起函式

當我們呼叫標記有特殊修飾符 suspend 的函式時，會發生掛起（協程呼叫可能比較麻煩）
如果我們呼叫協程，要引入kotlin庫：
maven依賴:

<dependency>
            <groupId>org.jetbrains.kotlinx</groupId>
            <artifactId>kotlinx-coroutines-core</artifactId>
            <version>0.22.5</version>
</dependency>

我們不能直接呼叫suspend修飾的方法：
只能從協程和其他掛起函式中呼叫。（也就是說，suspend修飾的函式，只能被suspend修飾的函式呼叫）

import kotlinx.coroutines.experimental.async

suspend  fun  doSomething(i : Int):Int{
    println("會被掛起的函式執行了")
    return 1
}

fun main(args: Array<String>) {
  async {  //suspend修飾的很熟
      doSomething(1)
  }
}

注意：上面程式碼中的async函式是在kotlinx.coroutines.experimental中的
這樣的函式（doSomething()）稱為掛起函式，因為呼叫它們可能掛起協程（如果相關呼叫的結果已經可用，庫可以決定繼續進行而不掛起）。掛起函式能夠以與普通函式相同的方式獲取引數和返回值，但它們只能從協程和其他掛起函式中呼叫。事實上，要啟動協程，必須至少有⼀個掛起函式，它通常是匿名的（即它是⼀個掛起lambda 表示式）。讓我們來看⼀個例⼦，⼀個簡化的 async() 函式（源自kotlinx.coroutines 庫）：
下面貼上async的程式碼：

public fun <T> async(context: kotlin.coroutines.experimental.CoroutineContext,
                     start: kotlinx.coroutines.experimental.CoroutineStart,
                     parent: kotlinx.coroutines.experimental.Job?,
                     block: suspend kotlinx.coroutines.experimental.CoroutineScope.() -> T): kotlinx.coroutines.experimental.Deferred<T> {
                     }

這⾥的 async() 是⼀個普通函式（不是掛起函式），但是它的 block 引數具有⼀個帶 suspend 修飾符的函式型別：suspend kotlinx.coroutines.experimental.CoroutineScope.() -> T 。所以，當我們將⼀個 lambda 表示式傳給 async() 時，它會是掛起 lambda 表示式，於是我們可以從中呼叫掛起函式：

繼續該類比，await() 可以是⼀個掛起函式（因此也可以在⼀個 async {} 塊中呼叫），該函式掛起⼀個協程，直到⼀些計算完成並返回其結果：

async {
    ……
    val result = computation.await()
    ……
}

請注意，掛起函式 await() 和 doSomething() 不能在像 main() 這樣的普通函式中調⽤：（能作為suspend的引數傳入，lambda表示式的函式體中使用）

fun main(args: Array<String>) {
    doSomething() // 錯誤：掛起函式從⾮協程上下⽂調⽤
}

還要注意的是，掛起函式可以是虛擬的，當覆蓋它們時，必須指定 suspend 修飾符：

interface Base {
    suspend fun foo()
} 
class Derived: Base {
    override suspend fun foo() { …… }
}

@RestrictsSuspension 註解

擴充套件函式（和 lambda 表示式）也可以標記為 suspend ，就像普通的⼀樣。這允許建立 DSL 及其他使用者可擴充套件的 API。在某些情況下，庫作者需要阻止使用者新增新方式來掛起協程。
為了實現這⼀點，可以使⽤ @RestrictsSuspension 註解。當接收者類/介面 R 用它標註時，所有掛起擴充套件都需要委託給 R 的成員或其它委託給它的擴充套件。由於擴充套件不能無限相互委託（程式不會終止），這保證所有掛起都通過調⽤ R 的成員發生，庫的作者就可以完全控制了。
這在少數情況是需要的，當每次掛起在庫中以特殊方式處理時。例如，當通過 buildSequence() 函式實現下⽂所述的生成器時，我們需要確保在協程中的任何掛起呼叫終呼叫用yield() 或 yieldAll() 而不是任何其他函式。這就是為什麼 SequenceBuilder 用 @RestrictsSuspension 註解：
參⻅其 Github 上 的原始碼。

@RestrictsSuspension
public abstract class SequenceBuilder<in T> {
    ……
}

協程的內部機制

我們不是在這⾥給出⼀個關於協程如何⼯作的完整解釋，然⽽粗略地認識發⽣了什麼是相當重要的。
協程完全通過編譯技術實現（不需要來⾃ VM 或 OS 端的⽀持），掛起通過程式碼來⽣效。基本上，每個掛起函式（優化可能適⽤，但我們不在這⾥討論）都轉換為狀態機，其中的狀態對應於掛起調⽤。剛好在掛起前，下⼀狀態與相關區域性變數等⼀起儲存在編譯器⽣成的類的欄位中。在恢復該協程時，恢復區域性變數並且狀態機從剛好掛起之後的狀態進⾏。
掛起的協程可以作為保持其掛起狀態與區域性變數的物件來儲存和傳遞。這種物件的型別是 Continuation ，⽽這⾥描述的整個程式碼轉換對應於經典的延續性傳遞⻛格（Continuation-passing style）。因此，掛起函式有⼀個 Continuation 型別的額外引數作為⾼級選項。
關於協程⼯作原理的更多細節可以在這個設計⽂檔中找到。在其他語⾔（如 C# 或者 ECMAScript 2016）中的 async/await 的類似描述與此相關，雖然它們實現的語⾔功能可能不像 Kotlin 協程這樣通⽤。

協程是實驗性的（小編這裡先大致瞭解，今後再探究）

協程的設計是實驗性的，這意味著它可能在即將釋出的版本中更改。當在 Kotlin 1.1 中編譯協程時，預設情況下會報⼀個警告： “協程”功能是實驗性的。要移出該警告，你需要指定 opt-in 標誌。
由於其實驗性狀態，標準庫中協程相關的 API 放在 kotlin.coroutines.experimental 包下。當設計完成並且實驗性狀態解除時，最終的 API 會移動到 kotlin.coroutines ，並且實驗包會被保留（可能在⼀個單獨的構件中）以實現向後相容。
重要注意事項：我們建議庫作者遵循相同慣例：給暴露基於協程 API 的包新增“experimental”字尾（如 com.example.experimental ），以使你的庫保持⼆進位制相容。當最終 API 釋出時，請按照下列步驟操作：
將所有 API 複製到 com.example（沒有 experimental 字尾），保持實驗包的向後相容性。這將最⼩化你的⽤⼾的遷移問題。