Java Magic. Part 1: java.net.URL

@(Base)[JDK, url, magic, 黑魔法]

英文原文

转载请写明：原文地址

系列文章：

-Java Magic. Part 1: java.net.URL

-Java Magic. Part 2: 0xCAFEBABE

-Java Magic. Part 3: Finally

-Java Magic. Part 4: sun.misc.Unsafe

废话不多说，首先我们看如下代码：

HashSet set = new HashSet();

set.add(new URL("http://google.com"));

set.contains(new URL("http://google.com"));

Thread.sleep(60000);

set.contains(new URL("http://google.com"));

代码的第3行和第5行分别会输出什么呢？

当然不会是true, 如果是true的话，这篇文章也就不会有java黑魔法的后缀了。简单地说吧，当你有运行的PC有网络链接的时候，返回结果是false。如果你关掉你的网络链接，比如wi-if，那么该段程序的返回值就是true。

这么奇葩的直接原因就是URL类的hashCode()和equals()方法的实现。

下面是hashCode()方法：

public synchronized int hashCode() {

  if (hashCode != -1)

    return hashCode;

  hashCode = handler.hashCode(this);

  return hashCode;

}

值得注意的是，URL是一个immutable的对象。

我们可以显然看到这个URL的hashCode值是一个私有域。也就是说，只会计算一次。什么是代码中提到的handler呢？它其实是URLStreamHandler的子类，具体的类型和当前的网络协议类型（file,http,ftp）有着密不可分的关系。我们可以看看URL.hashCode()方法上面的注释：

The hash code is based upon all the URL components relevant for URL comparison. As such, this operation is a blocking operation.

翻译过来就是：hash code的计算和URL的所有相关属性都有关系。例如，这个操作是不是blocking的。

WTF，BLOCKING OPERATION?!

好了这个事情我们暂时放一边。另外这个hashCode的计算奇葩的地方在于，这个handler竟然会解析ip地址参与计算。我们拿这个google.com为例子。当host的ip是动态的时候，或者说有一个域名解析的负载均衡的时候，这个hashCode()方法就会针对google.com计算出两个完全不同的hashCode值。

其实最让人无法接受的是URLStreamHandler会开启一个URLConnection，当然这又是另外一个话题啦。

How to avoid this?