Java 如何强制或预测jstatd的第二个开放端口？

如果要在RMI注册表的特定端口上启动，可以为此传递

-p

参数

但问题是它会打开第二个随机端口（java中称为“匿名端口”），这会导致编写防火墙规则或使用JVisualVM连接到Docker容器中运行的远程

jstatd

的问题

如果您查看，您将看到它正在调用，这将打开一个新的“匿名端口”，它似乎是随机的

---

有没有办法将最后一个端口强制设置为固定端口，或者预测将选择哪个端口？

我发现使用匿名端口无法预测将打开哪个具体端口

但是我发现了一个名为“”的

jstatd重写，它将强制使用
jstatd
使用的3个端口（因为最后，我发现
jstatd
实际上打开了3个端口，而不是我最初认为的2个）

因为我需要控制这些端口，所以这对我来说还不够，所以我写了一篇文章来回答这个问题（以及其他问题），所以现在我可以使用（在ejstatd的文件夹中）控制这些端口：

在这里，将打开的3个端口将是
2222
、
2223
和
2224
，RMI注册表将在端口
2222
处可用，实际上它可能会导致新导出的对象重用以前使用的端口，例如注册表端口，除非存在插座工厂冲突。你有证据吗？还是这个问题只是基于误读？@EJP:我不太理解你的评论。。。我的问题是基于这样一个事实：当启动
jstatd
时，另一个端口被打开（以及RMI注册表端口），如果您不在防火墙规则中转发此端口，那么JVisualVM（例如）将无法访问此远程服务器…@EJP我还可以确认它是一个“匿名端口”在这种情况下，可以通过查看
UnicastRemoteObject.exportObject（Remote obj）
的源代码和文档打开它，它将使用一个
新的UnicastServerRef（true）
调用构造函数中的
this（0）
（因此它将本地端口设置为
0
，称为“匿名端口”）在源文件和文档中的多个位置）。因此，它几乎等同于调用UnicastRemoteObject.exportObject（远程对象，0）

（唯一的区别是

forceStubUse

，它将在

UnicastServerRef

中设置为

false

）@AnthonyO。如果您再深入一点，就会发现端口共享逻辑。就在那里。

mvn exec:java -Dexec.args="-pr 2222 -ph 2223 -pv 2224"