本系列译自jakob jenkov的Java并发多线程教程，个人觉得很有收获。由于个人水平有限，不对之处还望矫正！
尽管多线程有诸多的挑战，但是多线程被广泛使用的原因有以下几点：
1、对资源的充分利用。
2、简化程序设计
3、响应的及时性
资源的充分利用
假设一个应用程序从本地文件系统中读取并处理一个文件，让我们来假设从硬盘读取文件需要5秒，处理文件需要两秒，那么处理两个文件则需要：
5秒 读取A文件
2秒 处理A文件
5秒 读取B文件
2秒 处理B文件
共需14秒
当从硬盘读取文件的时候，CPU大部分时间用在等待从硬盘读取数据，CPU 在等待的这段时间是非常空闲的，是可以被利用来做其他事情的，通过改变执行顺序，CPU 可以被更好的利用。看下面的执行顺序：
5秒 读取A文件
5秒 读取B文件+2秒处理A文件
2秒 处理B文件
共需12秒
到CPU等待A文件读取的时候，开始读取B文件，当B文件正在读取的时候，CPU 开始处理A文件，记住，当CPU 等待从硬盘读取文件的时候，CPU 几乎是空闲的。
通常，CPU 在等待IO操作时，可以做其他的事情的，不光是磁盘IO,网络IO也是一样的
简化程序设计
如果你打算用一个单线程的程序去处理上面的问题，你不得不时刻跟踪每个文件的读取和处理状态。而用多线程，你只需要启动两个线程，而每个线程只需负责单个文件读取和处理。这些线程会被blocked当等待从磁盘上读取文件，在等待的同时，另外的线程可以利用CPU 来处理它已经读到的数据，这样做的结果就是，磁盘一直处于繁忙的状态，不断地从磁盘读取数据到内存中。这样做，对于磁盘和CPU 的利用率得到提升，同时对于程序来说也更简单，因为每个线程只需去跟踪一个文件的读取和处理状态
响应的及时性
将单线程转变为多线程的另一个目的是更具有响应的及时性。假设一个服务端程程序在一个端口上监听请求，当收到请求后，它对这个请求进行相应的处理，然后再返回去监听另外的请求。服务端程序如下：
while(server is active){
listen for the request
process request
}
如果这个请求花费了很长的时间去处理，那么客户端就不能在此期间发送任何请求到服务端，只有当服务端处理完当前请求再次回到监听时才能接受新的请求。另一种设计是监听线程把接受到的请求交给工作线程(work thread )然后立即返回监听。工作线程会对请求进行处理，并对客户端返回一个结果。这种设计模式如下：
while(server is active){
listen for request
handle request to work thread
}
这种方式，监听线程会很快继续进行监听，因此更多的客户端可以发送更多的请求到服务端，服务端也变的更具响应性。这对桌面应用程序也是一样的。
