为啥 VisualVM 为 VisualVM 本身运行 50 个线程？

Posted 2023-03-06

【中文标题】为啥 VisualVM 为 VisualVM 本身运行 50 个线程？

【英文标题】：Why is VisualVM running 50 threads for VisualVM itself?为什么 VisualVM 为 VisualVM 本身运行 50 个线程？

【发布时间】：2017-09-17 19:48:50

【问题描述】：

更新

提出这个问题的另一种方式是“应用程序可用的线程数是否比内核数多？”。

原始问题

我的笔记本电脑上共有 8 个内核。我刚刚下载了最新版本的 VisualVM 并单击了VisualVM 选项卡以查看它的性能。我注意到的一件事是它使用了 32 个活动线程和 22 个守护线程。为什么用了这么多？使用超过 8 个的 IIUC 效率较低，而 IIUC JVM 知道我有多少个内核，因此它可以将线程总数限制为 8 个。

有人将此标记为重复，所以我会尝试解释一下我的要求有所不同。我不是在问如何使用 VisualVM 的特定功能。我在问为什么它运行超过 8 个线程，因为超过 8 个的 IIUC 将不是最佳的，而 VisualVM 来自 Oracle，所以我认为他们会将其设计为以最佳方式运行，所以我想知道我是否遗漏了什么，还是 Oracle 只是允许它运行比它应该运行的线程更多的线程？

【问题讨论】：

Limiting Profiling in Visual VM的可能重复

"Profiled 线程数限制.. 总是 32" blogs.oracle.com/nbprofiler/profiling-with-visualvm,-part-2

【参考方案1】：

仅仅因为您有 50 个 VisualVM 线程正在运行，并不一定意味着所有这些线程都应该同时活跃地工作。如果按“正在运行”列排序，您会看到只有前 7 或 8 个线程在积极运行。其余线程正在休眠或等待 I/O。

【讨论】：

一个回答说 what 额外的线程在做什么会更有帮助：“等待 I/O”的方向是正确的，但仍然含糊不清。

您的回答是有道理的——但根据我目前对如何设计并发 Java 解决方案的理解，这对我来说仍然是一个设计缺陷。自从甲骨文做了这个，我想知道他们是否知道我不知道的事情。特别是我想知道为什么他们不只是在这种情况下为整个应用程序使用最多 8 个线程的共享执行器池 - 做他们正在做的事情有什么好处吗？

线程数多于内核数并没有错。事实上，这是一种标准做法，不仅适用于 Oracle。优点是，就像我说的，当一个 CPU 内核因为该线程当前正在等待 I/O 或其他原因而空闲时，它仍然可以处理另一个线程而不是闲置。

这个逻辑是有道理的。例如，如果我们正在发出一百个异步休息请求并等待缓慢的响应，那么我们不妨为每个请求分配一个异步线程并并行处理所有请求。

假设我有 2 个内核和 2 个线程，看起来略有不同。其中一个线程忙于计算斐波那契数，而另一个线程正在等待也在同一台机器上执行的数据库操作。在这种情况下，数据库可能正在使用另一个核心，因此在这种情况下拥有例如 4 个线程可能会导致过多的上下文切换，所以最后看来这是必须调整的东西......？跨度>