DFA 演算法是通過提前構造出一個 樹狀查找結構，之後根據輸入在該樹狀結構中就可以進行非常高效的查找。 設我們有一個敏感詞庫，詞酷中的辭彙為：我愛你我愛他我愛她我愛你呀我愛他呀我愛她呀我愛她啊 那麼就可以構造出這樣的樹狀結構： 設玩家輸入的字元串為：白菊我愛你呀哈哈哈 我們遍歷玩家輸入的字元串 str ...
背景
外媒The Register報道，甲骨文稽查企業用戶，近期開始將把過去看管較鬆散的Java授權加入。
甲骨文針對標準版Java（Java SE）有2種商業授權。2019年4月甲骨文宣佈Java SE用戶需要付費訂閱，才能取得授權及更新，包括Java SE 7、8或11、12。但到同年9月該公司又宣佈了免費Java授權方案，針對Java 17版本提供每季更新，併在2021年的新版本提供多1年免費支持，但這項方案並不溯及既往，舊版Java用戶即使安裝修補程式也是需要付費。
報道指出，最近一些美國企業收到甲骨文授權管理部門的消息，詢問Java授權數量。此外甲骨文也從資料庫、中間件或應用授權，來推敲用戶的Java授權是否為虛報。例如，資料庫的數量可以反映 CPU 數量，Java SE 訂閱價格的其中一個收費標準為每個 CPU 每月收費 25 美元，因此就可以反映出 Java SE 訂閱數量是否符合要求。
在這個背景下一些企業已開始用 OpenJDK 開源替代方案應對甲骨文的審計。但是OpenJDK與甲骨文標準版之間存在差異。今天咱們就來聊聊這些差異。
JDK和OpenJDK的區別
關於JDK和OpenJDK的區別，可以歸納為以下幾點：
授權協議的不同
OpenJDK採用GPL V2協議，而JDK則採用JRL。兩者協議雖然都是開放源代碼的，但是在使用上的不同在於GPL V2允許在商業上使用，而JRL只允許個人研究使用。
OpenJDK不包含Deployment（部署）功能
部署的功能包括：Browser Plugin、Java Web Start、以及Java控制面板，這些功能在Openjdk中是找不到的。
OpenJDK源代碼不完整
這個很容易想到，在採用GPL協議的Openjdk中，sun jdk的一部分源代碼因為產權的問題無法開放openjdk使用，其中最主要的部分就是JMX中的可選元件SNMP部分的代碼。因此這些不能開放的源代碼將它製作成插件，以供OpenJDK編譯時使用，你也可以選擇不要使用plug。而Icedtea則為這些不完整的部分開發了相同功能的源代碼(OpenJDK6)，促使OpenJDK更加完整。
部分源代碼用開源代碼替換
由於產權的問題，很多產權不是SUN的源代碼被替換成一些功能相同的開源代碼，比如說字體柵格化引擎，使用Free Type代替。
OpenJDK只包含最精簡的JDK
OpenJDK不包含其他的軟體包，比如Rhino Java DB JAXP……，並且可以分離的軟體包也都是儘量的分離，但是這大多數都是自由軟體，你可以自己下載加入。
不能使用Java商標
這個很容易理解，在安裝openjdk的機器上，輸入“java -version”顯示的是openjdk，但是如果是使用Icedtea補丁的openjdk，顯示的是java。（未驗證）
OpenJDK之坑
一個在 Java SE 中穩定運行了一年多的項目，最近在OpenJDK上部署測試。一個案例失敗。原因是缺少javafx.util。
這裡的javafx.util包在jdk 1.8的類庫裡面有，但在OpenJDK 8裡面是沒有的。解決方式也很簡單，主要如下幾種做法：
-
不要使用javafx.util這種OpenJDK裡面沒有的包；
-
下載javafx-sdk到伺服器，編譯時將javafx-sdk位置作為--module-path參數傳入；
-
在pom裡面顯式添加javafx依賴，這樣在伺服器上用mvn編譯時，會把它從maven中央倉庫拉到本地打包到你的工程里。
<!-- java項目 fhadmin.cn-->
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-base</artifactId>
<version>14-ea+7</version>
</dependency>4. 本地編譯好，直接用jar包佈署。
除了這個問題之外，Oracle JDK構建過程是基於OpenJDK的，所以他們之間並沒有技術差別。只是OpenJDK由於版本發佈比較頻繁，可能會遇到不穩定的問題。根據社區反饋，也有一些OpenJDK用戶遇到了性能問題。而Oracle JDK作為商業軟體，在穩定性方面要好很多。
