今天主要改了rss和收藏夾的bug，有一定的收穫。 這幾天提的bug中有很多是關於收藏夾的，以前正常的功能突然出現了很多bug，後臺總是報空指標錯誤，跟蹤了半天，才發現是新面板的問題，目前3.1中已經有了應用面板模式的系統選項，勾選後則應用標準面板，在標準面板中將系統功能新增到收藏夾時是把uifuncguid儲存到了庫中，並沒有儲存功能的guid，所以在用sessionEnv.getUIService.getBaseFuncion(funcguid)中得到的funcItem為null，所以有空指標，當初程式設計時，根本沒有考慮到如果guid為空或者不正確的時候，得到的funcItem會為空指標，所以說在寫程式的時候不要假設某些情況不會出現，一切情況都回出現，所以一定要嚴密，經常判斷得到的物件是否為空可以大大避免空指標的錯誤出現，所以在寫程式時一定要注意這一點。 另外今天提的bug中還有一個是關於rss地址訪問不到的，這個問題我幾天前已經花大力氣解決過了，今天又仔細測試了一下，發現解決方法還是有待於改進。上次是用ThreadLocal做得執行緒級別的快取，當每個執行緒去執行訪問rss地址的任務時候，把得到的doc物件放在其ThreadLocal裡邊，並用另一個ThreadLocal標誌此執行緒已經訪問過此rss地址。這樣是有問題的，當莫個時間點遠端主機不可訪問時候，那時執行的執行緒A中記錄了此rss地址不可訪問；當某個時間點此rss地址又可以訪問時候，此時執行的執行緒B中儲存瞭解析出來的doc物件，並記錄了此rss地址可以訪問。這樣當執行緒A重新執行時和執行緒B執行時候結果就會完全相反，體現在頁面上就是不斷重新整理頁面時，如果是執行緒A執行，則提示使用者此rss地址不可訪問，如果是執行緒B執行，則會展示此rss地址中的種子資訊，不同的結果，當然是bug。  所以不可以用執行緒級別的ThreadLocal去解決，因為web伺服器中有執行緒池的概念，並不是每個程式的執行都去建立新的執行緒，而是輪流使用執行緒池裡邊的執行緒。  最後是還是用類級別的快取解決的，但是把此快取的生存週期控制在一定時間範圍內，比如1 0秒，具體程式如下：  public Document canRssConnected(String rssAddress,int  timeout){
  long lastAccessTime =0;//上次訪問的時間
  long intervalTime = 0;//上次訪問的時間與當前時間的間隔時間
  Document doc = null;
  if(cacheMap.get("time")!=null)
           lastAccessTime = ((Long)cacheMap.get("time")).longValue();
    if(cacheMap.get("time")==null || intervalTime>10000){//如果cacheMap中沒有time屬性對應的物件或者此次訪問時間距上次訪問時間已經超過１0秒，則重新取doc
    cacheMap.put("time",new Long(System.currentTimeMillis()));//存入當前時間
    doc = getRssDocument(rssAddress,timeout);
    cacheMap.put("doc", doc);
  }