Yes. No difference toot again == and equals to forget
== more basic type of number is the value of time than the comparison of reference types when comparing address. equals more basic types of time. . . .
The answer on this question in mind a good fuzzy good insecure
But please believe, after reading this article toot guaranteed to make you remember at least a year. I remember one year I lost count.
== first number is the design of java initially good people, it is impossible to change, not to mention the first sentence is well understood. Hard to remember it.
As some people say is how relatively basic types (that is, about the constant pool, heap memory piece things) after the beep destined to study it further. After all, the purpose-oriented programming is the primary goal of Dudu now.
Then we Chou Chou equals the ratio is how
First of equals can not be more basic types
Basic types on the left? ? nonexistent. If you write basic types .equals compiler error I do not live to eat fruits.
Basic types on the right? ? This is acceptable. Because toot just tried. No error. And when debug parameters found on the right side of the equals I wrote a 1, then do not know whom to automatically packaged into the Integer class.
So equals still can not compare basic types.
equals comparison of reference types than how
This issue needs to be traced back to the father million class Object class above. Object class which has a equals method, should be regarded as the father of all the equals method.
Yes, Object class equals method which should be regarded as the most primitive method of equals, than is the address.
Then we find a few other classes to look at other classes override the equals method is how to compare
equals method 1.String class:
也就是说String 根据自己的需要（String认为什么样的比较算是两个字符串相等）重新写了equals方法。那么什么样的两个字符串才算相等呢？上面代码很明显。（1）如果地址一样，那就是相等 （2）要是地址不相等的话：如果比较的那个对象也属于String类，我就比一下两个String对象的长度。如果长度相等，我就逐个比较每一个字符。都相等？？好吧。勉强算你们两个相等了。
2.咱们再看看HashMap的源代码里面是怎么定义两个HashMap相同的
上图是AbstractMap.class的equals方法嘟嘟debug了一下也证明了走的是这个equals方法
比较过程简单说一下
（1）.上来先比个地址，如果地址一样，就根本不用继续往下比了。
（2） 如果比较的那个对象不属于Map这个类，那也不用继续往下比了。（这里嘟嘟先留个伏笔，后边有好玩的）
（3）如果你属于Map这个类，行，咱们比比大小吧。大小一样的话可以继续往下比
（4）到了这一步。我先将自己转化为一个一个键值对的迭代器，然后我把我的key先拿出来，问你有没有，什么？你没有？对不起，我们不合适，我们不相等。什么？你有？那你那边对应的key的value值跟我这边的一样吗？不一样？对不起，我们不合适，我们不相等。
如果上诉的条件我们都相等，我们就相等。
但是嘟嘟当时有个疑问？就是为什么上面源代码里面判断的是该对象是否属于Map类而不是按照HashMap LinkedHashMap等按照更细化的类型比较？？
然后嘟嘟就做了个简单的验证：
结论就是。Map家族的设计者认为：如果两个Map对象地址不同，那只要你们键值对都一样，那我就认为你们相同，我也不管你是HashMap还是LinkedHashMap了。
进而嘟嘟有个疑问。equals方法其实是设计者们在考虑 “怎么样才算是相等” 之后，重写的Object 里面的equals 方法。那嘟嘟自己随便瞎重写一个equals方法不是也行么？？嘟嘟自己尝试了（嘟嘟随便定义了一个类A ，重写了里面的equals方法，只要比较的那个对象属于String类型就算他俩相等），还特么真行。但是嘟嘟不敢保证以后你瞎写一个equals方法你项目经理打不打你。
所以嘟嘟下面要说的就是重写equals方法要遵守的几个原则
1.自反性:自己跟自己比一定要相等。像嘟嘟自己写的那个就不相等。
2. 对称性:a.equals(b)和b.equals(a)必须返回的是同结果。（HashMap和LinkedHashMap对象相互比较的时候也是满足对称性的，因为HashMap和linkedHashMap的equals方法用的都是AbstractMap的）
3.传递性：a等于b，b等于c，那么a也等于c
4.一致性：如果a和b没改变，多次调用equals方法得到的结果相同
大总结：
==号基本类型比较数值，引用类型比较地址
equals 如果是Object类的equals 比较的就是地址（用的==号啊）
但是不同的类，可能重新写了自己的equals方法（这里举一个String的一个Map就行了吧）
但是equals 在设计的时候要遵守4个原则 （自反，对称，传递，一致）