线程池执行器-java 的优化

Question

我使用线程池执行器，将其替换为旧版线程。

我创建了如下执行器：

pool = new ThreadPoolExecutor(coreSize, size, 0L, TimeUnit.MILLISECONDS,
       new LinkedBlockingQueue<Runnable>(coreSize),
       new CustomThreadFactory(name),
       new CustomRejectionExecutionHandler());
pool.prestartAllCoreThreads();

这里的核心大小是maxpoolsize/5。我已经在应用程序启动时预先启动了所有核心线程，大约160个线程。

在传统设计中，我们创建并启动了大约670个线程。

但关键是，即使在使用Executor并创建和替换遗留设计之后，我们也不会得到更好的结果。

对于结果内存管理，我们使用Top命令来查看内存使用情况。对于时间，我们将System.current时间的记录器以毫秒为单位来检查使用情况。

请说明如何优化此设计。谢谢

Answer 1

执行器只是包装线程的创建/使用，所以它没有做任何神奇的事情。

听起来你在其他地方遇到了瓶颈。您是否锁定了单个对象？您是否有一个每个线程都命中的单线程资源？在这种情况下，您不会看到行为的任何变化。

您的进程是否受CPU限制？如果是这样的话，您的线程应该（非常粗略地说）与可用的处理内核数量相匹配。请注意，您创建的每个线程都会消耗其堆栈的内存，如果您是内存受限的，那么创建多个线程在这里就无济于事了。

Answer 2

但关键是，即使在使用Executor并创建和替换遗留设计之后，我们也不会得到更好的结果。

我假设您正在查看应用程序的总体吞吐量，与在自己的线程中运行每个任务（即不使用池）相比，您没有看到更好的性能？

这听起来就像你没有因为上下文切换而被阻塞。也许你的应用程序是IO绑定的，或者在等待其他系统资源。670线程听起来很多，你会使用很多线程堆栈内存，但除此之外，它可能不会阻碍你的应用程序的性能。

通常我们使用< code>ExecutorService类不一定是因为它们比原始线程快，而是因为代码更容易管理。并发类负责大量的锁定、排队等工作。脱离你的控制。

几个代码注释：

>

我不确定您是否希望LinkedBlockingQueue受到核心大小的限制。这是两个不同的数字。核心大小是池中的最小线程数。BlockingQueue 的大小是有多少作业可以排队等待空闲线程。

顺便说一句，ThreadPoolExecutor 永远不会分配超过核心线程编号的线程，除非 BlockingQueue 已满。在您的情况下，如果所有核心线程都繁忙并且队列已满，核心大小的排队任务数是下一个线程分叉时。

我从来没有用过< code > pool . prestartallcorethreads()；。一旦任务被提交到池中，核心线程就会被启动，所以我不认为这对你有什么好处——至少对一个长时间运行的应用程序来说是这样。

为了时间，我们已经将System.currentTime的记录器放置在millis中以检查使用情况。

对此要小心。过多的记录器对应用程序性能的影响可能大于重新构建应用程序。但我假设您在没有看到性能改进后添加了记录器。