到目前為止，還能保持每天抽出一小時來學習。不過由于時間緊，所以一直沒來得及進行學習記錄，趁著現在有點時間，趕緊補一補

第8條：在改寫equals的時候請遵守通用約定

改寫equals方法看似簡單，但是有許多的改寫方式會導致錯誤，避免問題最容易的方式就是不改寫。那么我們什么時候equals呢？當一個類有自己特有的“ 邏輯相等”概念（不同于對象身份的概念），而且超類也沒有改寫e q u a l s以實現期望的行為，這時我們需要改寫e q u a l s方法。這通常適合于“ 值類（value class ）”的情形，比如I n t e g e r或者date。程序員在利用e q u a l s方法來比較兩個指向值對象的引用的時候，希望知道它們邏輯上是否相等，而不是它們是否指向同一個對象。為了滿足程序員的要求，改寫e q u a l s方法是必需的，而且這樣做也使得這個類的實例可以被用做映射表（ m a p）的鍵（ k e y），或者集合（s e t）的元素，并使映射表或者集合表現出預期的行為。

改寫equals的時候必須遵守它的通用約定：

e q u a l s方法實現了等價關系（ equivalence re l a t i o n）：

?

自反性 （reflexive）。對于任意的引用值x，x.equals(x)一定為true。

?

對稱性 (symmetric).對于任意的引用值x和y，當且僅當y.equals(x)返回true是，x.equals(y)也一定返回true。

?

傳遞性 (transitive)。對于任意的引用值x、y和z，如果x.equals(y)返回true，并且y.equals(z)也返回true，那么x.equals(z)也一定返回true。

?

一致性 (consistent)。對于任意的引用值x和y，如果用于equals比較的對象信息沒有被修改的話，那么，多次地哦啊用x.equals(y)要么一致的返回true，要么一致的返回false。

?

非空性 (nun-nullity)。對于任意的非空引用值x，x.equals(null)一定返回false。

?

第9條：改寫equals時總是要改寫hashCode

?

一個很常見的錯誤根源在于沒有改寫hashCode方法。在每個改寫了equals方法的類中，你必須也要改寫hashCode方法。如果不這樣做的話，就會違反Object.hashCode的通用約定，從而導致該類無法與所有基于散列值（ hash）的集合類結合在一起正常運作，這樣的集合類包括HashMap、HashSet和Hashtable。

?

下面是hashCode約定的內容，來自java.lang.Object的規范：

?

? 在一個應用程序執行期間，如果一個對象的equals方法做比較所用到的信息沒有被修改的話，那么，對該對象調用hashCode方法多次，它必須始終如一地返回同一個整數。在同一個應用程序的多次執行過程中，這個整數可以不同，即這個應用程序這次執行返回的整數與下一次執行返回的整數可以不一致。

?

? 如果兩個對象根據equals (Object)方法是相等的，那么調用這兩個對象中任一個對象的hashCode方法必須產生同樣的整數結果。

?

? 如果兩個對象根據equals(Object)方法是不相等的，那么調用這兩個對象中任一個對象的hashCode方法，不要求必須產生不同的整數結果。然而，程序員應該意識到這樣的事實，對于不相等的對象產生截然不同的整數結果，有可能提高散列表（hash table）的性能。

?

第10條：始終要覆蓋toString

java.lang.Object提供了一個toString方法的實現。它包含類的名稱，以及一個“@”符號，接著是散列碼的無符號十六進制，如“PhoneNumber@163b91”。這個結果通常不是我們想要的，所以toString的通用約定指出“建議所有的子類都覆蓋這個方法”。

?

提供好的toString方法，不僅僅有利于這個類的實例，同樣也利于那些包含這些實例的引用的對象，特別是集合對象。

?

第二天和第三天（第8-10條）