答案是：==比较值或内存地址，equals()比较逻辑内容，重写equals()需遵守五契约并同步重写hashCode()。
==在 Java 里主要比较的是值或内存地址。对于基本数据类型（如
int,
char,
boolean），它比较的是它们实际的数值。但对于对象类型，
==比较的是这两个引用是否指向了内存中的同一个对象实例。而
equals()方法，它的设计初衷就是为了比较两个对象的内容是否逻辑上相等。默认情况下，
Object类里的
equals()实现和
==行为一样，也是比较内存地址，但很多类，比如
String、
Integer等，都重写了这个方法，让它比较对象内部的数据。
说实话，每次讲到
==和
equals()的区别，我总觉得像是在重温 Java 基础的“九阳真经”第一页。但它确实太重要了，因为稍有不慎，就可能踩到坑里，导致程序行为不符合预期。
咱们先从最直观的看。如果你有两个
int变量
a = 5和
b = 5，那么
a == b肯定是
true。这里
==就是老老实实地比对那两个“5”这个数值。没毛病。
但如果换成对象呢？假设我们有
String s1 = new String("hello") 和 String s2 = new String("hello")。这时候 s1 == s2会是
false。为什么？因为
new String()每次都会在堆内存里创建一个全新的
String对象。所以
s1和
s2虽然内容都是 "hello"，但它们是两个不同的对象实例，内存地址不一样。而
==关注的就是这个内存地址。
立即学习“Java免费学习笔记（深入）”；
这时候
equals()就登场了。对于
String类，它早就被重写了，所以
s1.equals(s2)会返回
true。
String类的
equals()不看内存地址，它会逐个字符地比较两个字符串的内容。这才是我们大多数时候希望的“相等”概念，对吧？我们关心的是“你是不是叫张三”，而不是“你是不是坐在我旁边的张三”。
再来个例子，如果你自己写一个
Person类，里面有
name和
age字段。如果你不重写
equals()方法，那么
new Person("Alice", 30) == new Person("Alice", 30) 肯定是 false，甚至
new Person("Alice", 30).equals(new Person("Alice", 30)) 也会是 false。因为默认的
equals()行为就是
==的行为。要让这两个“Alice, 30”在逻辑上相等，你就得手动去重写
equals()，告诉 Java 虚拟机，当
name和
age都一样的时候，这两个
Person对象就算相等。这其实就是赋予了对象“内容相等”的语义。
有时候，我会看到一些新手，甚至是老手，在比较
Integer对象时犯错。比如
Integer i1 = 100; Integer i2 = 100;此时
i1 == i2可能是
true。但
Integer i3 = 200; Integer i4 = 200;此时
i3 == i4却可能是
false。这背后涉及到
Integer的缓存机制（-128到127之间的整数会被缓存）。这种“看脸”的相等性判断，真的让人头疼。所以，对于对象包装类，永远用
equals()才是最稳妥的。
家电小商城网站源码1.0
下载
家电公司网站源码是一个以米拓为核心进行开发的家电商城网站模板，程序采用metinfo5.3.9 UTF8进行编码，软件包含完整栏目与数据。安装方法：解压上传到空间，访问域名进行安装，安装好后，到后台-安全与效率-数据备份还原，恢复好数据后到设置-基本信息和外观-电脑把网站名称什么的改为自己的即可。默认后台账号：admin 密码：132456注意：如本地测试中127.0.0.1无法正常使用，请换成l
总结一下，
==就像是身份证号比对，看是不是同一个人（内存地址）。
equals()则是内容比对，看是不是同一个人（逻辑内容）。理解这个核心差异，基本上就抓住了关键。
重写 equals()
方法时，有哪些“坑”是必须注意的？
重写
equals()绝对不是件小事，它有一套严格的契约，一旦违反，程序行为就可能变得诡异莫测。我见过太多因为
equals()没写对，导致
HashMap、
HashSet行为异常的案例。
最基础的，就是
equals()方法必须满足以下五个特性，这被称为“
equals()契约”：
-
自反性 (Reflexive): 任何非
null
的对象x
，x.equals(x)
必须返回true
。这很直观，自己和自己肯定相等。 -
对称性 (Symmetric): 如果
x.equals(y)
返回true
，那么y.equals(x)
也必须返回true
。这个性质经常被忽略，尤其是在涉及继承的时候。比如，ColorPoint
和Point
，如果ColorPoint
的equals()
只比较x, y
坐标，那么new Point(1,2).equals(new ColorPoint(1,2,Color.RED))
可能会是true
，但反过来new ColorPoint(1,2,Color.RED).equals(new Point(1,2))
却可能因为ColorPoint
内部的color
字段而返回false
，这就违反了对称性。通常的建议是，如果想在子类中添加新的字段，就不要扩展equals()
的行为，而是使用组合（composition）而不是继承。 -
传递性 (Transitive): 如果
x.equals(y)
返回true
，并且y.equals(z)
返回true
，那么x.equals(z)
也必须返回true
。这在多层继承或者复杂对象比较时尤其容易出错。 -
一致性 (Consistent): 如果参与比较的对象信息没有被修改，那么无论调用多少次
x.equals(y)
，结果都应该保持一致。这意味着equals()
的判断逻辑不应该依赖于随机数、当前时间或者网络状态这些不确定的因素。 -
非空性 (Non-nullity): 任何非
null
的对象x
，x.equals(null)
必须返回false
。这是为了避免NullPointerException
，也是一个基本的防御性编程习惯。
除了这五大契约，还有一个非常关键的点：重写 equals()
时，必须同时重写 hashCode()
方法。 这是因为
HashMap、
HashSet等基于散列（hash）的数据结构，都是先通过
hashCode()来快速定位对象的存储位置，再通过
equals()来确认对象是否真的相等。如果两个逻辑上相等的对象有不同的
hashCode，那么它们在
HashMap中就可能被存储在不同的位置，导致
get()方法找不到本应存在的数据。反之，如果
hashCode()相同，
equals()不同，那性能会下降，但至少功能上不会出错。但如果
equals()相同，
hashCode()不同，那就彻底乱套了。
所以，在实现
equals()时，我通常会遵循一个模式：
@Override
public boolean equals(Object o) {
if (this == o) return true; // 自反性，性能优化
if (o == null || getClass() != o.getClass()) return false; // 非空性，类型检查
// 或者用 o instanceof MyClass，但这在继承场景下可能带来对称性问题，getClass() 更严格
MyClass myClass = (MyClass) o;
// 逐一比较关键字段
return field1 == myClass.field1 &&
Objects.equals(field2, myClass.field2) && // 使用 Objects.equals 处理 null 值
// ... 其他字段
;
}
@Override
public int hashCode() {
// 使用 Objects.hash() 方便地生成哈希码，它能处理 null 值
return Objects.hash(field1, field2 /*, ... 其他字段 */);
}这里
Objects.equals()和
Objects.hash()是 Java 7 引入的工具类，它们能很好地处理
null值，避免了手动写
if (field1 != null ? field1.equals(myClass.field1) : myClass.field1 == null)这样的繁琐代码，大大简化了重写过程，也减少了出错的可能。
为什么 String
、Integer
等包装类要重写 equals()
，它们对 HashMap
和 HashSet
有什么影响？
String和
Integer这些类重写
equals()方法，完全是为了符合我们人类对“相等”的直观理解。试想一下，如果两个字符串内容都是 "hello"，但因为它们
