Violations(多數內容來自他人blog與論壇討論)
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。
意思應該是:本地變量存儲了閑置不用的對象,也就是說這個變量是多余的。
意思應該是:本地變量存儲了閑置不用的對象。
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.
看下面代碼:
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();就可以了。
這里我遇到了這樣的問題:
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在下面只被重復賦值一次,而前面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.
先看下面代碼:
//

String v = request.getParameter("v");
//

PrintWriter out = response.getWriter();
out.print("協議版本號不對,v="+v);
out.close();
//

}
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
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:
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
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!!