J2EE疑難解決實例

2019-11-18 12:30:57

字體：大中小

來源：轉載

供稿：網友

　　J2EE疑難解決實例　
　　作者：xiaoyao原創發文時間：2003.10.22
　　
　　Best Story I
　　
　　System.out.PRintln("total memory is: "
　　+ java.lang.Runtime.getRuntime().totalMemory() / 1024);
　　System.out.println("free memory is: "
　　+java.lang.Runtime.getRuntime().freeMemory() / 1024);
　　
　　有一天，一家客戶要找東軟麻煩，說我們的軟件不好用，總死機。weblogic錯誤提示好象是內存分配請求失敗。
　　
　　－－東軟的應用系統從研發環境搬到使用環境去，一開始總要出點毛病，PC機上的tomcat終歸不能跟服務器上的weblogic比啊。
　　
　　監理公司打上門來了，我和一個java天師一起受理這個案子。（java天師就是洞察java心髓的技術大師，不是精通java命令語法、熟練ide工具用法的程序員，不是編碼工，以下同此義。）
　　
　　開發主力親自過來搭建了演示環境，我們測試了一下，沒有出現同等錯誤。操作系統是不同的unix類型，因此數據庫也是不同的版本。別的地方都一樣啊。
　　
　　天師用java.lang.Runtime.getRuntime().totalMemory()和freeMemory()函數得到jvm的實際分配量和使用量，發到前線去測了一下，發現雖然啟動Weblogic server指定了大內存參數，實際運行時，jvm沒有得到這么多內存。
　　
　　現在找到了問題，是weblogic沒有打夠補丁！
　　
　　案子結束，我們通知前線去索要weblogic和unix OS的最新補丁，現在該東軟發飆了。
　　
　　Best Story II
　　
　　System.out.println("the caller is "
　　+ sun.reflect.Reflection.getCallerClass(0));
　　System.out.println("the caller is "
　　+sun.reflect.Reflection.getCallerClass(1));
　　System.out.println("the caller is "
　　+sun.reflect.Reflection.getCallerClass(2));
　　
　　這是我們自己的故事，NOU發布后，一切表現如常，有一次，忽然發現數據庫連接池行為異常，不能正確分配新的連接。以前做壓力測試、暴力測試都沒有漏過一次啊？！
　　
　　為了查錯，我們想知道是那些程序訪問了公共的數據庫訪問bean。調用的地方太多，只能在bean里面加代碼來實現調用者的報告了，用什么代碼呢？
　　
　　我們在水母smth.org上發了一個提問，半小時內就有了一個有價值的回答，提醒我們用sun.reflect.Reflection.getCallerClass(int i)，參數隨便，０，１，２，３都可以。我們試了，果然能匯報，０是getCallerClass自身，１是bean自身，２就應該是bean的調用方，３不穩定。這個函數好象不能準確的報告所有的調用層。對我們來說，能有２好用就可以了。
　　
　　我們在程序上依然沒有找到錯誤，vaja用了一個晚上排除了代碼有問題的可能性。
　　
　　最后我們把weblogic的連接池的健壯性探測開關都打開，錯誤排除了。
　　
　　Best Story III
　　
　　接著上一個故事，我們又調一個系統，這次是kevin的struts框架的程序搬家失敗了，不能在weblogic上用。讀applicationResources.properties文件失敗，我們在ApplicationResources.properties文件里改了各種可能，都不行。
　　
　　我們改用struts范例，部署也不成功。
　　
　　我們換了一臺服務器，范例部署成功了，而業務程序部署依然錯誤。
　　
　　改程序吧，kevin改了幾次，沒效果。
　　
　　我們能判定的是：weblogic版本對應用系統的表現有影響。
　　
　　kevin和離島狂人一起比較了weblogic的版本，發現不能部署struts范例的系統是根本沒補丁的。有補丁也是sp2。
　　
　　安裝sp4？
　　
　　在大連的網管沒給我們FTP權限，三天后，在沈陽，從java天師那里得到了sp4，回來裝上便解決問題。
　　
　　一點經驗
　　
　　調試問題，解決問題，要害在于分析，不在于編碼快。
　　
　　光有j2sdk，jsp，servlet的知識和開發工具的知識，還是不夠，要懂得系統運轉的機理，盡量分解錯誤，定位錯誤，縮小錯誤范圍，還可以通過各種實驗來排除一些可能，形成一些有助于調試的初步結論。
　　
　　這是trouble shooting的基本思想。
　　
　　進一步，要分清楚是在研究環境還是現場環境做動作，在現場做事情另外有一些規則

上一篇：Sun在開放源代碼J2EE認證上又邁出重要一步

下一篇：JNDI設計內幕