最近发现 == 和equals 成了恒久的问题。无论面试还是一些书上,博客上都能看到它的出现。可能是我想的简单了,如果是这样那我应该做出反思,所以有了这篇博客。
我认为 == 和 equals 从本质上是没有关系的,只是语义上有些相似。如果equal 不是用作” 相等的, 同样的, 平等的”的含义,我想可能会有另一个单词与==扯上关系。
在Java中,当我们要比较两个东西的时候是否相等的时候只能用关系运算符去操作，，== 是关系运算符,而equals是一个方法,仅此而已。
Java里有基本类型,和引用类型(或对象类型)。当我们用基本类型做比较时,是可以直接用==操作的,而且结果肯定也是正确的。当然引用类型肯定也是可以用==操作的,因为引用它是一个地址,地址也是一个值。这是毋庸置疑的。但是当我们要以某个对象的某个属性为参照物进行比较时,那么==只能判断两者是否是同一地址,也就是说两者是否为同一个对象。由于封装性,类的属性正常情况下是private修饰的。方法从一定角度可以看做类的接口。所以当我们以某个对象的某个属性为参照物进行比较时,应该实现一个方法,方法的内部由关系运算符进行属性比较。这可能也是equals方法的由来。从某一方面来看由于equals的使用率的确很高,所以Object默认实现了equals方法。
如果类不重写Object的equals方法,那么比较时默认是Object类的equals方法,通过Object 类equals方法的源码可以看到
public boolean equals(Object obj) {return (this == obj);}
默认是 == 比较。如果需要用对象的属性为参照物,应该自己实现equals方法,当然eclipse已经提供了快捷方式。
String 在 ==和equals的关系中出现率也是相当之高。String是一个特殊的对象,JAVA对它似乎也是很关照。我所知道的String在进行+= 时编译器会进行重载……这是一个值得总结的问题。
通过源码可以看到String类是用final修饰的。也就是不可变的,所以String字符串是一个常量(String 字符串的值是常量不是String 对象的引用)。在JVM中有个专门用于存储常量的地方,叫常量池。由于String使用频率很高,所以从一定程度上看, JAVA把String使用final修饰,是为了节省内存。
通过内存图我想应该很好看出在String 在内存中的分配情况,自然==和equals的关系就清楚了。
case 1 :
String a = “abc”;String b = “abc”;
a 和 b 指向同一内存。所以a 和 b 的引用地址也是一样的。那么用== 返回true。
再看String 的 equals 方法源码:
public boolean equals(Object anObject) {if (this == anObject) { //首先会进行 == 比较return true;}if (anObject instanceof String) {String anotherString = (String)anObject;int n = count;if (n == anotherString.count) {char v1[] = value;char v2[] = anotherString.value;int i = offset;int j = anotherString.offset;while (n– != 0) {if (v1[i++] != v2[j++])return false;}return true;}}return false;}
String 的 equals方法首先会进行 == 比较, 所以 a 和 b 用 equals方法进行比较也是返回 true。case 2 :
String a = new String(“abc”);String b = new String(“abc”);
a 和 b 分配了两块内存,所以 a 和 b 的引用地址肯定是不同的。所以用 == 返回false。通过上面String类的equals源码可以看到,如果 a 和 b 的引用不同,会进行值比较。而 a 和 b 内存块都指向常量池里的abc。所以用 equals 方法比较会返回 true。 这里 a 和 b 内存块里面是如何分配或者是如何实现的,我一直没能理解。关于JVM内存的书,有一本《深入java虚拟机》之前用电子书大致的看了一些章节,很多地方都没能理解。而且这本书又绝版了,实在可惜。还有一本《深入理解Java虚拟机》,在书城看了内存结构这一章,似乎也不是很深入。看来虚拟机这块还需要努力。
旅行，有一种苍凉，“浮云游子意，落日故人情”，
