Java理论与实践: 线程池与工作队列 - 编程入门网

死锁

任何多线程应用程序都有死锁风险。当一组进程或线程中的每一个都在等待 一个只有该组中另一个进程才能引起的事件时，我们就说这组进程或线程 死锁 了。死锁的最简单情形是：线程 A 持有对象 X 的独占锁，并且在等待对象 Y 的锁，而线程 B 持有对象 Y 的独占锁，却在等待对象 X 的锁。除非有某种方 法来打破对锁的等待（Java 锁定不支持这种方法），否则死锁的线程将永远等 下去。

虽然任何多线程程序中都有死锁的风险，但线程池却引入了另一种死锁可能 ，在那种情况下，所有池线程都在执行已阻塞的等待队列中另一任务的执行结果 的任务，但这一任务却因为没有未被占用的线程而不能运行。当线程池被用来实 现涉及许多交互对象的模拟，被模拟的对象可以相互发送查询，这些查询接下来 作为排队的任务执行，查询对象又同步等待着响应时，会发生这种情况。

资源不足

线程池的一个优点在于：相对于其它替代调度机制（有些我们已经讨论过） 而言，它们通常执行得很好。但只有恰当地调整了线程池大小时才是这样的。线 程消耗包括内存和其它系统资源在内的大量资源。除了 Thread 对象所需的内存 之外，每个线程都需要两个可能很大的执行调用堆栈。除此以外，JVM 可能会为 每个 Java 线程创建一个本机线程，这些本机线程将消耗额外的系统资源。最后 ，虽然线程之间切换的调度开销很小，但如果有很多线程，环境切换也可能严重 地影响程序的性能。

如果线程池太大，那么被那些线程消耗的资源可能严重地影响系统性能。在 线程之间进行切换将会浪费时间，而且使用超出比您实际需要的线程可能会引起 资源匮乏问题，因为池线程正在消耗一些资源，而这些资源可能会被其它任务更 有效地利用。除了线程自身所使用的资源以外，服务请求时所做的工作可能需要 其它资源，例如 JDBC 连接、套接字或文件。这些也都是有限资源，有太多的并 发请求也可能引起失效，例如不能分配 JDBC 连接。

并发错误

线程池和其它排队机制依靠使用 wait() 和 notify() 方法，这两个方法都 难于使用。如果编码不正确，那么可能丢失通知，导致线程保持空闲状态，尽管 队列中有工作要处理。使用这些方法时，必须格外小心；即便是专家也可能在它 们上面出错。而最好使用现有的、已经知道能工作的实现，例如在下面的 无须 编写您自己的池中讨论的 util.concurrent 包。

线程泄漏

各种类型的线程池中一个严重的风险是线程泄漏，当从池中除去一个线程以 执行一项任务，而在任务完成后该线程却没有返回池时，会发生这种情况。发生 线程泄漏的一种情形出现在任务抛出一个 RuntimeException 或一个 Error 时 。如果池类没有捕捉到它们，那么线程只会退出而线程池的大小将会永久减少一 个。当这种情况发生的次数足够多时，线程池最终就为空，而且系统将停止，因 为没有可用的线程来处理任务。

有些任务可能会永远等待某些资源或来自用户的输入，而这些资源又不能保 证变得可用，用户可能也已经回家了，诸如此类的任务会永久停止，而这些停止 的任务也会引起和线程泄漏同样的问题。如果某个线程被这样一个任务永久地消 耗着，那么它实际上就被从池除去了。对于这样的任务，应该要么只给予它们自 己的线程，要么只让它们等待有限的时间。

请求过载

仅仅是请求就压垮了服务器，这种情况是可能的。在这种情形下，我们可能 不想将每个到来的请求都排队到我们的工作队列，因为排在队列中等待执行的任 务可能会消耗太多的系统资源并引起资源缺乏。在这种情形下决定如何做取决于 您自己；在某些情况下，您可以简单地抛弃请求，依靠更高级别的协议稍后重试 请求，您也可以用一个指出服务器暂时很忙的响应来拒绝请求。

有效使用线程池的准

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!