字典樹樹java

❶ 數據結構--前綴樹（字典樹）

Trie ，又稱前綴樹或字典樹，是一棵有根樹，其每個節點包含以下欄位：

我們從字典樹的根開始，插入字元串。對於當前字元對應的子節點，有兩種情況：

重復以上步驟，直到處理字元串的最後一個字差帆符，然後將當前節點標記為字元串的結尾。

我們從塵慶腔字典樹的根開始，查找前綴。對於當前字元對應派衫的子節點，有兩種情況：

重復以上步驟，直到返回空指針或搜索完前綴的最後一個字元。

若搜索到了前綴的末尾，就說明字典樹中存在該前綴。此外，若前綴末尾對應節點的 isEnd 為真，則說明字典樹中存在該字元串。

❷ 字元串匹配演算法的使用（未完待整理）

字元串的匹配在java中都知道使用indexOf函數來實現，那麼其匹配演算法是怎麼樣的呢？

單模式和多模式的區別就是一次遍歷主串能否將多個模式的字元串都查找出來。

英文全稱為Brute Force，暴力匹配演算法，匹配字元串的方法比較暴力，也比較簡單易懂。其大概的思路就是：

我們可以看到，在極端情況下，在主串 aaaa...aab 中尋找模式串 aab ，那麼總共需要尋找(n-m+1)次，且每次都需要比對m次，那麼時間復雜度將是 (n-m+1)*m ，即 O(n*m) ；但實際上並不會這么低效，因為我們的使用場景中主串和模式串都不會太長，而且在每個子串和模式串進行比對時，只要中途有一個不匹配，那麼當前比對就會提前結束，因此大部分情況下，時間復雜度都會比 O(n*m) 要好。

我們在BF演算法的基礎上引入哈希演算法，我們不需要將每個子串與模式串逐個字元地進行比較，而是計算得出每個子串的hash值，然後和模式串的hash值進行比較，如果有相等的，那就說明有子串和模式串匹配上了。

雖然我們只需要比對模式串和子串的hash值就能得到匹配結果，次數為(n-m+1)，但是對每個子串進行hash計算的時候，是要遍歷每個字元的，因此次數也是m，那麼總的時間復雜度還是 O(n*m) ，並沒有明顯地提升。

那麼我們該如何想出一個辦法，使得每個子串hash值的計算時間得到提升呢？這就是RK演算法的精髓，假設子串包含的字元集中元素個數為k，那麼就用k進制數來代表這個子串，然後hash的過程就是將這個k進制的數轉換為十進制的數，這個十進制的數就是該子串的hash值。

相鄰子串的hash值計算是有規律的，我們只需要遍歷一次主串就能得到所有子串的hash值，演算法復雜度為O(n)，而不是像原先一樣，每個子串都需要O(m)的時間復雜度。

然後將模式串的hash值和所有子串的hash值進行比較，每次比較的時間復雜度是 O(1) ，總共比較(n-m+1)次，所以RK演算法的總的時間開銷為 O(n)+O(1)*O(n-m+1) ，即為 O(n) ，時間復雜度比BF演算法更加高效。

當然，有hash的地方就有可能會存在hash沖突，有可能子串和hash值和模式串的hash值是一樣的，但內容就是不一樣，此時怎麼辦呢？其實很簡單，對於hash值一樣的子串，我們增加雙保險，再比較一下這m個字元是否都一樣即可，總的時間開銷為 O(n)+O(1)*O(n-m+1)+O(m) ，即為 O(n) 。

如果極端情況下出現了很多hash沖突呢？我們對於每個和模式串相同hash值的子串都需要逐一再進行比較，那麼總的時間開銷就會為 O(n)+O(1)*O(n-m+1)+O(m)*O(n-m+1) ，即為 O(n*m) ，不過這種概率太小了，大部分情況下都不會這樣。

在真正的文本編輯器中查找和替換某個字元串時，使用的演算法既不是上述的BF演算法，也不是RK演算法；BF演算法只適合不是很長的主串，RK演算法則要設計一個沖突概率很低的hash演算法，這個比較困難，所以實際使用的是BM演算法，它是工程中非常常用的一種字元串匹配演算法，效率也是最高的。

演算法的思想和過程有些復雜，待以後整理。

KMP演算法在本質上是和BM演算法一樣的。演算法的思想和過程有些復雜，待以後整理。

瀏覽器輸入框中的智能輸入匹配是怎麼實現的，它是怎麼做動態字元串匹配查找的呢？這就用到了Trie樹。

又名字典樹，是一種專門用來快速查找字元串前綴匹配結果的樹形結構，其本質就是將所有字元串的重復的前綴合並在一起，構造一個多叉樹。

其中，根節點不包含任何信息，每個節點表示一個字元，從根節點到紅色節點的一條路徑表示存儲的一個字元串。當我們在如上Trie樹中查找"he"時，發現"he"並非是一個字元串，而是"hello"和"her"的公共前綴，那麼就會找到這兩個字元串返回。

