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

在批处理应用中，线程是在创建线程池时分配(如果将最大线程数和最小线程数设置为同一个值，就会出现这种情况)，还是按需分配，并不重要：执行应用所需的时间是一样的。在其他应用中，新线程可能会在预热阶段分配(分配线程的总时间还是一样的)，对性能的影响可以忽略不计。即使线程创建发生在可以测量的周期内，只要此类操作有限，也很有可能测不出来。

另一个可以调优的地方是线程的空闲时间。比如，某个线程池的最小线程数为 1，最大线程数为 4。现在假设一般会有一个线程在执行，处理一个任务;然后应用进入这样一个循环：每 15 秒，负载平均有 2 个任务要执行。第一次进入这个循环时，线程池会创建第 2 个线程，此时，让这个新创建的线程在池中至少留存一段时间是有意义的。我们希望避免这种情况：第 2 个线程创建出来后，5 秒钟内结束其任务，空闲 5 秒，然后退出了。而 5 秒之后又需要为下一个任务创建一个线程。一般而言，对于线程数为最小值的线程池，一个新线程一旦创建出来，至少应该留存几分钟，以处理任何负载飙升。如果任务到达率有个比较好的模型，可以基于这个模型设置空闲时间。另外，空闲时间应该以分钟计，而且至少在 10 分钟到 30 分钟之间。

留存一些空闲线程，对应用性能的影响通常微乎其微。一般而言，线程对象本身不会占用大量的堆空间。除非线程保持了大量的线程局部存储，或者线程的 Runnable 对象引用了大量内存。不管是哪种情况，释放这样的线程都会显著减少堆中的活数据(这反过来又会影响 GC 的效率)。

不过对线程池而言，这些情况并不多见。当池中的某个对象空闲时，它就不应该再引用任何 Runnable 对象(如果引用了，就说明哪个地方有 bug 了)。根据线程池的实现情况，线程局部变量可能会继续保留;尽管在某些情况下，线程局部变量可以有效促成对象重用，但是那些线程局部对象所占用的总的内存量，应该加以限制。

对于可能会增长到非常大(当然也是运行在规模很大的机器上)的线程池，这个规则有个重要的特例。举例而言，假设某个线程池的任务队列预计平均有 20 个任务，那么 20 就是很好的最小值。再假设这个池运行在一个规模很大的机器上，它被设计为可以处理 2000 个任务的峰值负载。如果在池中留存 2000 个空闲线程，则当只有 20 个任务时，对性能会有所影响：如果只有核心的 20 个线程忙碌，与有 1980 个空闲线程相比，前者的吞吐量可能是后者的 50%。线程池一般不会遇到这样的问题，但如果遇到了，那就应该确认一下池的合适的最小值了。

线程池任务大小

等待线程池来执行的任务会被保存到某类队列或列表中;当池中有线程可以执行任务时，就从队列中拉出一个。这会导致不均衡：队列中任务的数量有可能变得非常大。如果队列太大，其中的任务就必须等待很长时间，直到前面的任务执行完毕。例如一个超负荷的 Web 服务器：如果有个任务被添加到队列中，但是没有在 3 秒钟内执行，那用户很可能就去看另一个页面了。

（编辑：西安站长网）

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