多线程的优势
尽管使用多线程有挑战，但是由于使用多线程也有很多好处，我们仍然使用多线程。这些优势(好处)是：
- 更好的资源利用率
- 在一些情景下更好的程序设计
- 更具有响应性的程序
更好的资源利用率
想象有一个在文件系统中读和处理文件的程序。如果从磁盘中读一个文件需要使用5秒钟，处理它需要使用2秒钟。处理两个文件就需要：
5秒钟用于读文件A
2秒钟用于处理文件A
5秒钟用于读文件B
2秒钟用于处理文件B
-------------------
共14秒
当cpu从磁盘中读文件的时候，大部分的cpu时间被用于等待文件被磁盘中读出(读入内存)。cpu在这段时间其实是非常空闲的。它能够做一些其他的事情。通过改变操作顺序，cpu能够被更好更有效率地利用。看一下下面这个顺序。
5秒钟用于读文件A
5秒钟用于读文件B+2秒钟用于处理文件A
2秒钟用于处理文件B
------------------
共12秒
cpu先等待读第一个文件。然后他开始读第二个文件。当第二个文件正在被读时，cpu处理了第一个文件。记住，当cpu等待文件从磁盘中被读出时，cpu大部分时间都是空闲的。
一般来说，当cpu在等待IO的时候，cpu能够做其他事情。不仅仅局限于磁盘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
}
通过这种方法，服务将会马上返回继续监听。这样更多的客户端能够发送请求到服务端。服务端能够变得更具有响应性。
这种情况和桌面程序是一样的。如果你点了一个按钮引发了一个长时间的任务，这个线程执行的任务是更新窗口，按钮和其他...但是当这个任务执行时，这个应用将不会响应。换一种方式，任务可以交给工作线程。当工作线程忙于这个任务时，窗口线程能够回应其他用户的请求。当工作线程完成时，他会发送一个信号给窗口线程。这个窗口线程能够用任务的结果来更新应用的界面。这种带有工作线程设计的程序变得更具有响应性了。
ps:本人只是一个自学英语一段时间的初级程序猿。无论是英语翻译程度，还是技术理解程度都远远不足，如果文中有翻译不到位，或者技术理解错误情况，还请各位指出，必定改正，也可相互学习交流。
