Violations(多数内容来自他人blog与论坛讨论)

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()方法的。

以上来自：

http://www.cnblogs.com/hyddd/

http://hi.baidu.com/dinguangx/blog/item/7b4883ed01520adcb21cb143.html

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.

5. Performance - Private method is never called

Just delete it!!