2010-12-06 111 views
0

我需要內部實現HashTable在java代碼中。進一步,你可以解釋我與其他意見代碼作爲它如何工作。在java中需要內部實現HashTable

我只是在HashTable中使用的加載因子和容量有一些基本知識,其中加載因子是0.75。你能用一個簡單的例子來解釋嗎?

我很久沒有這個了。

1>爲什麼散列表的加載因子爲0.75,而不是其他值不等。很奇怪請澄清。

2>爲什麼我們沒有HashMap的加載因子?
我不想要現有的代碼。有人寫了比實際編寫的更好的代碼

+1

來源可以在這裏找到... http://developer.classpath.org/doc/java/util/Hashtable-source.html – 2010-12-06 14:46:29

+0

你看過Java源代碼嗎? – Sean 2010-12-06 14:46:40

+0

夥計們感謝您的即時答覆,但是問題1和問題2 – Deepak 2010-12-06 14:49:03

回答

4

爲何我們對客座率HashMap?

我們 - 看HashMap(int initialCapacity, float loadFactor)

爲什麼是散列表負載係數0.75,而不是其變化的一些其他的價值。

  1. 負荷係數爲Hashtable一個可調參數。

  2. HashMaps的javadoc說的是關於0.75的值。

「作爲一般規則,默認加載因子(.75)在時間和空間成本上尋求一種折衷。較高的值減少空間開銷,但增加了查找成本(反映在大多數HashMap類的操作,包括get和put)。「

我知道這個數字是由經驗測試而不是理論分析確定的。 (一個徹底的理論分析將是困難的,但是,在絕大多數情況下,加載因子爲0.75並結合一個好的散列函數可能足以將散列鏈降低到1或2,並且導致快速的平均查找時間。 )

1

源代碼是available for download。你甚至可以擁有它 - 如果你使用Eclipse,點擊Ctrl-Shift-T,鍵入「Hashtable」,看看你是否可以看到源代碼。自己下載代碼絕對比它剛剛發佈在這裏更受歡迎。

如果您有任何特定關於實施的問題,請問(通過編輯此問題或詢問另一個問題)。 「Hashtable工作如何」的一般問題不太可能讓你感到非常滿意......儘管在general principles上閱讀並不會造成任何傷害。

1

你的JVM有可用的JDK安裝的一部分庫的源代碼。你只需要選擇它。 Java有兩種不同的實現:HashMap和HashTable。 HashTable具有用於同步的額外內容,因此如果您想要核心實現,請查看HashMap的源代碼。除此之外,你是獨立的。

1

你應該永遠不需要內部的實現,這就是爲什麼約書亞布洛赫確實把它從我們身邊隱藏起來。我更喜歡使用標準Java Collections API類中的HashMapHashtable。首先,它更快(不同步)。其次,Hashtable在真正的收藏品被添加到那裏之前就已經在Java了,然後它被改編(據我所知)。

這是從java.util.HashMap<K, V>類的JavaDoc的摘錄:

HashMap實例有影響其性能的兩個參數:初始容量負載因子容量是哈希表中桶的數量,初始容量僅僅是哈希表創建時的容量。 加載因子是散列表在其容量自動增加之前被允許獲得的滿量程的度量。當哈希表中的條目數超過負載因子與當前容量的乘積時,通過調用rehash方法,容量大約增加一倍。

我認爲這很清楚。加載因子爲0.75並且初始容量爲100的地圖將插入前75個新地圖項,而不分配任何內存。如果你再添加一個元素。將分配一個容量爲200的新內存塊,並將現有項目複製到此新內存中。爲了另一個更大的內存塊而分配的新項目數量現在分配爲150。

更多的細節可以在HashMap的類源代碼中看到。

0

大部分JDK的代碼都附帶了JDK。它位於src.jar文件中。如果你使用IDE,它會自動鏈接到這個jar,所以當你在一個內部類上時,它會向你顯示源代碼。

值得注意的是,Hashtable在1998年被Java 1.2集合所取代。我不推薦你使用它,除非你必須爲遺留的庫。

1>爲什麼是負載係數爲0。75爲散列表,而不是其他一些值不同的值。很奇怪。

根本不奇怪,默認值必須是某種東西,並且此值被選爲最佳的全面性能。

我不想現有code.some一個誰寫比實際寫入

一個更好的代碼你說的更好呢?你看過在Java 5.0(2005)中使用併發庫添加的集合嗎?在某些情況下更好一些,是作爲這些支持基元的Trove4j集合。你也可以看看有很多擴展的番石榴。