Trie樹在內存中是如何存儲的呢？因為每一個節點都可能是包含所有字元的，所以每一個節點都是一個數組（或者散列表），用來存儲每個字元及其後綴節點的指針。

使用Trie樹，最開始構建的時候，時間復雜度為 O(n) ，其中n為所有字元串長度之和，但是一旦構建完成，頻繁地查詢某個字元串是非常高效的，時間復雜度為 O(k) ，其中k為查找字元串的長度。

Trie樹雖然查詢效率很高，但是比較浪費內存，每一個節點都必須維護一個數組存放所有可能的字元數據及其指向下一個節點的指針，因此在所有字元串公共前綴並不多的時候，內存空間浪費地就更多了。這種問題其實也有對應的解決辦法，我們可以不使用數組，而是使用有序數組、散列表、紅黑樹來存放，可以相應地降低性能來節省內存空間。

Trie樹除了可以實現瀏覽器動態輸入內容查找候選項的功能外，還可以實現多模式地敏感詞匹配功能。假設我們需要對用戶輸入的內容進行敏感詞檢查，將所有的敏感內容用***代替，那麼該如何實現呢？

首先我們可以維護一個敏感詞字典，使用上述四種單模式匹配演算法也可以實現，但是需要遍歷N次用戶輸入的內容，其中N是所有敏感詞的模式串，顯得非常低效。但是我們如果將敏感詞字典維護為一個Trie樹，然後將用戶輸入的內容從位置0開始在Trie樹中進行查詢，如果匹配到紅色節點，那麼說明有敏感詞；如果沒有匹配到紅色節點，就從用戶輸入內容的下一個位置開始繼續在Trie樹中查詢，直至將用戶輸入內容遍歷完，因此我們只是遍歷了一遍主串。

然而更高效的多模式字元串匹配使用地更多的是如下的AC自動機。

如果把Trie樹比作BF演算法，KMP演算法是BF演算法的改進，那麼AC自動機就是利用同樣的思想改進了Trie樹。

演算法的思想和過程有些復雜，待以後整理。

❸ JAVA 排序問題

第一、最簡單的辦法是使用暴力排序，也就是一個一個的計算，這個不用說你也應該懂吧？實現方法有多個。

第二、前面的方法太笨，數據量大時會導致系統非常慢，有一個最聰激穗明的辦法旁並，使用「字元樹（又稱字典樹）」。這種辦法估計你沒學過，這是《數據結構》學科里的一種N叉樹的表示形式。具體說起來明啟卜需要長篇大論，這里就不詳解了，但已經告訴你在《數據結構》這門學科上可以查找，你自已去學習研究吧！

❹ JAVA數據結構有哪幾種

JAVA數據結構有以下幾種：

1、List：

List是有序的Collection，使用此介面能夠精確的控制每個元素插入的位置。用戶能夠使用索引（元素在List中的位置，類似於數組下 >標）來訪問List中的元素，這類似於Java的數組。

2、Vector：

基於數組（Array）的List，其實就是封裝了數組所不具備的一些功能方便我們使用，所以它難易避免數組的限制，同時性能也不可能超越數組。

另外很重要的一點就是Vector是線程同步的(sychronized)的，這也是Vector和ArrayList 的一個的重要區別。

3、ArrayList：

同Vector一樣是一個基於數組上的鏈表，但是不同的是ArrayList不是同步的。所以在性能上要比Vector好一些，但是當運行到多線程環境中時，可需要自己在管理線程的同步問題。

4、LinkedList：

LinkedList不同於前面兩種List，它不是基於數組的，所以不受數組性能的限制。 它每一個節點（Node）都包含兩方面的內容：節點本身的數據（data），下一個節點的信息（nextNode）。

所以當對LinkedList做添加，刪除動作的時候就不用像基於數組的ArrayList一樣，必須進行大量的數據移動。只要更改nextNode的相關信息就可以實現了，這是LinkedList的優勢。

5、HashSet：

雖然Set同List都實現了Collection介面，但是他們的實現方式卻大不一樣。List基本上都是以Array為基礎。

但是Set則是在 HashMap的基礎上來實現的，這就是Set和List的根本區別。HashSet的存儲方式是把HashMap中的Key作為Set的對應存儲項。

6、HashMap：

基於哈希表的 Map 介面的實現。此實現提供所有可選的映射操作，並允許使用 null 值和 null 鍵。(除了不同步和允許使用 null 之外，HashMap 類與 Hashtable 大致相同。)此類不保證映射的順序，特別是它不保證該順序恆久不變。

7、HashTable：

Hashtable 是一個散列表，它存儲的內容是鍵值對(key-value)映射。Hashtable 繼承於Dictionary，實現了Map、Cloneable、java.io.Serializable介面。

Hashtable 的函數都是同步的，這意味著它是線程安全的。它的key、value都不可以為nul

❺ 如何用用java語言實現IP地址字典樹

其實就是一個tree，睜銷至於你要顯示什麼其實無所謂了，隨便找一個tree用上就可以了，比櫻早兄脊襲如ztree之類的都可以的
http://www.treejs.cn/v3/main.php#_zTreeInfo
個人找到的經典給你分享下