最小化 Java 线程上下文切换开销答案

【问题标题】：Minimizing Java Thread Context Switching Overhead最小化 Java 线程上下文切换开销
【发布时间】：2010-05-28 05:57:39
【问题描述】：

我有一个 Java 应用程序在 Sun 1.6 32 位 VM/Solaris 10 (x86)/Nahelem 8 核（每核 2 个线程）上运行。

应用程序中的一个特定用例是响应一些外部消息。在我的性能测试环境中，当我在接收外部输入的同一线程中准备和发送响应时，与将消息交给单独的线程以发送响应相比，我获得了大约 50 us 的优势。我使用ThreadPoolExecutor 和SynchronousQueue 进行切换。

根据您的经验，在将任务安排到线程池和被拾取执行之间的~~可接受~~预期延迟是多少？过去有哪些想法对您有用，可以尝试改进这一点？

【问题讨论】：

标签： java performance multithreading solaris threadpool

【解决方案1】：

“可接受的延迟”完全取决于您的应用程序。如果您有非常严格的延迟要求，那么在同一线程上处理所有事情确实会有所帮助。幸运的是，大多数应用程序没有那么严格的要求。

当然，如果只有一个线程能够接收请求，那么占用该线程来计算响应将意味着您无法接受任何其他请求。根据您正在做什么，您可以使用异步 IO（等）来避免“每个请求线程”模型，但它在 IMO 中要困难得多，并且仍然会以线程上下文切换结束。

有时将请求排队以避免有太多线程处理它们是合适的：如果您的处理受 CPU 限制，那么拥有数百个线程并没有多大意义 - 最好有一个生产者/消费者队列的任务和将它们分布在每个核心大约一个线程上。如果你设置得当，这基本上就是ThreadPoolExecutor 会做的事情。如果您的请求花费大量时间等待外部服务（包括磁盘，但主要是其他网络服务），那么这也不会奏效......此时，无论何时您可能需要使用异步执行模型内核因阻塞调用而空闲，或者您受到线程上下文切换的影响并拥有大量线程，依靠线程调度程序使其工作得足够好。

底线是延迟要求可能很苛刻 - 根据我的经验，它们比吞吐量要求要严格得多，因为它们更难横向扩展。不过，这确实取决于上下文。

【讨论】：

谢谢！我的意思是“预期”而不是“可接受”。我想知道 50 us 是否太大或是否可以降低。是的，我想尽快释放接收线程以便能够接收下一条消息。此外，我的请求处理受 CPU 限制。

【解决方案2】：

50us 对于切换来说听起来有些高，IME (Solaris 10/Opteron) LBQ 通常在 30-35us 范围内，而 LTQ (LinkedTransferQueue) 比这快大约 5us。正如其他回复中所述，SynchronousQueue 可能会稍微慢一些，因为要等到其他线程被占用后，报价才会返回。

根据我的结果，Solaris 10 在这方面明显比 Linux 慢，它的时间

这真的取决于一些事情，在峰值负载下

您每秒处理多少个请求？
处理请求通常需要多长时间？

如果您知道这些问题的答案，那么从性能的角度来看，您应该在接收线程中处理还是切换到处理线程。

【讨论】：

【解决方案3】：

您是否有理由不使用LinkedBlockingQueue，以便您的生产者可以排队几个项目而不是SynchronousQueue？至少有一个包含 1 个项目的队列，这样您就可以获得更好的并行性。

“准备”过程与“响应”过程的速度是多少？如果响应成本太高，是否可以使用线程池让多个线程处理响应？

【讨论】：

【解决方案4】：

不是同一个任务，而是“是” - 队列通常用于时间关键任务。我们已经集中精力避免同步来处理事件。查看以下提示

不要使用同步容器（数组、列表、映射...）。想想每个线程的容器。
我们使用了循环线程池。该池由预先分配的线程组成，并且（！）恰好一个监听事件出现，没有任何队列。当事件引发时，线程从循环中删除，另一个成为监听器。处理完成后，线程返回池中。

【讨论】：

我不认为为每个传入事件创建一个新线程是最好的方法。我宁愿有一个固定的线程池（甚至可以缩放）来处理由一个或多个侦听器线程放入列表中的传入事件
"...为每个传入事件创建一个新线程是最好的方法" - 你在我的帖子中哪里看到这个，而我写道："...循环线程池"？
哦。我误读了。只看到“删除线程”并认为：“是的，那不好”：p