什么情况下使用多线程？

----摘自《Java编程思想》

用并发解决的问题大体上可以分为“速度”和“设计可管理性”两种。

速度问题听起来很简单：如果你想要一个程序运行得更快，那么可以将其断开为多个片段，在单独的处理器上运行每个片段。并发是用于多处理器编程的基本工具。当前，摩尔定律已经有些过时了（至少对于传统芯片是这样），速度提高是以多核处理器的形式而不是更快的芯片的形式出现的。为了使程序运行得更快，你必须学习如何利用这些额外的处理器，而这正是并发赋予你的能力。

如果你有一台多处理器的机器，那么就可以在这些处理器之间分布多个任务，从而可以极大地提高吞吐量。这是使用强有力的多处理器Web服务器的常见情况，在为每个请求分配一个线程的程序中，它可以将大量的用户请求分布到多个CPU上。

但是，并发通常是提高运行在单处理器上的程序的性能。

这听起来有些违背直觉。如果你仔细考虑一下就会发现，在单处理器上运行的并发程序开销确实应该比该程序的所有部分都顺序执行的开销大，因为其中增加所谓了上下文切换的代价（从一个任务切换到另一个任务）。表面上看，将程序的所有部分当作单个的任务运行好象是开销更小一点，并且可以节省上下文切换的代价。

使这个问题变得有些不同的是阻塞。如果程序中的某个任务因为该程序控制范围之外的某些条件（通常是I/O）而导致不能继续执行，那么我们就可以说这个任务或者线程阻塞了。如果没有并发，则整个程序都将停止下来，直至外部条件发生变化。但是，如果使用并发来编写程序，那么当一个任务阻塞时，程序中的其他任务还可以继续执行，因此这个程序可以保持继续向前执行。事实上，从性能的角度看，如果没有任务会阻塞，那么在单处理器上使用并发就没有任何意义。

在单处理器系统中的性能提高的常见示例是事件驱动的编程。实际上，使用并发最吸引人的一个原因就是要产生具有可响应的用户界面。考虑这样一个程序，它因为将执行某些长期运行的操作，所以最终用户输入会被忽略，从而成为不可响应的程序。如果有一个“退出”按钮，那么你肯定不想在你写的每一段代码中都检查它的状态。因为这会产生非常尴尬的代码，而我们也无法保证程序员不会忘记这种检查。如果不使用并发，则产生可响应用户界面的唯一方式就是所有的任务都周期性地检查用户输入。通过创建单独的执行线程来响应用户的输入，即使这个线程在大多数时间里都是阻塞的，但是程序可以保证具有一定程度的可响应性。