louc2022-04-25对于单线程并发，要提一个不同观点，在实际项目中delay这种延时任务往往是io操作，我做了一个测试，把这里delay替换为file.readText去读一个10M的文件，那个三个协程都用同一个mySingleDispatcher的话其实是串行执行的，并没与起到优化并行的效果，所以如果要说协程的优越性，这里还是得使用IO线程池既Dispatcher.IO。这样可以把多IO任务同时启动，达到并行优化，否则，同一个线程，协程无法并行，时间消耗是三个IO动作之和作者回复: 其实，主要还是因为用了Java底层的阻塞式IO。不可否认的是，现实生活中，符合条件的非阻塞场景并不多。
共 3 条评论7
êｗěｎ2022-03-09mutex是挂起函数，那么它存在竞争的话是支持协程挂起，意味着底层线程资源可以复用，比起Java的线程并不会浪费多余的系统资源作者回复: 没错
7
神秘嘉Bin2022-03-09大眼看了下Mutex的源码，看起来很像AQS的实现。 这里等待的节点可能不是自旋等待，应该是把CallBack塞到了队列，前面节点释放锁，后续节点竞争然后执行CallBack。 因为没有自旋等待，所以不会阻塞线程，效率自然会高。作者回复: 是的，可以这么理解。
4
Allen2022-03-09我认为 Mutex 比 JDK 的锁性能更好，主要有两个原因： 1. Mudex 挂起的是协程，协程被挂起，线程并不会被阻塞。而 JDK 锁的都是线程，线程会被阻塞。 2. 挂起不浪费系统资源，而阻塞由于会管理锁队列等，会浪费更多的系统资源。 本质上来说，这个效率和资源是由挂起函数的实现方式决定的，而这也是协程的核心。作者回复: 是的，可以这么理解。
3
杨小妞2022-03-26并发场景：多线程执行耗时任务（例如网络请求）。如果用“单线程并发”的概念去实现，应该是无法达到目的。作者回复: 主要是看任务是“阻塞型”，还是“非阻塞型”。如果是阻塞型，则无法：单线程并发。
2
辉哥2022-03-09大佬，问个问题，Mutex是非阻塞的，那它是如何防止共享变量不会同时被多个线程修改的作者回复: 其实，它的流程和普通锁是差不多的，区别在于，普通的锁在获取不到执行权限的时候，会阻塞，而Mutex则是挂起。
共 2 条评论2
白乾涛2022-03-18老师，我觉得"单线程并发"是一个伪概念，他只是看起来像是并发代码，实际上，这种"单线程并发"的代码用 Java 的 CallBack 也是可以实现的 --- 比如借助 LockSupport作者回复: 可以这么理解，协程的好处在于，并发概念与线程之间完全解耦了，同样的代码改动一个参数就能实现单线程并发。案例中之所以可以实现单线程并发，本质还是因为非阻塞。
共 2 条评论1- 神秘嘉Bin2022-03-09大眼看了下Mutex的实现，看上去很像AQS的实现；可能是基于AQS进行了一波改造吧尝试加锁成功就resume；
作者回复: 嗯，其中有挂起和恢复。
1 - 杨小妞2022-03-26业务场景：生产消费者。如果希望用协程来控制消费者的个数，除了自定义Dispatchs以外，还有什么其他好的方式吗？
作者回复: 多个消费者不一定要多个线程，我们使用多个协程也可以的。
- 白乾涛2022-03-18这个问题和"协程对线程性能更好吗"类似，我觉得答案都是否定的，因为这么比较不公平。 如果这么问：大神用 Kotlin 的 Mutex 写的代码，和大神用 JDK 的锁写的代码，相比，性能更好吗？
作者回复: 确实没有绝对的优劣，要分场景讨论才行。