<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    rosial

    lost memory
    數據加載中……

    Violations(多數內容來自他人blog與論壇討論)

    Critical!


    1. Findbugs——Dodgy - Dead store to local variable
     
    例如:String abc = "abc";
          String xyz = new String();
          xyz = abc;
    編譯肯定通過,運行也不會出問題。   

    來分析一下這個語句:String xyz = new String();   
    這一句執行3個動作:   
    1)創建一個引用xyz   
    2)創建一個String對象   
    3)把String的引用賦值給xyz

    其中,后面兩個動作是多余的,因為后面的程序中你沒有使用這個新建的String對象,而是重新給xyz賦值。   
              xyz = abc; 

    所以,只需要   
              String xyz = abc; 就可以完成整個操作了,可以把上面的語句修改為:
       String abc = "abc";
              xyz = abc;
    這樣,findbugs就不會報了。

    FindBugs的提示:Dead   store   to   local   variable。   
    意思應該是:本地變量存儲了閑置不用的對象,也就是說這個變量是多余的。
    FindBugs的提示:Dead   store   to   local   variable。 
    意思應該是:本地變量存儲了閑置不用的對象。 

    zbo(大門)說的IDEA中的提示比較直觀。 
    'new   Object() '是多余的。 ——Variable   'aObject '   initializer   'new   Object() '   is   redundant.  

    ----------------------------------------------------------------------------------------------------------------

    [hyddd的FindBugs分析記錄][M D DLS] Dead store to local variable

    [M D DLS] Dead store to local variable [DLS_DEAD_LOCAL_STORE]

    This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

    Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

     

    看下面代碼:

    public static void main(String args[]) throws Exception{
        Object str 
    = new Object() ;  //報錯處
        str 
    = new Object() ;
        System.out.println(str);
    }

     

    Object str = new Object();是無用的代碼,因為在下面有一句str= new Object();,很多語言編譯器它都會做優化,比如:去除一些無用的代碼以提高效率。JAVA編譯器也會做一些優化,但是,Java編譯器對上面這段代碼卻沒有做優化(你可以DComplie確認一下),編譯后的.class文件還是new了兩次,具體什么原因導致它不去做這個優化我還不能確定,我覺得難做這種優化不是借口,起碼不應該是Sun的借口。

    修改這段代碼方法很簡單,隨便去掉一行new Object();就可以了。


    這里我遇到了這樣的問題:

     1       Class[] paramArray = null;
     2       Object[] objArray = null
     3       String finalRetrun = null;
     4 String[] params = null;
     5       if ((param == null && paramType != null)
     6           || (param != null && paramType == null)) {
     7         out.println("Parameters are not match with parameter types!");
     8       }
     9 
    10       if (param != null && paramType != null) {
    11         params = param.split(";");
    12         String[] paramTypeArray = paramType.split(";");
    13         Object[] paramWithClass = classCast(params, paramTypeArray);
    14         if (null != customMethod) {
    15           paramArray = new Class[] { String.class, String.class, Object[].class };
    16           objArray = new Object[] { entityName, customMethod, paramWithClass };
    17         } else {
    18           paramArray = new Class[] { String.class, Object[].class };
    19           objArray = new Object[] { entityName, paramWithClass };
    20         }

    1-4行中只提示第4行的
    params是dead store,前面3個不也是有null的無辜存在嗎?
    反復看了覺得差別是params在下面只被重復賦值一次,而前面3個變量被重復賦值多次……不知是不是這樣的原因……



    [hyddd的FindBugs分析記錄][M S XSS] Servlet reflected cross site scripting vulnerability

    [M S XSS] Servlet reflected cross site scripting vulnerability [XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER]

    This code directly writes an HTTP parameter to Servlet output, which allows for a reflected cross site scripting vulnerability. Seehttp://en.wikipedia.org/wiki/Cross-site_scripting for more information.

    FindBugs looks only for the most blatant, obvious cases of cross site scripting. If FindBugs found any, you almost certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool.

     

    先看下面代碼:

    public void doGet(HttpServletRequest request,HttpServletResponse response)throws ServletException,IOException{
      //
      String v = request.getParameter("v");
      //
      PrintWriter out = response.getWriter();
      out.print(
    "協議版本號不對,v="+v);
      out.close();
      //
    }
    這里字符串v沒有作過濾,直接返回給用戶,有可能操作XSS攻擊。具體關于XSS攻擊的資料,可以參考上面Findbugs說明中的連接,這里就不多說了。


    2. method invokes inefficient new String() constructor.
    (方法中調用了低效的new String()構造方法)
    例如: String abc = new String("abc");
    這個語句會去調用String的構造方法String(String)在堆棧創建一個對象,并把這個對象的引用賦給abc.
    如果直接采用String abc = "abc";的方式就不用在堆棧中新創建一個對象了,而直接在值棧中創建一個"abc"對象,把"abc"賦給變量abc

    所以,在沒有特殊需要的時候就不要去創建新的對象,盡量在值棧中尋找需要的內容。比如,在一個方法返回值為"abc"時,不要采用return new String("abc");的方法,而改變為使用return "abc";的方法,提高執行效率。
      

    3. XXX mail fail to close stream.
    (輸入)流可能沒有關閉。

    在進行文件流的操作時,沒有對輸入輸出流進行關閉,或者關閉過程可能出錯,就會報這個bug。最好是在finally中將所有的輸入輸出流關閉。

    4. Possible null pointer dereference in method on exception.
    (在有異常的情況下,可能調用的引用是一個空指針)

    這個很容易理解,比如在try塊中對一個空引用的變量進行賦值,而在try塊之后才引用這個變量,就可能會出現空指針異常。

    5.Suspicious reference comparison.
    (懷疑對兩個引用進行比較)

    在對兩個對象(即兩個引用)進行比較的時候,使用的不是equals()方法,而采用==的方式進行,可能會出現結果與預期不一致的情況.
    當然,在對兩個引用進行equals()的時候,對象是需要重寫hashcode()方法的。


    以上來自:



    3. Performance - Method concatenates strings using + in a loop

    Plugin: findbugs    Key: SBSC_USE_STRINGBUFFER_CONCATENATION

    The method seems to be building a String using concatenation in a loop. In each iteration, the String is converted to a StringBuffer/StringBuilder, appended to, and converted back to a String. This can lead to a cost quadratic in the number of iterations, as the growing string is recopied in each iteration.

    Better performance can be obtained by using a StringBuffer (or StringBuilder in Java 1.5) explicitly.

    For example:


     // This is bad
      String s = "";
      
    for (int i = 0; i < field.length; ++i) {
        s 
    = s + field[i];
      }

      
    // This is better
      StringBuffer buf = new StringBuffer();
      
    for (int i = 0; i < field.length; ++i) {
        buf.append(field[i]);
      }
      String s 
    = buf.toString();


    4. Bad practice - Method may fail to close stream on exception

    Plugin: findbugs    Key: OS_OPEN_STREAM_EXCEPTION_PATH

    The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method.  This may result in a file descriptor leak.  It is generally a good idea to use a finally block to ensure that streams are closed.




    Just delete it!!



    posted on 2012-02-27 18:43 rosial 閱讀(1320) 評論(0)  編輯  收藏


    只有注冊用戶登錄后才能發表評論。


    網站導航:
     
    主站蜘蛛池模板: 亚洲成a∧人片在线观看无码| 国产亚洲蜜芽精品久久| 最近免费中文字幕大全| 国产亚洲漂亮白嫩美女在线| 亚洲精品自产拍在线观看| 91久久精品国产免费直播| 亚洲第一街区偷拍街拍| 久久91亚洲人成电影网站| 中文字幕无码视频手机免费看| 爱爱帝国亚洲一区二区三区| 亚洲综合无码精品一区二区三区 | 色屁屁www影院免费观看视频| 亚洲精品无码成人片久久| 成人免费无码视频在线网站| 一级毛片免费一级直接观看| 亚洲成年人免费网站| 亚洲国模精品一区| 日本XXX黄区免费看| 中文在线日本免费永久18近| 亚洲人成77777在线观看网| 亚洲色偷偷综合亚洲AVYP| 男人的好免费观看在线视频| 日韩免费高清播放器| 青娱乐在线免费观看视频| 亚洲精品永久www忘忧草| 亚洲七七久久精品中文国产| 久草在视频免费福利| 成全视频在线观看免费| 狼人大香伊蕉国产WWW亚洲 | 国产一级一毛免费黄片| 亚洲午夜精品一区二区麻豆| 久久精品亚洲中文字幕无码网站| 免费jjzz在在线播放国产| 西西大胆无码视频免费| 日韩精品内射视频免费观看 | 人妻免费久久久久久久了| 亚洲av永久无码精品三区在线4| 国产亚洲精品自在久久| 女人18毛片水最多免费观看| 亚洲视频在线免费看| 男的把j放进女人下面视频免费|