kotlin中的协程

最新推荐文章于 2024-05-29 22:26:52 发布

MMsmileNN

最新推荐文章于 2024-05-29 22:26:52 发布

阅读量466

点赞数

分类专栏： kotlin 文章标签： android kotlin java

本文链接：https://blog.csdn.net/MMsmileNN/article/details/118223455

版权

kotlin 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

协程Coroutine

runBlocking协程构造器（阻塞的）

runBlocking<Unit> { …… } 作为用来启动顶层主协程的适配器

GlobalScop全局协程（非阻塞）

1. 可以将 GlobalScope.launch { …… } 替换为 thread { …… }
2. 将 delay(……) 替换为 Thread.sleep(……)
3.  delay 是一个特殊的***挂起函数***
4.  GlobalScope.launch启动一个协程，这意味着新协程的生命周期只受整个应用程序的生命周期限制
5.  val job = GlobalScope.launch { …… }会生成一个返回值，可以处理协程，job.jion()等待协程结束
6.  使用 GlobalScope.launch 时，我们会创建一个顶层协程,运行时仍会消耗一些内存资源，（不建议使用）
7.  全局协程像守护线程

启动方式

1.launch：顺序执行，返回job
2.async: 并发执行，返回一个 Deferred，可以使用.await()获取返回值

