更好的资源利用

假设一个应用会从本地文件系统中读取和处理文件。我们假设从磁盘上读取一个文件花费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会等待第一个文件的读取。然后他开始读取第二个文件。当第二个文件正在被读取的时候，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
}

这种情况下，服务器线程会更快地监听请求。就有更多地客户端可以向服务器发送请求。服务器因此而更具有响应性。

对于桌面应用也是这样的。如果你点击一个按钮开启一个耗时很长的任务，并且执行任务的线程同时也是更新窗口，按钮等的线程，那么应用会在处理任务的时候表现得响应性很差。其实可以把任务交给后台的线程。当后台线程繁忙地处理任务地时候，窗口线程可以继续响应用户其他地请求。当工作线程把任务处理完毕之后，可以给窗口线程发送信号。这时，窗口线程可以根据任务处理的结果来更新应用窗口。采用后台线程程序可以对用户表现得更具有更好得响应。