==:
==是直接比較的兩個(gè)對(duì)象的堆內(nèi)存地址劝赔，如果相等豌骏，則說(shuō)明這兩個(gè)引用實(shí)際是指向同一個(gè)對(duì)象地址的琅翻。但是我們又常常碰到這樣一個(gè)問(wèn)題:
最終結(jié)果是 true，true晒杈，false嫂伞，那既然==是比較的地址，那么int數(shù)據(jù)的地址是怎樣的呢桐智，String又是怎樣的呢末早？
對(duì)于基本數(shù)據(jù)類型（byte，short说庭，char然磷，int，float刊驴，double姿搜，long寡润，boolean）來(lái)說(shuō)，他們是作為常量在方法區(qū)中的常量池里面以HashSet策略存儲(chǔ)起來(lái)的舅柜，對(duì)于這樣的字符串 "123" 也是相同的道理梭纹，在常量池中，一個(gè)常量只會(huì)對(duì)應(yīng)一個(gè)地址致份，因此不管是再多的 123,"123" 這樣的數(shù)據(jù)都只會(huì)存儲(chǔ)一個(gè)地址变抽，所以所有他們的引用都是指向的同一塊地址，因此基本數(shù)據(jù)類型和String常量是可以直接通過(guò)==來(lái)直接比較的氮块。其實(shí)常量池是為了避免頻繁的創(chuàng)建和銷毀對(duì)象而影響系統(tǒng)性能绍载，其實(shí)現(xiàn)了對(duì)象的共享。
例如字符串常量池滔蝉，在編譯階段就把所有的字符串文字放到一個(gè)常量池中击儡。
（1）節(jié)省內(nèi)存空間：常量池中所有相同的字符串常量被合并，只占用一個(gè)空間蝠引。
（2）節(jié)省運(yùn)行時(shí)間：比較字符串時(shí)阳谍，==比equals()快。對(duì)于兩個(gè)引用變量螃概，只用==判斷引用是否相等矫夯，也就可以判斷實(shí)際值是否相等。
下面再舉一個(gè)例子：
String s1 = "Hello";
String s2 = "Hello";
String s3 = "Hel" + "lo";
String s4 = "Hel" + new String("lo");
String s5 = new String("Hello");
String s7 = "H";
String s8 = "ello";
String s9 = s7 + s8;
System.out.println(s1 == s2); // true
System.out.println(s1 == s3); // true
System.out.println(s1 == s4); // false
System.out.println(s1 == s9); // false
System.out.println(s4 == s5); // false
1.s1 == s2這個(gè)非常好理解谅年，s1茧痒、s2在賦值時(shí)，均使用的字符串字面量融蹂，說(shuō)白話點(diǎn)旺订，就是直接把字符串寫死，在編譯期間超燃，這種字面量會(huì)直接放入class文件的常量池中区拳，從而實(shí)現(xiàn)復(fù)用，載入運(yùn)行時(shí)常量池后意乓，s1樱调、s2指向的是同一個(gè)內(nèi)存地址，所以相等届良。
2.s1 == s3這個(gè)地方有個(gè)坑笆凌，s3雖然是動(dòng)態(tài)拼接出來(lái)的字符串，但是所有參與拼接的部分都是已知的字面量士葫，在編譯期間乞而，這種拼接會(huì)被優(yōu)化，編譯器直接幫你拼好慢显，因此String s3 = "Hel" + "lo";在class文件中被優(yōu)化成String s3 = "Hello"爪模，所以s1 == s3成立欠啤。只有使用引號(hào)包含文本的方式創(chuàng)建的String對(duì)象之間使用“+”連接產(chǎn)生的新對(duì)象才會(huì)被加入字符串池中。
3.s1 == s4當(dāng)然不相等屋灌，s4雖然也是拼接出來(lái)的洁段，但new String("lo")這部分不是已知字面量，是一個(gè)不可預(yù)料的部分共郭，編譯器不會(huì)優(yōu)化祠丝，必須等到運(yùn)行時(shí)才可以確定結(jié)果，結(jié)合字符串不變定理落塑，鬼知道s4被分配到哪去了纽疟，所以地址肯定不同。對(duì)于所有包含new方式新建對(duì)象（包括null）的“+”連接表達(dá)式憾赁，它所產(chǎn)生的新對(duì)象都不會(huì)被加入字符串池中。
而在某些特別情況下散吵， String 對(duì)象的字符串拼接其實(shí)是被 JVM 解釋成了 StringBuffer 對(duì)象的拼接龙考，所以這些時(shí)候 String 對(duì)象的速度并不會(huì)比 StringBuffer 對(duì)象慢，而特別是以下的字符串對(duì)象生成中矾睦， String 效率是遠(yuǎn)要比 StringBuffer 快的：
String S1 = "This is only a" + " simple" + " test";
StringBuffer Sb = new StringBuffer("This is only a").append(" simple").append(" test");
你會(huì)很驚訝的發(fā)現(xiàn)晦款，生成 String S1 對(duì)象的速度簡(jiǎn)直太快了，而這個(gè)時(shí)候 StringBuffer 居然速度上根本一點(diǎn)都不占優(yōu)勢(shì)枚冗。其實(shí)這是 JVM 的一個(gè)把戲缓溅，在 JVM 眼里，這個(gè)
String S1 = “This is only a” + “ simple” + “test”; 其實(shí)就是：
String S1 = “This is only a simple test”;
所以當(dāng)然不需要太多的時(shí)間了赁温。但大家這里要注意的是坛怪，如果你的字符串是來(lái)自另外的 String 對(duì)象的話，速度就沒(méi)那么快了股囊，譬如：
String S2 = “This is only a”;
String S3 = “ simple”;
String S4 = “ test”;
String S1 = S2 +S3 + S4;
這時(shí)候 JVM 會(huì)規(guī)規(guī)矩矩的按照原來(lái)的方式去做
具體可以參考：https://www.cnblogs.com/syp172654682/p/8082625.html
另外袜匿，對(duì)于基本數(shù)據(jù)的包裝類型（Byte, Short, Character，Integer稚疹，F(xiàn)loat, Double居灯，Long, Boolean）除了Float和Double之外，其他的六種都是實(shí)現(xiàn)了常量池的内狗，因此對(duì)于這些數(shù)據(jù)類型而言怪嫌，一般我們也可以直接通過(guò)==來(lái)判斷是否相等。
equals：
equals在eclipse自動(dòng)生成的一種方法：
可以看出柳沙，eclipse還是很智能的岩灭，它首先是判斷兩個(gè)對(duì)象的地址是否相等，若不相等再進(jìn)行下面的成員變量判斷偎行。
但這個(gè)方法體是完全可以由我們自己實(shí)現(xiàn)的川背，即便是我們直接 return true 都是可以的贰拿，只要能滿足我們的業(yè)務(wù)需求，怎樣寫都是無(wú)所謂的熄云，因此膨更，equals比較的并不一定是對(duì)象的內(nèi)容，它還可以由其他的信息來(lái)指導(dǎo)比較缴允。
參考：https://blog.csdn.net/lcsy000/article/details/82782864
和http://www.reibang.com/p/b1b75fdd5dec
文章有不當(dāng)之處請(qǐng)?zhí)岢霎愖h荚守。
