Java究竟怎么玩？

 中午吃飯時大略分析了一下Douyu的業務實現過程，趁著沒人偶趕緊發上來……由于該平臺尚未開源，分析可能存在某種程度的誤差，對與不對有賴讀者自辨……

咳， 經過一段相當漫長的鉆研，偶得出如下結論：

就目前所見，Douyu項目由com.douyu.config，com.douyu.engine，com.douyu.engine.core，com.douyu.engine.db，com.douyu.engine.dialect，com.douyu.engine.http，com.douyu.engine.http.buf，com.douyu.engine.http.fileupload，com.douyu.engine.http.session，com.douyu.engine.http.util，com.douyu.engine.log，com.douyu.engine.util，com.douyu.http(不理解為什么不同com.douyu.engine.http寫一起……)，com.douyu.main，com.douyu.security，com.douyu.sql，com.douyu.tree，com.douyu.util等包組成。

由于重寫了javac的部分java編碼，Douyu可以“表面上”直接讀取Java文件，也就是Douyu可以不需手動編譯即可令Java文件被執行，也可以動態增刪java文件內容，但與常見的java字節碼修改不同，Douyu的動態特性依賴于添加相應字符串到java文件對應內容后的重新編譯。

在Douyu的engine.core包下有兩個非常重要的組件，堪稱是Douyu的核心所在，一個是調用com.sun.tools.javac包的javac類，一個是真正用于處理Douyu中javac命令的CleverCoder類（在com.sun.tools.javac.main.JavaCompiler與com.sun.tools.javac.comp.Enter中被調用），應該說，javac只是一個調用數據的馬甲，而核心在于CleverCoder。至于CleverCoder對于java文件的處理原理，則與jsp生成servlet的原理相類似（順便說一下，前天偶提到Douyu只能加載靜態頁面，現在看來并不確切，應該是Douyu可以將view層轉義為Java文件，再編譯執行轉義后的文件并反饋到頁面中去，由于Douyu中存在ViewEntry，view數據也會經由updateView函數進行逐行分析后處理并反饋，其與jsp轉servlet過程大同小異，但對其運行效率保留意見……）。

Douyu加載java文件與類使用自定義的ResourceLoader，其繼承關系如下：URLClassLoader->LibClassLoader->ResourceLoader。

ResourceLoader內部依賴Javac，以ConcurrentHashMap緩存數據，Douyu在每次loadResource時都會判斷目標對象是否存在，存在則調用已有對象，不存在則調用異化后的javac生成該對象。縱觀整個Douyu平臺對ResourceLoader的調用，顯而易見Douyu中ResourceLoader重點不是用于加載class。與標準ClassLoader相比，ResourceLoader更像一個javac命令的緩存與執行器，它之所以存在，實際上就是要加載java文件本身，類加載功能反倒其次。

目前來說，ResourceLoader處理不同功能的函數接口并不統一，針對不同功能需要分別調用對應函數，例如在其DefaultContext中out時尚需要分別調用loadClassResource與loadStaticResource，而在Database的MetaData類中又需要調用compileClass（內部會調用findClassOrClassResource查詢指定類，有類加載，沒有則調用javac編譯java文件后加載），到了http包下屬的Connector里又得加載loadResource來匹配類與PrintWriter中數據。

Douyu目前涵蓋有http請求與反饋、db操作、security驗證等主要功能，但實現程度普遍較低。比如數據庫方言僅支持mysql、oracle、sqlserver三種，而且只有mysql與oracle實現了不同的limit與非常少的操作優化，sqlserver部分暫時看還是空殼。security中的rule還只有一個接口，沒有看到具體業務邏輯與調用，能夠被checkPermission函數處理的Permission實現也非常有限。http協議部分雖然擁了有最基礎的協議解讀能力，但也僅僅是最基礎的能力而已，比如目前我即不能向Douyu服務器要求對目標資源進行gzip壓縮，Douyu也不可能根據瀏覽器判定此要求是否可行，更不要說反饋數據了，諸如此類的不足還有很多（僅以偶07年在各大小說網站刷票得到的http協議應用經驗看），建議作者去找一份http1.1協議文檔逐一比對并分別實現。沒辦法，誰讓Douyu是個孤立的平臺，開發難度自然大些（不過都寫上的話，性能又會大打折扣，照目前的業務邏輯完全補足協議與相關功能后，我斷言Douyu效率比不上Tomcat6，所以系統尚待優化）……

綜上所述，竊以為Douyu平臺在技術上存在可行性與創新性（如果作者有閑錢的話，可以考慮在國內申請個技術新型專利，最起碼擺著好看），只是業務功能暫時不足，部分領域有待分工與優化，尚不具備很強的實用性，希望作者響應國父“革命尚未成功，同志仍需努力”號召，持續發展，與時俱進，吾輩就以觀后效了……

以下揀選了兩張分析代碼時生成的Douyu關系圖（感覺比較散啊，侵入性太強了……）：