● 更好的CPU使用率
● 程序设计更简单
● 更快的程序响应速度
● 更公平地分配CPU资源
多线程的最显着优点是：
● 更高的CPU利用率。
● 在某些情况下，程序设计更简单。
● 更快的程序响应速度。
● 在不同任务之间更公平地分配CPU资源。
更高的CPU利用率
假设有这样一个应用程序，它需要从本地文件系统中读取并处理文件。假设从磁盘读取一个文件需要5秒钟，处理它需要2秒钟。 如果我们需要处理两个文件。
5 seconds reading file A
2 seconds processing file A
5 seconds reading file B
2 seconds processing file B
-----------------------
14 seconds total
从磁盘读取文件时，大部分的CPU时间都花在等待磁盘读取数据上。 在这段时间内，CPU几乎处于空闲状态。 它可能正在做其他事情。 通过更改操作顺序，可以更好地利用CPU。 查看以下顺序：
5 seconds reading file A
5 seconds reading file B + 2 seconds processing file A
2 seconds processing file B
-----------------------
12 seconds total
首先，CPU等待读取第一个文件。接下来，它开始读取第二个文件。 在计算机的IO组件读取第二个文件的同时，CPU处理第一个文件。 请记住，在等待从磁盘读取文件时，CPU大部分处于空闲状态。
通常，CPU在等待IO时可以做其他事情。 不一定是磁盘IO。 它也可以是网络IO，也可以是来自计算机用户的输入。 网络和磁盘IO通常比CPU和内存IO慢很多。
程序设计更简单
如果要在单线程应用程序中手动编写上述读取和处理的顺序，则必须跟踪每个文件的读取和处理状态。 相反，您可以启动两个线程，每个线程仅读取和处理一个文件。 在等待磁盘读取其文件时，这些线程中的每个线程都会被阻止。 在等待时，其他线程可以使用CPU处理已读取的文件部分。 结果是，磁盘始终保持忙碌状态，将各种文件读入内存。 这样可以更好地利用磁盘和CPU。 编程也更容易，因为每个线程只需要跟踪一个文件即可。
更快的程序响应速度
将单线程应用程序转换为多线程应用程序的另一个常见的目标是，实现更快的程序响应速度。 想象一下，一个服务器应用程序在某个端口上监听传入的请求。 收到请求后，它将处理该请求，然后返回监听。 服务器循环如下所示：
while(server is active){
listen for request
process request
}
如果请求需要很长时间才能处理，则在这段时间内，所有其他的客户端，都不能将请求发送到服务器。 只有在服务器正在监听时，才能接收来自客户端的请求。
另一种设计是监听线程将请求传递给工作线程，然后立即返回监听。 工作线程将处理该请求，并将应答发送给客户端。 该设计概述如下：
while(server is active){
listen for request
hand request to worker thread
}
这样，服务器线程将返回到更快的监听状态。 因此，更多的客户端可以将请求发送到服务器。 服务器响应速度变得更快。
桌面应用程序也是如此。 如果单击一个按钮，该按钮启动一个长任务，而执行这个长任务的线程，是更新窗口、按钮等处于同一个线程，则在执行任务时应用程序将表现为无响应。 相反，任务可以移交给工作线程。 当工作线程忙于任务时，窗口线程可以自由响应其他用户请求。 当工作线程完成时，它向窗口线程发出信号。 然后，窗口线程可以使用任务的结果来更新应用程序窗口。 具有工作线程设计的程序，将表现出对用户更快的响应速度。
更公平地分配CPU资源
假设有一个服务器正在接收来自客户端的请求。 然后想象一下，其中一个客户端发送了一个处理时间很长的请求，例如 10秒，如果服务器使用单个线程处理了所有任务，则处理缓慢的请求之后的所有请求将被迫等待，直到处理完完整的请求为止。
通过在多个线程之间划分CPU时间，并在线程之间进行切换，CPU可以在多个请求之间更公平地共享其执行时间。 这样，即使其中一个请求较慢，也可以与较慢的请求同时执行处理速度更快的其他请求。 当然，这意味着执行慢速请求的速度甚至会更慢，因为CPU不会仅仅分配给它来进行处理。 但是，其他请求只需要等待更短的时间来处理，因为它们不必等待慢的任务完成后再来处理它们。 如果只有慢速请求要处理，则仍可以将CPU单独分配给慢速任务。
Jakob Jenkov
Last update: 2021-03-09
