java - 为什么 java.net.URL 的哈希码会将主机解析为 IP？

Question

第一个解决方案之后的想法是依赖操作系统缓存吗？这仍然看起来效率低下，并且在多个域解析到同一 IP 的情况下，不正确。我错过了什么？

Answer 1

Why does java.net.URL’s hashcode resolve the host to an IP?

有两个原因。第一个是:

• URL 类的行为旨在将 URL 建模为网络可访问资源的定位器。具体来说，equals 和 hashCode() 的设计使得两个 URL 实例在定位相同资源时是相等的。这要求将 DNS 名称解析为 IP 地址。

事后看来，我们知道以下内容:

1. URL.equals 方法不能¹ 可靠地确定两个 URL 字符串是否是同一资源的定位器。原因包括虚拟主机、HTTP 30x 转发、URL 的服务器内部映射等。

2. URL.equals 和 URL.hashcode 的 IP 解析行为对于没有经验的 Java 程序员来说是一个陷阱，尽管它有明确的文档记录。

3. 即使在导致正确答案的情况下，URL.equals 的 IP 解析也可能会导致意外(和不希望的)性能下降。

简而言之……URL 的设计是一个错误。

这给我们带来了第二个更重要的原因。

• URL.equals(Object) 的行为是很久以前定义的，现在不可能在不破坏(可能)数百万已部署的 Java 应用程序的情况下进行更改。这排除了 Sun(现在的 Oracle)改变它的任何可能性。

也许 Java 类库的(假设的)后继者的设计者可以解决这个(和其他问题)。当然，与现有 Java 程序的向后兼容性必须被抛到窗外才能实现这一点。

最后，对于 Java 应用程序开发人员来说，真正的答案是简单地使用 URI 类。 (真正的软件工程是尽可能地完成工作，而不是提示提供给您的工具。)

---

^{1 - 当我在上面说“不能”时，我的意思是这在理论上是不可能的。处理一些更困难的情况需要更改 HTTP 协议(protocol)。即使 HTTP 的某些(假设的) future 版本“修复”了这个问题，我们在 20 年后仍然要处理遗留的 HTTP 服务器......因此 URL.equals 仍然会被破坏.}