一.
除了equals方法外，還有其他的方法可以用。
上圖要記住，equals方法不覆蓋，也會有，建立對象特有的比較相同的形式，這很重要(語音不清楚，可能寫的是錯誤的)。
我們以前做過這樣一件事兒，直接打印對象，
編譯的結果是person@61de33，這就是哈希值。這個哈希值是通過哈希算法算出來的，哈希算法到底怎么弄？(打印對象，結果到底指的是什么？哈希值代表的是什么？)
在object類的源代碼中，有hashcode()
這是本地的，換句話說，你要是不做，它用的是系統的(說的這些可能都和native有關)，是由windows幫我們算的。人家在幫你算，在內存中要放在哪兒。其實應該先走虛擬機等等(這里有一塊兒細節，現在沒有談論到，先不管)。這個方法幫我算了一個具體的對象位置存在，這里面涉及數據結構，但是我們還沒學數據結構，沒法講述，所以我們只能說它是個內存地址。
既然說是用hashcode()方法算的，那我們來看看。
注意是將內部地址轉換。
這里面涉及一個轉換動作，java不需要直接調用該方法就行。
接下來開始調用hashcode方法
再將程序修改一下，編譯運行
DOS的結果顯示，輸出p1和p1的hashcode是不一樣的。
Ca0b6是十六進制，827574是十進制。我們現在把十進制轉換為十六進制。
DOS顯示兩者是一樣了，但是為什么不同輸出時，數值在變動呢？
把十進制轉換成十六進制，顯示短一些。
現在進一步進行擴展，對於原有的hashcode不滿意。現在想對人具備的特有數據，來進行哈希值的定義。
覆蓋每個對象原有的hashcode方法，每個人年齡都不一樣，訪問每個人的年齡可不可以？可以，我們以人的年齡來作為哈希值。這么一弄，就變得不一樣了。(對hashcode的修改真是奇怪？如果拋開hashcode特有的觀點，其實方法體里面怎么書寫都無所謂)
修改之后，看原先程序的輸出是怎樣的
DOS結果顯示兩者都是一樣的，(由於程序中已經設置好進制轉換，所以結果肯定都是一樣的，不應該的是十六進制么？)
程序中年齡是20，是十進制，轉換成十六進制就是14。
一句話，哈希值是可以自己來實現的。依據對象的特點不同，我們建立它的不同的地址值，哈希值。
真正比較兩個對象是否相等，看的就是這兩個對象的哈希值是否相等，如果內容也是一樣的，這時才能視為兩個對象是一樣的。判斷equals不行，判斷這個才給力。但是這個得涉及到數據結構，就是哈希表。
Equals方法重寫和地址值有關系么？
光說內容相等不行，還得是哈希值相同。
這塊的知識點，將會在集合框架中應用。