java內(nèi)存堆和棧深入-資料下載頁
2025-08-18 16:23本頁面
【正文】 須是獨(dú)特的元對(duì)象）。這個(gè)例子說明一個(gè)元對(duì)象可以和其他不同的元對(duì)象擁有相同的hashCode。但是一個(gè) 元對(duì)象只能和擁有同樣內(nèi)容的元對(duì)象相等。所以這兩個(gè)規(guī)則必須成立。設(shè)計(jì)這兩個(gè)函數(shù)所要注意到的：如果你設(shè)計(jì)的對(duì)象類型并不使用于收集性對(duì)象，那么沒有必要自己再設(shè)計(jì)這兩個(gè)函數(shù)的處理方式。這是正確的面向?qū)ο笤O(shè)計(jì)方法，任何用戶一時(shí)用不到的功能，就先不要設(shè)計(jì)，以免給日后功能擴(kuò)展帶來麻煩。如果你在設(shè)計(jì)時(shí)想別出心裁，不遵守以上的兩套規(guī)則，那么勸你還是不要做這樣想入非非的事。我還沒有遇到過哪一個(gè)開發(fā)者和我說設(shè)計(jì)這兩個(gè)函數(shù)要違背前面說的兩個(gè)規(guī)則，我碰到這些違反規(guī)則的情況時(shí)，都是作為設(shè)計(jì)錯(cuò)誤處理。當(dāng)一個(gè)對(duì)象類型作為收集型對(duì)象的元對(duì)象時(shí)，這個(gè)對(duì)象應(yīng)該擁有自己處理equals()，和/或處理hashCode()的設(shè)計(jì)，而且要遵守前面所說 的兩種原則。equals()先要查null和是否是同一類型。查同一類型是為了避免出現(xiàn)ClassCastException這樣的異常給丟出來。查 null是為了避免出現(xiàn)NullPointerException這樣的異常給丟出來。如果你的對(duì)象里面容納的數(shù)據(jù)過多，那么這兩個(gè)函數(shù) equals()和hashCode()將會(huì)變得效率低。如果對(duì)象中擁有無法serialized的數(shù)據(jù)，equals()有可能在操作中出現(xiàn)錯(cuò)誤。想象 一個(gè)對(duì)象x，它的一個(gè)整型數(shù)據(jù)是transient型（不能被serialize成二進(jìn)制數(shù)據(jù)流）。然而equals()和hashCode()都有依靠 這個(gè)整型數(shù)據(jù)，那么，這個(gè)對(duì)象在serialization之前和之后，是否一樣？答案是不一樣。因?yàn)閟erialization之前的整型數(shù)據(jù)是有效的 數(shù)據(jù)，在serialization之后，這個(gè)整型數(shù)據(jù)的值并沒有存儲(chǔ)下來，再重新由二進(jìn)制數(shù)據(jù)流轉(zhuǎn)換成對(duì)象后，兩者（對(duì)象在serialization 之前和之后）的狀態(tài)已經(jīng)不同了。這也是要注意的。知道以上這些能夠幫助你：1. 進(jìn)行更好的設(shè)計(jì)和開發(fā)。2. 進(jìn)行更好的測(cè)試案例開發(fā)。3. 在面試過程中讓面試者對(duì)你的學(xué)識(shí)淵博感到滿意。 hashCode的作用 總的來說，Java中的集合（Collection）有兩類，一類是List，再有一類是 Set。你知道它們的區(qū)別嗎？前者集合內(nèi)的元素是有序的，元素可以重復(fù)；后者元素?zé)o序，但元素不可重復(fù)。那么這里就有一個(gè)比較嚴(yán)重的問題了：要想保證元素不重復(fù)，可兩個(gè)元素是否重復(fù)應(yīng)該依據(jù)什么來判斷呢？。但是，如果每增加一個(gè)元素就檢查一次，那么當(dāng)元素很多時(shí)，后添加到集合中的元素比較的次數(shù)就非常多了。也就是說，如果集合中現(xiàn)在已經(jīng)有1000個(gè)元素，那么第1001個(gè)元素加入集合時(shí)，它就要調(diào)用1000次 equals方法。這顯然會(huì)大大降低效率。 于是，Java采用了哈希表的原理。哈希（Hash）實(shí)際上是個(gè)人名，由于他提出一哈希算法的概念，所以就以他的名字命名了。哈希算法也稱為散列算法，是將數(shù)據(jù)依特定算法直接指定到一個(gè)地址上。如果詳細(xì)講解哈希算法，那需要更多的文章篇幅，我在這里就不介紹了。初學(xué)者可以這樣理解，hashCode方法實(shí)際上返回的就是對(duì)象存儲(chǔ)的物理地址（實(shí)際可能并不是）。 這樣一來，當(dāng)集合要添加新的元素時(shí)，先調(diào)用這個(gè)元素的hashCode方法，就一下子能定位到它應(yīng)該放置的物理位置上。如果這個(gè)位置上沒有元素，它就可以直接存儲(chǔ)在這個(gè)位置上，不用再進(jìn)行任何比較了；如果這個(gè)位置上已經(jīng)有元素了，就調(diào)用它的equals方法與新元素進(jìn)行比較，相同的話就不存了，不相同就散列其它的地址。所以這里存在一個(gè)沖突解決的問題。這樣一來實(shí)際調(diào)用equals方法的次數(shù)就大大降低了，幾乎只需要一兩次。所以，Java對(duì)于eqauls方法和hashCode方法是這樣規(guī)定的：如果兩個(gè)對(duì)象相同，那么它們的hashCode值一定要相同；如果兩個(gè)對(duì)象的hashCode相同，它們并不一定相同，上面說的對(duì)象相同指的是用eqauls方法比較。你當(dāng)然可以不按要求去做了，但你會(huì)發(fā)現(xiàn)，相同的對(duì)象可以出現(xiàn)在Set集合中。同時(shí)，增加新元素的效率會(huì)大大下降。我們知道，equals()函數(shù)是用來做比較的。java中的比較有兩種：一種是內(nèi)存地址的比較，一種是內(nèi)容的比較。而比較個(gè)體也有兩種：一種是簡(jiǎn)單類型（這類簡(jiǎn)單說來無所謂內(nèi)存地址的比較或者內(nèi)容比較的區(qū)別）；還有一種是對(duì)象的比較，本文中說的主要是后者在java中，（對(duì)象）內(nèi)存地址的比較，是通過==完成的。比如 這樣的語句中，我們認(rèn)為，如果obj1和obj2的內(nèi)存地址相同，則返回true而equals()通常是比較內(nèi)容的。這里說“通?！?，是因?yàn)樵谧罡镜腛bject類中，equal()函數(shù)做的是地址的比較。而在其他幾乎所有的類中，equals()都經(jīng)過重載，進(jìn)行內(nèi)容的比較。而在說equals()的時(shí)候我們還涉及hashCode()是因?yàn)樵谟行?yīng)用中（比如，HashMap的key是對(duì)象），必須在重載equals()的同時(shí)重載hashCode()。因?yàn)閖ava中默認(rèn)(Object)的hashCode是根據(jù)對(duì)象的地址計(jì)算得到的。我們通常不會(huì)注意到這個(gè)問題，因?yàn)槲覀兺ǔＫ褂玫膋ey都是簡(jiǎn)單類型，或者是String, Long等一些特殊的對(duì)象（其特殊性請(qǐng)參看筆者在寫java 淺拷貝和深拷貝時(shí)的討論），這時(shí)候，這個(gè)問題被我們無意間繞過了有人已經(jīng)概括了這種我們忽略了的情況：“如果你想將一個(gè)對(duì)象A放入另一個(gè)收集（集合）對(duì)象B里，或者使用這個(gè)對(duì)象A為查找一個(gè)元對(duì)象在收集對(duì) 象B里位置的鑰匙（key），并支持是否容納（isContains()），刪除收集對(duì)象B里的元對(duì)象（remove()?）這樣的操作，那么，equals()和hashCode()函數(shù)必須開發(fā)者自己定義?！?（括號(hào)為筆者添加）
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1