val job = GlobalScope.launch { // 启动一个新协程并保持对这个作业的引用 delay(1000L) println("World!") } println("Hello,") job.join() // 等待直到子协程执行结束

在 GlobalScope 中启动的活动协程并不会使进程保活。它们就像守护线程。
    GlobalScope.launch {
    repeat(1000) { i ->
        println("I'm sleeping $i ...")
        delay(500L)
    }
}
delay(1300L) // 在延迟后退出
运行结果：
    I'm sleeping 0 ...
    I'm sleeping 1 ...
    I'm sleeping 2 ...

结构化并发

我们可以在执行操作所在的指定作用域内启动协程

我们可以在这个作用域中启动协程而无需显式 join ，因为外部协程（示例中的 runBlocking）直到在其作用域中启动的所有协程都执行完毕后才会结束

fun main() = runBlocking { // this: CoroutineScope
    launch { // 在 runBlocking 作用域中启动一个新协程
        delay(1000L)
        println("World!")
    }
    println("Hello,")
}

作用域构建器

runBlocking 与 coroutineScope 可能看起来很类似，因为它们都会等待其协程体以及所有子协程结束。主要区别在于，runBlocking 方法会阻塞当前线程来等待，而 coroutineScope 只是挂起，会释放底层线程用于其他用途。由于存在这点差异，runBlocking 是常规函数，而 coroutineScope 是挂起函数

fun main() = runBlocking { // this: CoroutineScope
launch { 
    delay(200L)
    println("Task from runBlocking")
}

coroutineScope { // 创建一个协程作用域
    launch {
        delay(500L) 
        println("Task from nested launch")
    }

    delay(100L)
    println("Task from coroutine scope") // 这一行会在内嵌 launch 之前输出
}

println("Coroutine scope is over") // 这一行在内嵌 launch 执行完毕后才输出
}

提取函数重构(挂起函数)

suspend 修饰符的函数
在协程内部可以像普通函数一样使用挂起函数
delay（）就是挂起函数

协程个数创建repeat

fun main() = runBlocking {
    repeat(100000) { // 启动10万个协程
        launch {
            delay(5000L)
            print(".")
        }
    }
}

协程的取消

job.cancel()取消协程， launch 函数返回了一个可以被用来取消运行中的协程的Job
job.join等待协助作业执行结束
job.cancelAndJoin()取消一个作业并且等待它结束

协程的取消是协作的，一段协程代码必须协作才能被取消，如果协程正在执行计算任务，并且没有检查取消(isActive)的话，那么它是不能被取消的

val startTime = System.currentTimeMillis()
val job = launch(Dispatchers.Default) {
    var nextPrintTime = startTime
    var i = 0
    while (i < 5) { // 一个执行计算的循环，只是为了占用 CPU
        // 每秒打印消息两次
        if (System.currentTimeMillis() >= nextPrintTime) {
            println("job: I'm sleeping ${i++} ...")
            nextPrintTime += 500L
        }
    }
}
delay(1300L) // 等待一段时间
println("main: I'm tired of waiting!")
job.cancelAndJoin() // 取消一个作业并且等待它结束
println("main: Now I can quit.")

输出：
    job: I'm sleeping 0 ...
    job: I'm sleeping 1 ...
    job: I'm sleeping 2 ...
    main: I'm tired of waiting!
    job: I'm sleeping 3 ...
    job: I'm sleeping 4 ...
    main: Now I can quit.

使计算代码可取消,显式的检查取消状态,将前一个示例中的 while (i < 5) 替换为 while (isActive) 并重新运行它

在 finally 中释放资源

try {……} finally {……} 表达式以及 Kotlin 的 use 函数一般在协程被取消的时候执行它们的终结动作。可以处理数据流关闭等动作

val job = launch {
    try {
        repeat(1000) { i ->
            println("job: I'm sleeping $i ...")
            delay(500L)
        }
    } finally {
        println("job: I'm running finally")
    }
}
delay(1300L) // 延迟一段时间
println("main: I'm tired of waiting!")
job.cancelAndJoin() // 取消该作业并且等待它结束
println("main: Now I can quit.")

输出：
job: I'm sleeping 0 ...
job: I'm sleeping 1 ...
job: I'm sleeping 2 ...
main: I'm tired of waiting!
job: I'm running finally
main: Now I can quit.

运行不能取消的代码块

在真实的案例中，当你需要挂起一个被取消的协程，你可以将相应的代码包装在 withContext(NonCancellable) {……} 中，并使用 withContext 函数以及 NonCancellable 上下文。

val job = launch {
    try {
        repeat(1000) { i ->
            println("job: I'm sleeping $i ...")
            delay(500L)
        }
    } finally {
        withContext(NonCancellable) {
            println("job: I'm running finally")
            delay(1000L)
            println("job: And I've just delayed for 1 sec because I'm non-cancellable")
        }
    }
}
delay(1300L) // 延迟一段时间
println("main: I'm tired of waiting!")
job.cancelAndJoin() // 取消该作业并等待它结束
println("main: Now I can quit.")
输出：
job: I'm sleeping 0 ...
job: I'm sleeping 1 ...
job: I'm sleeping 2 ...
main: I'm tired of waiting!
job: I'm running finally
job: And I've just delayed for 1 sec because I'm non-cancellable
main: Now I can quit.

超时

在实践中绝大多数取消一个协程的理由是它有可能超时， withTimeout 函数检查超时

withTimeout(1300L) {
    repeat(1000) { i ->
        println("I'm sleeping $i ...")
        delay(500L)
    }
}

输出：
I'm sleeping 0 ...
I'm sleeping 1 ...
I'm sleeping 2 ...
Exception in thread "main" kotlinx.coroutines.TimeoutCancellationException: Timed out waiting for 1300 ms

而 withTimeoutOrNull 通过返回 null 来进行超时操作，从而替代抛出一个异常

组合挂起函数

默认顺序执行

fun main() = runBlocking<Unit> {
    val time = measureTimeMillis {
        val one = doSomethingUsefulOne()
        val two = doSomethingUsefulTwo()
        println("The answer is ${one + two}")
    }
    println("Completed in $time ms")    
}

suspend fun doSomethingUsefulOne(): Int {
    delay(1000L) // 假设我们在这里做了些有用的事
    return 13
}

suspend fun doSomethingUsefulTwo(): Int {
    delay(1000L) // 假设我们在这里也做了一些有用的事
    return 29
}
输出：
The answer is 42
Completed in 2017 ms

使用 async 并发

async 就类似于 launch。它启动了一个单独的协程，这是一个轻量级的线程并与其它所有的协程一起并发的工作。你可以使用 .await() 在一个延期的值上得到它的最终结果

val time = measureTimeMillis {
    val one = async { doSomethingUsefulOne() }
    val two = async { doSomethingUsefulTwo() }
    println("The answer is ${one.await() + two.await()}")
}
println("Completed in $time ms")
输出：
The answer is 42
Completed in 1017 ms

这里快了两倍，因为两个协程并发执行。请注意，使用协程进行并发总是显式的

惰性启动的 async

可选的，async 可以通过将 start 参数设置为 CoroutineStart.LAZY 而变为惰性的。在这个模式下，只有结果通过 await 获取的时候协程才会启动，或者在 Job 的 start 函数调用的时候

val time = measureTimeMillis {
    val one = async(start = CoroutineStart.LAZY) { doSomethingUsefulOne() }
    val two = async(start = CoroutineStart.LAZY) { doSomethingUsefulTwo() }
    // 执行一些计算
    one.start() // 启动第一个
    two.start() // 启动第二个
    println("The answer is ${one.await() + two.await()}")
}
println("Completed in $time ms")
输出：
The answer is 42
Completed in 1017 ms

注意，如果我们只是在 println 中调用 await，而没有在单独的协程中调用 start，这将会导致顺序行为，直到 await 启动该协程执行并等待至它结束，这并不是惰性的预期用例。在计算一个值涉及挂起函数时，这个 async(start = CoroutineStart.LAZY) 的用例用于替代标准库中的 lazy 函数。

使用 async 的结构化并发

由于 async 被定义为了 CoroutineScope 上的扩展，我们需要将它写在作用域内，并且这是 coroutineScope 函数所提供的

suspend fun concurrentSum(): Int = coroutineScope {
    val one = async { doSomethingUsefulOne() }
    val two = async { doSomethingUsefulTwo() }
    one.await() + two.await()
}
val time = measureTimeMillis {
    println("The answer is ${concurrentSum()}")
}
println("Completed in $time ms")
输出：
The answer is 42
Completed in 1021 ms

注：如果在 concurrentSum 函数内部发生了错误，并且它抛出了一个异常，所有在作用域中启动的协程都会被取消。

协程上下文(CoroutineContext)与调度器

调度器与线程

协程上下文包含一个协程调度器（CoroutineDispatcher）它确定了相关的协程在哪个线程或哪些线程上执行。协程调度器可以将协程限制在一个特定的线程执行，或将它分派到一个线程池，亦或是让它不受限地运行

launch { // 运行在父协程的上下文中，即 runBlocking 主协程
    println("main runBlocking      : I'm working in thread ${Thread.currentThread().name}")
}
launch(Dispatchers.Unconfined) { // 不受限的——将工作在主线程中
    println("Unconfined            : I'm working in thread ${Thread.currentThread().name}")
}
launch(Dispatchers.Default) { // 将会获取默认调度器
    println("Default               : I'm working in thread ${Thread.currentThread().name}")
}
launch(newSingleThreadContext("MyOwnThread")) { // 将使它获得一个新的线程
    println("newSingleThreadContext: I'm working in thread ${Thread.currentThread().name}")
}
输出：
Unconfined            : I'm working in thread main
Default               : I'm working in thread DefaultDispatcher-worker-1
newSingleThreadContext: I'm working in thread MyOwnThread
main runBlocking      : I'm working in thread main

当调用 launch { …… } 时不传参数，它从启动了它的 CoroutineScope 中承袭了上下文
Dispatchers.Unconfined 协程调度器在调用它的线程启动了一个协程，但它仅仅只是运行到第一个挂起点（非受限调度器）
当协程在 GlobalScope 中启动时，使用的是由 Dispatchers.Default 代表的默认调度器。默认调度器使用共享的后台线程池。所以 launch(Dispatchers.Default) { …… } 与 GlobalScope.launch { …… } 使用相同的调度器。
newSingleThreadContext 为协程的运行启动了一个线程。 一个专用的线程是一种非常昂贵的资源。在真实的应用程序中两者都必须被释放，当不再需要的时候，使用 close 函数，或存储在一个顶层变量中使它在整个应用程序中被重用

非受限调度器 vs 受限调度器

Dispatchers.Unconfined 非受限的调度器非常适用于执行不消耗 CPU 时间的任务，以及不更新局限于特定线程的任何共享数据（如UI）的协程

继承了外部的 CoroutineScope。 runBlocking 协程的默认调度器，特别是，当它被限制在了调用者线程时，继承自它将会有效地限制协程在该线程运行并且具有可预测的 FIFO 调度

launch(Dispatchers.Unconfined) { // 非受限的——将和主线程一起工作
    println("Unconfined      : I'm working in thread ${Thread.currentThread().name}")
//     delay(500)
    println("Unconfined      : After delay in thread ${Thread.currentThread().name}")
}
launch { // 父协程的上下文，主 runBlocking 协程
    println("main runBlocking: I'm working in thread ${Thread.currentThread().name}")
//     delay(1000)
    println("main runBlocking: After delay in thread ${Thread.currentThread().name}")
}
输出：
Unconfined      : I'm working in thread main @coroutine#2
Unconfined      : After delay in thread main @coroutine#2
main runBlocking: I'm working in thread main @coroutine#3
main runBlocking: After delay in thread main @coroutine#3

非受限的调度器是一种高级机制，可以在某些极端情况下提供帮助而不需要调度协程以便稍后执行或产生不希望的副作用，因为某些操作必须立即在协程中执行。非受限调度器不应该在通常的代码中使用

子协程

当一个协程被其它协程在 CoroutineScope 中启动的时候，它将通过 CoroutineScope.coroutineContext 来承袭上下文，并且这个新协程的 Job 将会成为父协程作业的子作业。当一个父协程被取消的时候，所有它的子协程也会被递归的取消。

// 启动一个协程来处理某种传入请求（request）
val request = launch {
    // 孵化了两个子作业, 其中一个通过 GlobalScope 启动
    GlobalScope.launch {
        println("job1: I run in GlobalScope and execute independently!")
        delay(1000)
        println("job1: I am not affected by cancellation of the request")
    }
    // 另一个则承袭了父协程的上下文
    launch {
        delay(100)
        println("job2: I am a child of the request coroutine")
        delay(1000)
        println("job2: I will not execute this line if my parent request is cancelled")
    }
}
delay(500)
request.cancel() // 取消请求（request）的执行
delay(1000) // 延迟一秒钟来看看发生了什么
println("main: Who has survived request cancellation?")
输出：
job1: I run in GlobalScope and execute independently!
job2: I am a child of the request coroutine
job1: I am not affected by cancellation of the request
main: Who has survived request cancellation?

一个父协程总是等待所有的子协程执行结束

协程作用域

我们通过创建一个 CoroutineScope 实例来管理协程的生命周期，并使它与 activity 的生命周期相关联。CoroutineScope 可以通过 CoroutineScope() 创建或者通过MainScope() 工厂函数。前者创建了一个通用作用域，而后者为使用 Dispatchers.Main 作为默认调度器的 UI 应用程序创建作用域：

class Activity {
    private val mainScope = CoroutineScope(Dispatchers.Default) // use Default for test purposes

    fun destroy() {
        mainScope.cancel()
    }

    fun doSomething() {
        // 在示例中启动了 10 个协程，且每个都工作了不同的时长
        repeat(10) { i ->
            mainScope.launch {
                delay((i + 1) * 200L) // 延迟 200 毫秒、400 毫秒、600 毫秒等等不同的时间
                println("Coroutine $i is done")
            }
        }
    }
} // Activity 类结束

fun main() = runBlocking<Unit> {
    val activity = Activity()
    activity.doSomething() // 运行测试函数
    println("Launched coroutines")
    delay(500L) // 延迟半秒钟
    println("Destroying activity!")
    activity.destroy() // 取消所有的协程
    delay(1000) // 为了在视觉上确认它们没有工作    
}

结果显示取消了doSomething中所有的协程

线程局部数据

能够将一些线程局部数据传递到协程与协程之间是很方便的 ThreadLocal， asContextElement 扩展函数在这里会充当救兵。它创建了额外的上下文元素，且保留给定 ThreadLocal 的值，并在每次协程切换其上下文时恢复它。

val threadLocal = ThreadLocal<String?>() // 声明线程局部变量
runBlocking {
    threadLocal.set("main")
    println("外协程 current thread: ${Thread.currentThread()}, thread local value: '${threadLocal.get()}'")
    val job = launch(Dispatchers.Default + threadLocal.asContextElement(value = "launch")) {
        println("内部协程，current thread: ${Thread.currentThread()}, thread local value: '${threadLocal.get()}'")
        yield()
        println("After yield, current thread: ${Thread.currentThread()}, thread local value: '${threadLocal.get()}'")
    }
    job.join()
    println("外协程， current thread: ${Thread.currentThread()}, thread local value: '${threadLocal.get()}'")

}
输出：
外协程 current thread: Thread[main,5,main], thread local value: 'main'
内部协程，current thread: Thread[DefaultDispatcher-worker-1,5,main], thread local value: 'launch'
After yield, current thread: Thread[DefaultDispatcher-worker-1,5,main], thread local value: 'launch'
外协程， current thread: Thread[main,5,main], thread local value: 'main'

ThreadLocal设置参数，threadLocal.get()获取局部数据参数，threadLocal.asContextElement(value = "launch")给子协程设置数据参数

异步流（Flow）

挂起函数可以异步的返回单个值，也可以返回多个计算好的值

表示多个值

使用foreach打印

使用序列构造器（Sequence）去表示各个值，同步计算，会阻塞进行

fun simple(): Sequence<Int> = sequence { // 序列构建器
    for (i in 1..3) {
        Thread.sleep(100) // 假装我们正在计算
        yield(i) // 产生下一个值
    }
}
//每100ms打印一个
fun main() {
    simple().forEach { value -> println(value) } 
}

可以使用挂起函数，使用suspend 修饰符标记函数，执行异步计算

//挂起函数，不阻塞执行，等待一秒后打印数字，异步计算
suspend fun simple2():List<Int>{
    delay(100)
    return listOf(1,2,3)
}
fun main() = runBlocking<Unit> {
    simple().forEach { value -> println(value) } 
}

流（Flow）

不阻塞主线程的，异步处理，响应式流

名为 flow 的 Flow 类型构建器函数
flow { ... } 构建块中的代码可以挂起
函数 simple 不再标有suspend 修饰符
流使用 emit 函数发射值
流使用 collect 函数收集值

流是冷流

flow 构建器中的代码直到流被收集的时候才运行

fun simple(): Flow<Int> = flow { 
    println("Flow started")
    for (i in 1..3) {
        delay(100)
        emit(i)
    }
}

fun main() = runBlocking<Unit> {
    println("Calling simple function...")
    val flow = simple()
    println("Calling collect...")
    flow.collect { value -> println(value) } 
    println("Calling collect again...")
    flow.collect { value -> println(value) } 
}
输出：
Calling simple function...
Calling collect...
Flow started
1
2
3
Calling collect again...
Flow started
1
2
3

simple() 调用会尽快返回且不会进行任何等待。该流在每次收集的时候启动，这就是为什么当我们再次调用 collect 时我们会看到“Flow started”

流取消

流采用与协程同样的协作取消，可以取消挂起函数挂起的时候取消

//演示超时取消
fun simple(): Flow<Int> = flow { 
    for (i in 1..3) {
        delay(100)          
        println("Emitting $i")
        emit(i)
    }
}

fun main() = runBlocking<Unit> {
    withTimeoutOrNull(250) { // 在 250 毫秒后超时
        simple().collect { value -> println(value) } 
    }
    println("Done")
}
输出：
Emitting 1
1
Emitting 2
2
Done

流构建器

flow { ... } 构建器是最基础的一个，
flowOf 构建器定义了一个发射固定值集的流。使用 .asFlow() 扩展函数，可以将各种集合与序列转换为流。
```
// 将一个整数区间转化为流
(1..3).asFlow().collect { value -> println(value) }
```

过渡流操作符（map，filter）

过渡操作符应用于上游流，并返回下游流，这类操作符本身不是挂起函数。它运行的速度很快，返回新的转换流的定义。像过滤器可以中间操作处理数据

suspend fun performRequest(request: Int): String {
    delay(1000) // 模仿长时间运行的异步工作
    return "response $request"
}

fun main() = runBlocking<Unit> {
    (1..3).asFlow() // 一个请求流
        .map { request -> performRequest(request) }
        .collect { response -> println(response) }
}
输出：
response 1
response 2
response 3
//每秒输出一行，转换流数据输出

转换操作符（transform）

使用 transform 操作符，我们可以 发射任意值任意次

使用场景：使用 transform 我们可以在执行长时间运行的异步请求之前发射一个字符串并跟踪这个响应

(1..3).asFlow() // 一个请求流
    .transform { request ->
        emit("Making request $request") 
        emit(performRequest(request)) 
    }
    .collect { response -> println(response) }
输出：
Making request 1
response 1
Making request 2
response 2
Making request 3
response 3

限长操作符（take）

限长过渡操作符（例如 take）在流触及相应限制的时候会将它的执行取消。协程中的取消操作总是通过抛出异常来执行，这样所有的资源管理函数（如 try {...} finally {...} 块）会在取消的情况下正常运行：

fun numbers(): Flow<Int> = flow {
    try {                          
        emit(1)
        emit(2) 
        println("This line will not execute")
        emit(3)    
    } finally {
        println("Finally in numbers")
    }
}

fun main() = runBlocking<Unit> {
    numbers() 
        .take(2) // 只获取前两个
        .collect { value -> println(value) }
}
输出：
1
2
Finally in numbers 
//数据获取到第二个后就停止

末端流操作符（collect,reduce,fold）

末端操作符是在流上用于启动流收集的挂起函数

可以处理的场景，转化为各种集合，例如 toList 与 toSet。
获取第一个（first）值与确保流发射单个（single）值的操作符。

使用 reduce 与 fold 将流规约到单个值。

val sum = (1..5).asFlow()
    .map { it * it } // 数字 1 至 5 的平方                        
    .reduce { a, b -> a + b } // 求和（末端操作符）
println(sum)
输出：55

流是连续的

流的每次单独收集都是按顺序执行的，除非进行特殊操作的操作符使用多个流。默认情况下不启动新协程。从上游到下游每个过渡操作符都会处理每个发射出的值然后再交给末端操作符

(1..5).asFlow()
    .filter {
        println("Filter $it")
        it % 2 == 0              
    }              
    .map { 
        println("Map $it")
        "string $it"
    }.collect { 
        println("Collect $it")
    }  
输出：
Filter 1
Filter 2
Map 2
Collect string 2
Filter 3
Filter 4
Map 4
Collect string 4
Filter 5

流上下文

fun simple(): Flow<Int> = flow {
    log("Started simple flow")
    for (i in 1..3) {
        emit(i)
    }
}  

fun main() = runBlocking<Unit> {
    simple().collect { value -> log("Collected $value") } 
} 
输出
[main @coroutine#1] Started simple flow
[main @coroutine#1] Collected 1
[main @coroutine#1] Collected 2
[main @coroutine#1] Collected 3

由于 simple().collect 是在主线程调用的，那么 simple 的流主体也是在主线程调用的。这是快速运行或异步代码的理想默认形式，它不关心执行的上下文并且不会阻塞调用者

测试使用withContext 发出错误

长时间运行的消耗 CPU 的代码也许需要在 Dispatchers.Default 上下文中执行，并且更新 UI 的代码也许需要在** Dispatchers.Main** 中执行。通常，withContext 用于在 Kotlin 协程中改变代码的上下文，但是flow {...} 构建器中的代码必须遵循上下文保存属性，并且不允许从其他上下文中发射（emit）

fun simple(): Flow<Int> = flow {
    // 在流构建器中更改消耗 CPU 代码的上下文的错误方式
    kotlinx.coroutines.withContext(Dispatchers.Default) {
        for (i in 1..3) {
            Thread.sleep(100) // 假装我们以消耗 CPU 的方式进行计算
            emit(i) // 发射下一个值
        }
    }
}

fun main() = runBlocking<Unit> {
    simple().collect { value -> println(value) } 
}

输出：报错，原因：collect收集的上下文不一致

flowOn 操作符

该函数用于更改流发射的上下文

fun simple(): Flow<Int> = flow {
    for (i in 1..3) {
        Thread.sleep(100) // 假装我们以消耗 CPU 的方式进行计算
        log("Emitting $i")
        emit(i) // 发射下一个值
    }
}.flowOn(Dispatchers.Default) // 在流构建器中改变消耗 CPU 代码上下文的正确方式

fun main() = runBlocking<Unit> {
    simple().collect { value ->
        log("Collected $value") 
    } 
}  
输出：
[DefaultDispatcher-worker-1 @coroutine#2] Emitting 1
[main @coroutine#1] Collected 1
[DefaultDispatcher-worker-1 @coroutine#2] Emitting 2
[main @coroutine#1] Collected 2
[DefaultDispatcher-worker-1 @coroutine#2] Emitting 3
[main @coroutine#1] Collected 3

现在收集发生在一个协程中（“coroutine#1”）而发射发生在运行于另一个线程中与收集协程并发运行的另一个协程（“coroutine#2”）中。当上游流必须改变其上下文中的 CoroutineDispatcher 的时候，flowOn 操作符创建了另一个协程。

缓冲（ buffer 操作符）

将流的不同部分运行在不同的协程中将会很有帮助，特别是当涉及到长时间运行的异步操作时，

fun simple(): Flow<Int> = flow {
    for (i in 1..3) {
        delay(100) // 假装我们异步等待了 100 毫秒
        emit(i) // 发射下一个值
    }
}

fun main() = runBlocking<Unit> { 
    val time = measureTimeMillis {
        simple().collect { value -> 
            delay(300) // 假装我们花费 300 毫秒来处理它
            println(value) 
        } 
    }   
    println("Collected in $time ms")
}

//它会产生这样的结果，整个收集过程大约需要 1200 毫秒（3 个数字，每个花费 400 毫秒）

val time = measureTimeMillis {
    simple()
        .buffer() // 缓冲发射项，无需等待
        .collect { value -> 
            delay(300) // 假装我们花费 300 毫秒来处理它
            println(value) 
        } 
}   
println("Collected in $time ms")

它产生了相同的数字，只是更快了，由于我们高效地创建了处理流水线，仅仅需要等待第一个数字产生的 100 毫秒以及处理每个数字各需花费的 300 毫秒。这种方式大约花费了 1000 毫秒来运行注：flowOn 操作符使用了相同的缓冲机制，但是我们在这里显式地请求缓冲而不改变执行上下文。

合并（conflate）

适用与：当流代表部分操作结果或操作状态更新时，可能没有必要处理每个值，而是只处理最新的那个

val time = measureTimeMillis {
    simple()
        .conflate() // 合并发射项，不对每个值进行处理
        .collect { value -> 
            delay(300) // 假装我们花费 300 毫秒来处理它
            println(value) 
        } 
}   
println("Collected in $time ms")
输出：
1
3
Collected in 758 ms

我们看到，虽然第一个数字仍在处理中，但第二个和第三个数字已经产生，因此第二个是 conflated ，只有最新的（第三个）被交付给收集器

处理最新值（collectLatest）

有一组与 xxx 操作符执行相同基本逻辑的 xxxLatest 操作符，但是在新值产生的时候取消执行其块中的代码。让我们在先前的示例中尝试更换 conflate 为 collectLatest

val time = measureTimeMillis {
    simple()
        .collectLatest { value -> // 取消并重新发射最后一个值
            println("Collecting $value") 
            delay(300) // 假装我们花费 300 毫秒来处理它
            println("Done $value") 
        } 
}   
println("Collected in $time ms")
输出：
Collecting 1
Collecting 2
Collecting 3
Done 3
Collected in 741 ms

由于 collectLatest 的函数体需要花费 300 毫秒，但是新值每 100 秒发射一次，我们看到该代码块对每个值运行，但是只收集最后一个值

组合流（zip）

zip操作符可以组合两个流中的数据处理

fun main() = runBlocking<Unit> { 

    val nums = (1..3).asFlow() // 数字 1..3
    val strs = flowOf("one", "two", "three") // 字符串
    nums.zip(strs) { a, b -> "$a -> $b" } // 组合单个字符串
        .collect { println(it) } // 收集并打印
}
输出：
1 -> one
2 -> two
3 -> three

当流表示一个变量或操作的最新值时，可能需要执行计算，这依赖于相应流的最新值，并且每当上游流产生值的时候都需要重新计算。这种相应的操作符家族称为 combine

fun main() = runBlocking<Unit> { 

    val nums = (1..3).asFlow().onEach { delay(300) } // 发射数字 1..3，间隔 300 毫秒
    val strs = flowOf("one", "two", "three").onEach { delay(400) } // 每 400 毫秒发射一次字符串
    val startTime = System.currentTimeMillis() // 记录开始的时间
    nums.zip(strs) { a, b -> "$a -> $b" } // 使用“zip”组合单个字符串
        .collect { value -> // 收集并打印
            println("$value at ${System.currentTimeMillis() - startTime} ms from start") 
        } 
}
输出：
1 -> one at 437 ms from start
2 -> two at 837 ms from start
3 -> three at 1239 ms from start

数字改变，但组合最后执行的值未变，等待每个流发射数据

val nums = (1..3).asFlow().onEach { delay(300) } // 发射数字 1..3，间隔 300 毫秒
val strs = flowOf("one", "two", "three").onEach { delay(400) } // 每 400 毫秒发射一次字符串
val startTime = System.currentTimeMillis() // 记录开始的时间
nums.combine(strs) { a, b -> "$a -> $b" } // 使用“combine”组合单个字符串
    .collect { value -> // 收集并打印
        println("$value at ${System.currentTimeMillis() - startTime} ms from start") 
    } 
输出：
1 -> one at 452 ms from start
2 -> one at 651 ms from start
2 -> two at 854 ms from start
3 -> two at 952 ms from start
3 -> three at 1256 ms from start

每次执行时，都处理数据，执行计算

展平流

flatMapConcat（ flattenConcat）

连接模式由 flatMapConcat 与 flattenConcat 操作符实现。它们是相应序列操作符最相近的类似物。它们在等待内部流完成之前开始收集下一个值。等待所有内部流执行的顺序执行

fun requestFlow(i: Int): Flow<String> = flow {
    emit("$i: First") 
    delay(500) // 等待 500 毫秒
    emit("$i: Second")    
}

fun main() = runBlocking<Unit> { 
    val startTime = System.currentTimeMillis() // 记录开始时间
    (1..3).asFlow().onEach { delay(100) } // 每 100 毫秒发射一个数字 
        .flatMapConcat { requestFlow(it) }                                                                           
        .collect { value -> // 收集并打印
            println("$value at ${System.currentTimeMillis() - startTime} ms from start") 
        } 
}
输出：
1: First at 121 ms from start
1: Second at 622 ms from start
2: First at 727 ms from start
2: Second at 1227 ms from start
3: First at 1328 ms from start
3: Second at 1829 ms from start

flatMapMerge

展平模式是并发收集所有传入的流，并将它们的值合并到一个单独的流，以便尽快的发射值。它由flatMapMerge 与 flattenMerge 操作符实现。他们都接收可选的用于限制并发收集的流的个数的 concurrency 参数（默认情况下，它等于 DEFAULT_CONCURRENCY）

fun main() = runBlocking<Unit> { 
    val startTime = System.currentTimeMillis() // 记录开始时间
    (1..3).asFlow().onEach { delay(100) } // 每 100 毫秒发射一个数字 
        .flatMapMerge { requestFlow(it) }                                                                           
        .collect { value -> // 收集并打印
            println("$value at ${System.currentTimeMillis() - startTime} ms from start") 
        } 
}
输出：
1: First at 136 ms from start
2: First at 231 ms from start
3: First at 333 ms from start
1: Second at 639 ms from start
2: Second at 732 ms from start
3: Second at 833 ms from start

每个数据流都执行了一遍

flatMapLatest

与 collectLatest 操作符类似，也有相对应的“最新”展平模式，在发出新流后立即取消先前流的收集，收集完成后不在单独收集

fun main() = runBlocking<Unit> { 
    val startTime = System.currentTimeMillis() // 记录开始时间
    (1..3).asFlow().onEach { delay(100) } // 每 100 毫秒发射一个数字 
        .flatMapLatest { requestFlow(it) }                                                                           
        .collect { value -> // 收集并打印
            println("$value at ${System.currentTimeMillis() - startTime} ms from start") 
        } 
}
输出：
1: First at 142 ms from start
2: First at 322 ms from start
3: First at 425 ms from start
3: Second at 931 ms from start

执行完最后一个后，再延时500ms发射second，这在该特定示例中不会有什么区别，由于调用 requestFlow 自身的速度是很快的，不会发生挂起，所以不会被取消

流异常

1.收集器 try 与 catch

check发射异常处理，捕获异常并输出 fun simple(): Flow = flow { for (i in 1..3) { println("Emitting $i") emit(i) // 发射下一个值 } } .map { value -> check(value <= 1) { "Crashed on $value" }
"string $value" }

fun main() = runBlocking<Unit> {
    try {
        simple().collect { value -> println(value) }
    } catch (e: Throwable) {
        println("Caught $e")
    } 
} 
输出：
Emitting 1
string 1
Emitting 2
Caught java.lang.IllegalStateException: Crashed on 2

异常透明性

发射器可以使用 catch 操作符来保留此异常的透明性并允许封装它的异常处理。catch 操作符的代码块可以分析异常并根据捕获到的异常以不同的方式对其做出反应： - 可以使用 throw 重新抛出异常。 - 可以使用 catch 代码块中的 emit 将异常转换为值发射出去。 - 可以将异常忽略，或用日志打印，或使用一些其他代码处理它。

fun main() = runBlocking<Unit> {
    simple()
        .catch { e -> emit("Caught $e") } // 发射一个异常
        .collect { value -> println(value) }
}
输出：
Emitting 1
string 1
Emitting 2
Caught java.lang.IllegalStateException: Crashed on 2

与try/catch相同处理

透明捕获

catch 过渡操作符遵循异常透明性，仅捕获上游异常（catch 操作符上游的异常，但是它下面的不是）。 如果 collect { ... } 块（位于 catch 之下）抛出一个异常，那么异常会逃逸

fun simple(): Flow<Int> = flow {
    for (i in 1..3) {
        println("Emitting $i")
        emit(i)
    }
}

fun main() = runBlocking<Unit> {
    simple()
        .catch { e -> println("Caught $e") } // 不会捕获下游异常
        .collect { value ->
            check(value <= 1) { "Collected $value" }                 
            println(value) 
        }
}   
输出：
Emitting 1
1
Emitting 2
Exception in thread "main" java.lang.IllegalStateException: Collected 2

声明式捕获

我们可以将 catch 操作符的声明性与处理所有异常的期望相结合，将 collect 操作符的代码块移动到 onEach 中，并将其放到 catch 操作符之前。收集该流必须由调用无参的 collect() 来触发

fun main() = runBlocking<Unit> {
    simple()
        .onEach { value ->
            check(value <= 1) { "Collected $value" }                 
            println(value) 
        }
        .catch { e -> println("Caught $e") }
        .collect()
}
输出：
Emitting 1
1
Emitting 2
Caught java.lang.IllegalStateException: Collected 2

使用onEach处理collect的内容，可以不修改catch与collect的上下游位置也可以达到异常的捕获

流完成

当流收集完成时（普通情况或异常情况），它可能需要执行一个动作。你可能已经注意到，它可以通过两种方式完成：命令式或声明式

命令式 finally 块

除了 try/catch 之外，收集器还能使用 finally 块在 collect 完成时执行一个动作

fun simple(): Flow<Int> = (1..3).asFlow()

fun main() = runBlocking<Unit> {
    try {
        simple().collect { value -> println(value) }
    } finally {
        println("Done")
    }
}   
输出：
1
2
3
Done

声明式处理

对于声明式，流拥有 onCompletion 过渡操作符，它在流完全收集时调用。

simple()
.onCompletion { println("Done") }
.collect { value -> println(value) }

onCompletion 的主要优点是其 lambda 表达式的可空参数 Throwable 可以用于确定流收集是正常完成还是有异常发生

fun simple(): Flow<Int> = flow {
    emit(1)
    throw RuntimeException()
}

fun main() = runBlocking<Unit> {
    simple()
        .onCompletion { cause -> if (cause != null) println("Flow completed exceptionally") }
        .catch { cause -> println("Caught exception") }
        .collect { value -> println(value) }
}   
输出：
1
Flow completed exceptionally
Caught exception

onCompletion 操作符与 catch 不同，它不处理异常。我们可以看到前面的示例代码，异常仍然流向下游。它将被提供给后面的 onCompletion 操作符，并可以由 catch 操作符处理，可以使用onCompletion再异常处理前打印自己想要的日志

成功完成

与 catch 操作符的另一个不同点是 onCompletion 能观察到所有异常并且仅在上游流成功完成（没有取消或失败）的情况下接收一个 null 异常

fun simple(): Flow<Int> = (1..3).asFlow()

fun main() = runBlocking<Unit> {
    simple()
        .onCompletion { cause -> println("Flow completed with $cause") }
        .collect { value ->
            check(value <= 1) { "Collected $value" }                 
            println(value) 
        }
}
输出：
1
Flow completed with java.lang.IllegalStateException: Collected 2
Exception in thread "main" java.lang.IllegalStateException: Collected 2

如果下游没有异常终止，得到的数据是一个null

启动流

onEach 是一个过渡操作符。我们也需要一个末端操作符来收集流。否则仅调用 onEach 是无效的。如果我们在 onEach 之后使用 collect 末端操作符，那么后面的代码会一直等待直至流被收集

// 模仿事件流
fun events(): Flow<Int> = (1..3).asFlow().onEach { delay(100) }

fun main() = runBlocking<Unit> {
    events()
        .onEach { event -> println("Event: $event") }
        .collect() // <--- 等待流收集
    println("Done")
}  
输出：
Event: 1
Event: 2
Event: 3
Done

等待流收集完成，才执行后面的代码

使用 launchIn 替换 collect 我们可以在单独的协程中启动流的收集，这样就可以立即继续进一步执行代码

fun main() = runBlocking<Unit> {
    events()
        .onEach { event -> println("Event: $event") }
        .launchIn(this) // <--- 在单独的协程中执行流
    println("Done")
} 
输出
Done
Event: 1
Event: 2
Event: 3

launchIn 必要的参数 CoroutineScope 指定了用哪一个协程来启动流的收集（传入的参数）。在先前的示例中这个作用域来自 runBlocking 协程构建器，在这个流运行的时候，runBlocking 作用域等待它的子协程执行完毕并防止 main 函数返回并终止此示例。

作用域来自于一个寿命有限的实体。在该实体的寿命终止后，相应的作用域就会被取消，即取消相应流的收集。这种成对的 onEach { ... }.launchIn(scope) 工作方式就像 addEventListener 一样。而且，这不需要相应的 removeEventListener 函数，因为取消与结构化并发可以达成这个目的

注：launchIn 也会返回一个 Job，可以在不取消整个作用域的情况下仅取消相应的流收集或对其进行 join

流取消检测

为方便起见，流构建器对每个发射值执行附加的 ensureActive 检测以进行取消。这意味着从 flow { ... } 发出的繁忙循环是可以取消的

fun foo(): Flow<Int> = flow { 
    for (i in 1..5) {
        println("Emitting $i") 
        emit(i) 
    }
}

fun main() = runBlocking<Unit> {
    foo().collect { value -> 
        if (value == 3) cancel()  
        println(value)
    } 
}
输出：
Emitting 1
1
Emitting 2
2
Emitting 3
3
Emitting 4
Exception in thread "main" kotlinx.coroutines.JobCancellationException: BlockingCoroutine was cancelled; job="coroutine#1":BlockingCoroutine{Cancelled}@6d7b4f4c

出于性能原因，大多数其他流操作不会自行执行其他取消检测

fun main() = runBlocking<Unit> {
    (1..5).asFlow().collect { value -> 
        if (value == 3) cancel()  
        println(value)
    } 
}
输出：
1
2
3
4
5
Exception in thread "main" kotlinx.coroutines.JobCancellationException: BlockingCoroutine was cancelled; job="coroutine#1":BlockingCoroutine{Cancelled}@3327bd23

在协程处于繁忙循环的情况下，必须明确检测是否取消。可以添加 .onEach { currentCoroutineContext().ensureActive() }，但是这里提供了一个现成的 cancellable 操作符来执行此操作

fun main() = runBlocking<Unit> {
    (1..5).asFlow().cancellable().collect { value -> 
        if (value == 3) cancel()  
        println(value)
    } 
}
输出：
1
2
3
Exception in thread "main" kotlinx.coroutines.JobCancellationException: BlockingCoroutine was cancelled; job="coroutine#1":BlockingCoroutine{Cancelled}@5ec0a365

管道

延期的值提供了一种便捷的方法使单个值在多个协程之间进行相互传输。

通道基础（channel)

一个 Channel 是一个和 BlockingQueue 非常相似的概念,提供了挂起的 send发送,提供了挂起的 receive接收

fun main() = runBlocking {
    val channel = Channel<Int>()
    launch {
        // 这里可能是消耗大量 CPU 运算的异步逻辑，我们将仅仅做 5 次整数的平方并发送
        for (x in 1..5) channel.send(x * x)
    }
    // 这里我们打印了 5 次被接收的整数：
    repeat(5) { println(channel.receive()) }
    println("Done!")
}
输出：
1
4
9
16
25
Done!

通道的关闭与迭代（close）

和队列不同，一个通道可以通过被关闭来表明没有更多的元素将会进入通道。在接收者中可以定期的使用 for 循环来从通道中接收元素。

一个 close 操作就像向通道发送了一个特殊的关闭指令。这个迭代停止就说明关闭指令已经被接收了。所以这里保证所有先前发送出去的元素都在通道关闭前被接收到

fun main() = runBlocking {
    val channel = Channel<Int>()
    launch {
        for (x in 1..5) channel.send(x * x)
        channel.close() // 我们结束发送
    }
    // 这里我们使用 `for` 循环来打印所有被接收到的元素（直到通道被关闭）
    for (y in channel) println(y)
    println("Done!")
}
输出
1
4
9
16
25
Done!

构建通道生产者

生产者——消费者 模式的一部分。这里有一个名为produce 的便捷的协程构建器，可以很容易的在生产者端正确工作，并且我们使用扩展函数 consumeEach 在消费者端替代 for 循环

fun CoroutineScope.produceSquares(): ReceiveChannel<Int> = produce {
    for (x in 1..5) send(x * x)
}

fun main() = runBlocking {
    val squares = produceSquares()
    squares.consumeEach { println(it) }
    println("Done!")
}
输出：
1
4
9
16
25
Done!

管道

管道是一种一个协程在流中开始生产可能无穷多个元素的模式

fun main() = runBlocking {
    val numbers = produceNumbers() // 从 1 开始生成整数
    val squares = square(numbers) // 整数求平方
    //子协程处理数据
    repeat(5) {
        println(squares.receive()) // 输出前五个
    }
    println("Done!") // 至此已完成
    coroutineContext.cancelChildren() // 取消子协程
}

//生成数据
fun CoroutineScope.produceNumbers() = produce<Int> {
    var x = 1
    while (true) send(x++) // 从 1 开始的无限的整数流
}
//传递管道使用操作数据
fun CoroutineScope.square(numbers: ReceiveChannel<Int>): ReceiveChannel<Int> = produce {
    for (x in numbers) send(x * x)
}

使用管道查找质数

1.使用produce，

fun main() = runBlocking {
    var cur = numbersFrom(2)
    repeat(10) {//打印前十个质数
        val prime = cur.receive()
        println(prime)
        cur = filter(cur, prime)
    }
    coroutineContext.cancelChildren() // 取消所有的子协程来让主协程结束    
}

//开启数字管道
fun CoroutineScope.numbersFrom(start: Int) = produce<Int> {
    var x = start
    while (true) send(x++) // 从 start 开始过滤整数流
}
//过滤管道数据
fun CoroutineScope.filter(numbers: ReceiveChannel<Int>, prime: Int) = produce<Int> {
    for (x in numbers) if (x % prime != 0) send(x)
}

2.使用iterator 协程构建器构造相似的管道，使用 iterator 替换 produce、yield 替换 send、next 替换 receive、 Iterator 替换 ReceiveChannel 来摆脱协程作用域，你将不再需要 runBlocking，produce需要主动去关闭协程

fun main(){  
    var cur = numbersFrom(2)
    repeat(10) {//打印前十个质数
        val prime = cur.next()
        println(prime)
        cur = filter(cur, prime)
    }
    coroutineContext.cancelChildren() // 取消所有的子协程来让主协程结束    
}

//开启数字管道
fun numbersFrom(start: Int) = iterator<Int> {
    var x = start
    while (true) yield(x++) // 从 start 开始过滤整数流
}
//过滤管道数据
fun filter(numbers: Iterator<Int>, prime: Int) = iterator<Int> {
    for (x in numbers) if (x % prime != 0) yield(x)
}

输出结果一致，区别：在实践中，管道调用了另外的一些挂起中的调用（就像异步调用远程服务）并且这些管道不能内置使用 sequence/iterator，因为它们不被允许随意的挂起，不像 produce 是完全异步的

扇出

多个协程也许会接收相同的管道，在它们之间进行分布式工作

创建五个协程打印通道数据

fun main() = runBlocking<Unit> {
    val producer = produceNumbers()
    repeat(5) { launchProcessor(it, producer) }
    delay(950)
    producer.cancel() // 取消协程生产者从而将它们全部杀死
}

fun CoroutineScope.produceNumbers() = produce<Int> {
    var x = 1 // start from 1
    while (true) {
        send(x++) // 产生下一个数字
        delay(100) // 等待 0.1 秒
    }
}

fun CoroutineScope.launchProcessor(id: Int, channel: ReceiveChannel<Int>) = launch {
    for (msg in channel) {
        println("Processor #$id received $msg")
    }    
}
输出：
Processor #2 received 1
Processor #4 received 2
Processor #0 received 3
Processor #1 received 4
Processor #3 received 5
Processor #2 received 6
Processor #4 received 7
Processor #0 received 8
Processor #1 received 9
Processor #3 received 10

取消生产者协程将关闭它的通道，从而最终终止处理器协程正在执行的此通道上的迭代 与 consumeEach 不同，这个 for 循环是安全完美地使用多个协程的。如果其中一个处理器协程执行失败，其它的处理器协程仍然会继续处理通道，而通过 consumeEach 编写的处理器始终在正常或非正常完成时消耗（取消）底层通道

扇入

多个协程可以发送到同一个通道

fun main() = runBlocking {
    val channel = Channel<String>()
    launch { sendString(channel, "foo", 200L) }
    launch { sendString(channel, "BAR!", 500L) }
    repeat(6) { // 接收前六个
        println(channel.receive())
    }
    coroutineContext.cancelChildren() // 取消所有子协程来让主协程结束
}

suspend fun sendString(channel: SendChannel<String>, s: String, time: Long) {
    while (true) {
        delay(time)
        channel.send(s)
    }
}
输出：
foo
foo
BAR!
foo
foo
BAR!

带缓冲的通道

没有缓冲的通道，如果发送先被调用，则它将被挂起直到接收被调用，如果接收先被调用，它将被挂起直到发送被调用。有缓冲的通道，Channel() 工厂函数与 produce 建造器通过一个可选的参数 capacity 来指定缓冲区大小。缓冲允许发送者在被挂起前发送多个元素，就像 BlockingQueue 有指定的容量一样，当缓冲区被占满的时候将会引起阻塞

fun main() = runBlocking<Unit> {
    val channel = Channel<Int>(4) // 启动带缓冲的通道
    val sender = launch { // 启动发送者协程
        repeat(10) {
            println("Sending $it") // 在每一个元素发送前打印它们
            channel.send(it) // 将在缓冲区被占满时挂起
        }
    }
    // 没有接收到东西……只是等待……
    delay(1000)
    sender.cancel() // 取消发送者协程    
}
输出
Sending 0
Sending 1
Sending 2
Sending 3
Sending 4
//前四个元素被加入到了缓冲区并且发送者在试图发送第五个元素的时候被挂起

通道是公平的

发送和接收操作是公平的并且尊重调用它们的多个协程。它们遵守先进先出原则，可以看到第一个协程调用 receive 并得到了元素

data class Ball(var hits: Int)

fun main() = runBlocking {
    val table = Channel<Ball>() // 一个共享的 table（桌子）
    launch { player("ping", table) }
    launch { player("pong", table) }
    table.send(Ball(0)) // 乒乓球
    delay(1000) // 延迟 1 秒钟
    coroutineContext.cancelChildren() // 游戏结束，取消它们
}

suspend fun player(name: String, table: Channel<Ball>) {
    for (ball in table) { // 在循环中接收球
        ball.hits++
        println("$name $ball")
        delay(300) // 等待一段时间
        table.send(ball) // 将球发送回去
    }
}
输出：
ping Ball(hits=1)
pong Ball(hits=2)
ping Ball(hits=3)
pong Ball(hits=4)
//每300ms发送一次数据到通道，打印，直到1000ms结束

异常处理

被取消的协程会在挂起点抛出 CancellationException 并且它会被协程的机制所忽略

异常的传播

协程构建器有两种形式：自动传播异常（launch 与 actor）或向用户暴露异常（async 与 produce），自动传播异常可自动识别弹出异常，暴露异常需要消费，需要通过.await()或.receive()消费捕获

fun main() = runBlocking {
    val handler = CoroutineExceptionHandler { _, exception -> 
        println("CoroutineExceptionHandler got $exception") 
    }
    val job = GlobalScope.launch(handler) { // 根协程，运行在 GlobalScope 中
        throw AssertionError()
    }
    val deferred = GlobalScope.async(handler) { // 同样是根协程，但使用 async 代替了 launch
        throw ArithmeticException() // 没有打印任何东西，依赖用户去调用 deferred.await()
    }
    joinAll(job, deferred)    
}
输出：
CoroutineExceptionHandler got java.lang.AssertionError

CoroutineExceptionHandler

将未捕获异常打印到控制台的默认行为是可自定义的。根协程中的 CoroutineExceptionHandler 上下文元素可以被用于这个根协程通用的 catch 块，及其所有可能自定义了异常处理的子协程。它类似于 Thread.uncaughtExceptionHandler 。你无法从 CoroutineExceptionHandler 的异常中恢复。当调用处理者的时候，协程已经完成并带有相应的异常。通常，该处理者用于记录异常，显示某种错误消息，终止和（或）重新启动应用程序。

CoroutineExceptionHandler 仅在未捕获的异常上调用 — 没有以其他任何方式处理的异常。特别是，所有子协程（在另一个 Job 上下文中创建的协程）委托

CoroutineExceptionHandler 总是被设置在由 GlobalScope 启动的协程中

案例：如上

取消与异常

取消与异常紧密相关。协程内部使用 CancellationException 来进行取消，这个异常会被所有的处理者忽略，所以那些可以被 catch 代码块捕获的异常仅仅应该被用来作为额外调试信息的资源，当一个协程使用Job.cancel 取消的时候，它会被终止，但是它不会取消它的父协程

fun main() = runBlocking {
    val job = launch {
        val child = launch {
            try {
                delay(Long.MAX_VALUE)
            } finally {
                println("Child is cancelled")
            }
        }
        yield()
        println("Cancelling child")
        child.cancel()
        child.join()
        yield()
        println("Parent is not cancelled")
    }
    job.join()    
}
输出
Cancelling child
Child is cancelled
Parent is not cancelled//父线程未取消

注：当父协程的所有的子协程都结束后，原始的异常才会被父协程处理

监督

取消是在协程的整个层次结构中传播的双向关系，监督用于单向取消的情况

监督作业

SupervisorJob 可以用于这些目的。它类似于常规的 Job，唯一的不同是：SupervisorJob 的取消只会向下传播。这是很容易用以下示例演示

fun main() = runBlocking {
    val supervisor = SupervisorJob()
    with(CoroutineScope(coroutineContext + supervisor)) {
        // 启动第一个子作业——这个示例将会忽略它的异常（不要在实践中这么做！）
        val firstChild = launch(CoroutineExceptionHandler { _, _ ->  }) {
            println("The first child is failing")
            throw AssertionError("The first child is cancelled")
        }
        // 启动第二个子作业
        val secondChild = launch {
            firstChild.join()
            // 取消了第一个子作业且没有传播给第二个子作业
            println("The first child is cancelled: ${firstChild.isCancelled}, but the second one is still active")
            try {
                delay(Long.MAX_VALUE)
            } finally {
                // 但是取消了监督的传播
                println("The second child is cancelled because the supervisor was cancelled")
            }
        }
        // 等待直到第一个子作业失败且执行完成
        firstChild.join()
        println("Cancelling the supervisor")
        supervisor.cancel()
        secondChild.join()
    }
}
输出：
The first child is failing
The first child is cancelled: true, but the second one is still active
Cancelling the supervisor
The second child is cancelled because the supervisor was cancelled

监督作用域

对于作用域的并发，可以用 supervisorScope 来替代 coroutineScope 来实现相同的目的。它只会单向的传播并且当作业自身执行失败的时候将所有子作业全部取消。作业自身也会在所有的子作业执行结束前等待，就像 coroutineScope 所做的那样

fun main() = runBlocking {
    try {
        supervisorScope {
            val child = launch {
                try {
                    println("The child is sleeping")
                    delay(Long.MAX_VALUE)
                } finally {
                    println("The child is cancelled")
                }
            }
            // 使用 yield 来给我们的子作业一个机会来执行打印
            yield()
            println("Throwing an exception from the scope")
            throw AssertionError()
        }
    } catch(e: AssertionError) {
        println("Caught an assertion error")
    }
}
输出
The child is sleeping
Throwing an exception from the scope
The child is cancelled  //子协程先处理异常输出
Caught an assertion error

监督协程中的异常

常规的作业和监督作业之间的另一个重要区别是异常处理。监督协程中的每一个子作业应该通过异常处理机制处理自身的异常。这种差异来自于子作业的执行失败不会传播给它的父作业的事实。这意味着在 supervisorScope 内部直接启动的协程确实使用了设置在它们作用域内的 CoroutineExceptionHandler，与父协程的方式相同

fun main() = runBlocking {
    val handler = CoroutineExceptionHandler { _, exception -> 
        println("CoroutineExceptionHandler got $exception") 
    }
    supervisorScope {
        val child = launch(handler) {
            println("The child throws an exception")
            throw AssertionError()
        }
        println("The scope is completing")
    }
    println("The scope is completed")
}
输出
The scope is completing //父协程
The child throws an exception//子协程
CoroutineExceptionHandler got java.lang.AssertionError//子协程异常
The scope is completed//父协程完成

MMsmileNN

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
kotlin中的协程

协程CoroutinerunBlocking协程构造器（阻塞的）runBlocking<Unit> { …… } 作为用来启动顶层主协程的适配器GlobalScop全局协程（非阻塞）1. 可以将 GlobalScope.launch { …… } 替换为 thread { …… }2. 将 delay(……) 替换为 Thread.sleep(……)3. delay 是一个特殊的***挂起函数***4. GlobalScope.launch启动一个协程，这
复制链接

扫一扫