Linux多IP环境下Java RMI绑定IP规则及客户端连接配置问题

你遇到的lookup阶段卡住问题，核心原因是RMI通信分为两个独立阶段：第一阶段客户端连接1099端口访问RMI注册表，拿到远程服务的stub代理对象；第二阶段客户端会根据stub里内嵌的服务端IP，直接连接远程服务的实际通信端口。你当前场景中stub写入的是客户端不可达的10段内网IP，导致第二阶段连接阻塞。

三个疑问的明确解答 #

1. 调用LocateRegistry.createRegistry(1099)的绑定规则 #

• 仅传入端口参数时，该方法会将RMI注册表绑定到0.0.0.0地址，即监听服务器所有网卡的1099端口，不会绑定到某一个单独IP。只要客户端到服务器1099端口网络连通，访问注册表本身不会出现问题。
• 注意：注册表的监听地址，和后续远程服务stub中携带的服务IP是两个独立配置，不要混淆。

2. 调用registry.rebind(serviceName, service)的IP选择规则 #

• 这是故障的核心来源：远程服务对象导出时（无论是继承UnicastRemoteObject隐式导出，还是调用导出方法显式导出），如果没有手动指定对外服务IP，RMI会默认使用服务器主机名（hostname命令返回值）解析得到的IP，也就是hostname -i返回的地址，将这个IP写入返回给客户端的stub对象中。
• 你的场景中主机名解析到的是10.162.107.99这个客户端不可达的内网地址，客户端拿到stub后会主动尝试连接这个IP的随机服务端口，自然会卡住超时。
• 即使注册表监听在所有网卡上，rebind过程也不会自动使用客户端连接注册表时的来源IP作为服务IP，默认始终取主机名解析结果。

3. LocateRegistry.getRegistry(ip, 1099)的IP传参规则 #

• 该方法传入的IP仅用于第一阶段连接RMI注册表，只要传入客户端能正常访问服务器1099端口的IP即可，比如你场景中的172.16.5.199，这一阶段本身可以正常连通。
• 但仅传对这个IP无法解决连接问题：第二阶段连接实际远程服务时，客户端完全以stub中内嵌的服务端IP为准，只要这个IP客户端不可达，哪怕注册表连接成功，lookup完成后发起服务调用时依然会卡住或报连接错误。

可落地的解决方案 #

• 方案1（成本最低，无需修改代码和服务器配置）：在服务端JVM启动参数中添加配置，强制指定RMI对外服务的IP：

  java -Djava.rmi.server.hostname=172.16.5.199 -jar 你的服务端程序.jar
  

  该参数会强制所有RMI导出的远程对象（包括注册表、自定义业务服务）在生成stub时，将IP写为你指定的可达IP，客户端拿到stub后会直接访问这个可达地址。
• 方案2：修改服务端/etc/hosts文件，将服务器主机名（即hostname命令返回的iZbp124z80qrl3rd8pk42xZ）的解析地址改为对外暴露的可达IP172.16.5.199，让RMI默认解析主机名时能拿到正确地址。
• 方案3：代码中导出远程服务对象时，手动指定绑定的IP和固定服务端口，绕开默认的主机名解析逻辑。

补充提示：如果服务端开了防火墙，除了开放1099注册表端口外，要么在导出远程服务时手动指定固定的服务端口并在防火墙放行，要么配置RMI固定端口范围并放开对应段，否则IP配置正确也可能因为端口被拦截导致连接失败。

内容的提问来源于stack exchange，提问作者SJZ