为何服务器QPS上不去？Java线程调优权威指南

这个例子看上去可能有点有意为之。如果服务器已经是 CPU 密集型的，谁还会加入更多线程呢?之所以使用这个例子，只是因为它容易理解，而且仅使用了 Java 程序。这意味着读者自己就可以运行，并理解它是如何工作的，而不必设置数据库连接、模式(Schema)等选项。

需要指出的是，对于还要向 CPU 密集型或 I/O 密集型的机器发送数据库请求的应用服务器而言，同样的原则也成立。你可能只关注应用服务器 CPU，看到小于 100% 就感觉不错;看到有多余的请求要处理，就假定增加应用服务器的线程数是个不错的主意。结果会让人大吃一惊，因为在那种情况下增加线程数，实际上会降低整体吞吐量(影响可能非常明显)，就像前面那个只有 Java 程序的例子一样。

了解系统真正瓶颈之所在非常重要的另一个原因是：

• 如果还向瓶颈处增加负载，性能会显著下降。
• 相反，如果减少了当前瓶颈处的负载，性能可能会上升。

这也是设计自我调优的线程池非常困难的原因所在。线程池通常对挂起了多少工作有所了解，甚至有多少 CPU 可用也可以知道，但是它们通常看不到所在的整个环境的其他方面。因此，当有工作挂起时，增加线程(这是很多自我调优的线程池的一个核心特性，也是 ThreadPoolExecutor 的某些配置)往往是完全错误的。

遗憾的是，设置最大线程数更像是艺术而非科学，原因也在于此。在现实中，测试条件下自我调优的线程池会实现可能性能的 80%~90%;而且就算高估了所需线程数，也可能只有很小的损失。但是当设置线程数大小这方面出了问题时，系统可能会在很大程度上出现问题。就此而言，充足的测试仍然非常关键。

设置最小线程数

一旦确定了线程池的最大线程数，就该确定所需的最小线程数了。大部分情况下，开发者会直截了当地将它们设置为同一个值。

将最小线程数设置为其他某个值(比如 1)，出发点是防止系统创建太多线程，以节省系统资源。因为每个线程都需要一定量的内存，特别是线程的栈。根据一般原则之一，所设置的系统大小应该能够处理预期的最大吞吐量，而要达到最大吞吐量，系统将需要创建所有那些线程。如果系统做不到这一点，那选择一个最小线程数也没什么帮助：如果系统达到了这样的条件——需要按所设置的最大线程数启动所有线程，而又无法满足，系统将陷入困境。创建最终可能会需要的所有线程，并确保系统可以处理预期的最大负载，这样更好。

另一方面，指定一个最小线程数的负面影响相当小。如果进程一启动就有很多任务要执行，会有负面影响：这时线程池需要创建新线程才能处理任务。创建线程对性能不利，这也是为什么起初需要线程池的原因，不过这种一次性的成本在性能测试中很可能察觉不到。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!