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

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

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

    rosial

    lost memory
    數(shù)據(jù)加載中……

    Violations(多數(shù)內(nèi)容來自他人blog與論壇討論)

    Critical!


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

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

    其中,后面兩個(gè)動作是多余的,因?yàn)楹竺娴某绦蛑心銢]有使用這個(gè)新建的String對象,而是重新給xyz賦值。   
              xyz = abc; 

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

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

    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() ;  //報(bào)錯(cuò)處
        str 
    = new Object() ;
        System.out.println(str);
    }

     

    Object str = new Object();是無用的代碼,因?yàn)樵谙旅嬗幸痪鋝tr= new Object();,很多語言編譯器它都會做優(yōu)化,比如:去除一些無用的代碼以提高效率。JAVA編譯器也會做一些優(yōu)化,但是,Java編譯器對上面這段代碼卻沒有做優(yōu)化(你可以DComplie確認(rèn)一下),編譯后的.class文件還是new了兩次,具體什么原因?qū)е滤蝗プ?/span>這個(gè)優(yōu)化我還不能確定,我覺得難做這種優(yōu)化不是借口,起碼不應(yīng)該是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個(gè)不也是有null的無辜存在嗎?
    反復(fù)看了覺得差別是params在下面只被重復(fù)賦值一次,而前面3個(gè)變量被重復(fù)賦值多次……不知是不是這樣的原因……



    [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(
    "協(xié)議版本號不對,v="+v);
      out.close();
      //
    }
    這里字符串v沒有作過濾,直接返回給用戶,有可能操作XSS攻擊。具體關(guān)于XSS攻擊的資料,可以參考上面Findbugs說明中的連接,這里就不多說了。


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

    所以,在沒有特殊需要的時(shí)候就不要去創(chuàng)建新的對象,盡量在值棧中尋找需要的內(nèi)容。比如,在一個(gè)方法返回值為"abc"時(shí),不要采用return new String("abc");的方法,而改變?yōu)槭褂胷eturn "abc";的方法,提高執(zhí)行效率。
      

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

    在進(jìn)行文件流的操作時(shí),沒有對輸入輸出流進(jìn)行關(guān)閉,或者關(guān)閉過程可能出錯(cuò),就會報(bào)這個(gè)bug。最好是在finally中將所有的輸入輸出流關(guān)閉。

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

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

    5.Suspicious reference comparison.
    (懷疑對兩個(gè)引用進(jìn)行比較)

    在對兩個(gè)對象(即兩個(gè)引用)進(jìn)行比較的時(shí)候,使用的不是equals()方法,而采用==的方式進(jìn)行,可能會出現(xiàn)結(jié)果與預(yù)期不一致的情況.
    當(dāng)然,在對兩個(gè)引用進(jìn)行equals()的時(shí)候,對象是需要重寫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 閱讀(1323) 評論(0)  編輯  收藏


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


    網(wǎng)站導(dǎo)航:
     
    主站蜘蛛池模板: 中文字幕亚洲一区二区三区| www免费黄色网| 国产成人亚洲精品青草天美| 国产成人免费片在线视频观看| 99re免费99re在线视频手机版| 人妻免费久久久久久久了| 亚洲三级在线观看| 久久久久久亚洲AV无码专区| 亚洲一区二区三区乱码A| 热久久精品免费视频| 免费观看的毛片大全| 免费人成视频在线观看网站| 任你躁在线精品免费| 亚洲免费在线观看| 美女黄频视频大全免费的| 亚洲欧洲无码一区二区三区| 亚洲国产片在线观看| 亚洲熟妇无码久久精品| 亚洲a在线视频视频| 亚洲国产精品高清久久久| 亚洲无码黄色网址| 亚洲黄片毛片在线观看| 国产免费啪嗒啪嗒视频看看| 日韩激情淫片免费看| 午夜视频在线在免费| 中国在线观看免费国语版| www视频免费看| 亚洲电影免费观看| 免费国产成人高清在线观看网站| 日本h在线精品免费观看| 色影音免费色资源| 免费观看国产网址你懂的| 亚洲成年人免费网站| 亚洲视频在线免费看| 亚州免费一级毛片| 日韩欧毛片免费视频| 无码日韩精品一区二区免费| 成人免费午夜视频| 国产一区二区三区在线免费观看| 免费在线观看中文字幕| 亚洲成av人片一区二区三区|