multithreading - 哪些用例适用于 Kotlin 中的 Dispatchers.Default？

Question

根据文档IO 的线程池大小和 Default调度员的行为如下:

Dispatchers.Default :默认情况下，此调度程序使用的最大并行级别等于 CPU 内核数，但至少为 2。

Dispatchers.IO :默认为 64 个线程的限制或内核数(以较大者为准)。

除非我遗漏了一条信息，否则在 Default 上执行大量 CPU 密集型工作效率更高(更快)，因为 上下文切换的发生频率较低 .

但是下面的代码实际上在 Dispatchers.IO 上运行得更快:

fun blockingWork() {
    val startTime = System.currentTimeMillis()
    while (true) {
        Random(System.currentTimeMillis()).nextDouble()
        if (System.currentTimeMillis() - startTime > 1000) {
            return
        }
    }
}

fun main() = runBlocking {
    val startTime = System.nanoTime()
    val jobs = (1..24).map { i ->
        launch(Dispatchers.IO) { // <-- Select dispatcher here
            println("Start #$i in ${Thread.currentThread().name}")
            blockingWork()
            println("Finish #$i in ${Thread.currentThread().name}")
        }
    }
    jobs.forEach { it.join() }
    println("Finished in ${Duration.of(System.nanoTime() - startTime, ChronoUnit.NANOS)}")
}

我在 8 核 CPU 上运行 24 个作业(因此，我可以让 Default 调度程序的所有线程保持忙碌状态)。这是我机器上的结果:

Dispatchers.IO --> Finished in PT1.310262657S
Dispatchers.Default --> Finished in PT3.052800858S

你能告诉我我在这里缺少什么吗？如 IO效果更好，为什么我应该使用除 IO 以外的任何调度程序(或任何具有大量线程的线程池)。

Answer 1

回答您的问题:Default调度程序最适合不具有阻塞功能的任务，因为在并发执行此类工作负载时不会超过最大并行度(the-difference-between-concurrent-and-parallel-execution)。

https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/5_CPU_Scheduling.html

你的实验有缺陷。正如评论中已经提到的，您的 blockingWork不受 CPU 限制，但受 IO 限制。这完全是关于等待 - 您的任务被阻塞并且 CPU 无法执行其后续指令的时期。您的 blockingWork本质上只是“等待 1000 毫秒”，并行等待 1000 毫秒 X 次将比按顺序进行更快。您执行一些计算(生成随机数 - 本质上也可能受 IO 限制)，但如前所述，您的工作人员正在生成或多或少的这些数字，具体取决于底层线程已进入休眠状态的时间。

我执行了一些生成斐波那契数的简单实验(通常用于模拟 CPU 工作负载)。但是，在考虑到 JVM 中的 JIT 之后，我无法轻易得出任何结果来证明 Default调度员表现更好。可能是上下文切换没有人们想象的那么重要。可能是调度程序没有为我的工作负载使用 IO 调度程序创建更多线程。可能是我的实验也有缺陷。不能确定 - 在 JVM 上进行基准测试本身并不简单，将协程(及其线程池)添加到组合中当然不会使它变得更简单。

但是，我认为这里需要考虑更重要的事情，那就是阻塞。 Default调度员对阻塞调用更敏感。池中的线程越少，就越有可能所有线程都被阻塞并且此时没有其他协程可以执行。

您的程序正在线程中运行。如果所有线程都被阻塞，那么你的程序就什么都不做。创建新线程很昂贵(主要是内存方面)，因此对于具有阻塞功能的高负载系统来说，这成为一个限制因素。 Kotlin 在引入“暂停”功能方面做得非常出色。您的程序的并发性不再局限于您拥有的线程数。如果一个流需要等待，它只是挂起而不是阻塞线程。然而，“世界并不完美”，并不是所有的东西都“挂起”——仍然有“阻塞”调用——你有多确定你使用的任何库都不会在幕后执行此类调用？拥有权利的同时也被赋予了重大的责任。对于协程，需要更加小心死锁，尤其是在使用 Default 时。调度员。事实上，在我看来，IO调度员应该是默认的。