为什么在使用 VisualVM 监视 JVM 堆大小时，应用程序中的内存分配速率会根据网络设置而变化？

问：

环境：我正在使用 VisualVM IntelliJ 插件来调查我在本地运行的标准 OpenJDK Java 8 服务中的内存泄漏，我相信我解决了应用程序错误。

问题：但是，在我的本地验证工作中，由于我让服务运行了很长时间，发现每当我在保持监控运行的同时连接到公司的 VPN 时，都可以在堆大小随时间变化的图表中观察到，当我的笔记本电脑连接到 VPN 时，垃圾回收器触发之间的时间大大延长。就好像 VisualVM 减少了一些轮询间隔，这通常会导致应用程序更快地分配内存。然后，当我关闭 VPN 时，情况恰恰相反，它又回到了之前的原始分配/GC 触发率。为什么会这样？一定与JMX和网络有一些关系，我遗漏了，到目前为止似乎找不到任何解释。

我尝试过几次连接和断开 VPN，每次都注意到相同的行为模式。考虑到 VisualVM 中的本地连接使用 127.0.0.1 的事实，当网络没有发生更改的可辨别特征时，我希望它不会根据本地网络而有所不同，这些特征应该会影响由于 VisualVM 轮询而导致的内存分配速率......但如果是这种情况，我一定错过了什么。应该注意的是，我的 LAN 网络确实支持 IPv6，因此在连接到 VPN 之前，LAN 上同时存在 IPv6 和 IPv4 地址。但是我没有证据表明在任何给定时间，除了“本地”连接的属性中可见的内容，它只显示 127.0.0.1。

另一件需要注意的事情是，从第一次连接到 VPN 时开始，VisualVM 的 Sampler 选项卡中的内存和 CPU 采样选项停止更新并拒绝工作，尽管进行了几次不同的尝试，但“监控”选项卡仍在继续更新，即使在我通过禁用 VPN 将网络恢复到原始设置之后也是如此。

关闭 VisualVM 中的连接并为整个应用程序重新打开它会导致在 VPN 上的所有内容都处于空白状态，就好像它无法连接一样。但是，如果我停止 VPN 并重新打开与应用程序的连接，一切都会按预期工作。在JMX的引擎盖下发生了什么可能导致这种情况？JConsole/JMC 也观察到了类似的问题，正如我在一年多前这个完全独立的主题中解释的那样，但是在这种情况下，我从未尝试保持连接并查看它是否在连接到 VPN 后继续更新 - 显然，在 VisualVM 的情况下，Monitor 选项卡能够......但这怎么可能呢？

鉴于这个VPN-LAN配置问题的其他事实，这似乎非常可疑，我最初的问题应该修改为也问“VisualVM如何在VPN上保持连接，而在VPN上似乎不应该由于这种VPN配置而保持连接？是否使用单独的连接/协议来获取该信息？但是，为什么当我在已经连接到 VPN 的情况下打开与应用程序的连接时，“监控”选项卡不起作用，而当我在首次打开连接后打开 VPN 时，它继续工作？这似乎是不一致的行为。