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 閱讀(1327) 評論(0)  編輯  收藏


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


          網站導航:
           
          主站蜘蛛池模板: 错那县| 连云港市| 荆州市| 台南市| 依安县| 厦门市| 镇康县| 东明县| 嘉义市| 石台县| 花莲市| 揭东县| 博乐市| 鄢陵县| 临桂县| 朝阳区| 密云县| 保亭| 文成县| 阳西县| 呈贡县| 哈尔滨市| 湛江市| 百色市| 阳原县| 家居| 昭通市| 瑞安市| 平安县| 上栗县| 吉水县| 寿阳县| 玉林市| 宜川县| 涟水县| 额济纳旗| 南和县| 孝感市| 庄浪县| 东莞市| 新建县|