Findbugs缺陷等级对照表(5)

2019-03-15 17:27

This method contains a call to java.lang.Object.wait() which is not

guarded by conditional control flow. If the condition that the method intends to wait for has already happened, the thread could wait indefinitely.

VO: A volatile reference to an array doesn't treat the array elements as volatile

This declares a volatile reference to an array, which might not be what you want. With a volatile reference to an array, reads and writes of the reference to the array are treated as volatile, but the array elements are non-volatile. To get volatile array elements, you will need to use one of the atomic array classes in java.util.concurrent (provided in Java 5.0).

WS: Class's writeObject() method is synchronized but nothing else is

This class has a writeObject() method which is synchronized; however, no other method of the class is synchronized.

Wa: Wait not in loop in method

This method contains a call to java.lang.Object.wait() which is not in a loop. If the monitor is used for multiple conditions, the condition the caller intended to wait for might not be the one that actually occurred.

Dm: Method invokes dubious Boolean constructor; use Boolean.valueOf(...) instead

Creating new instances of java.lang.Boolean wastes memory, since Boolean objects are immutable and there are only two useful values of this

type. Use the Boolean.valueOf() method to create Boolean objects instead.

Dm: Explicit garbage collection; extremely dubious except in benchmarking code

Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.

In the past, situations where people have explicitly invoked the

garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive.

Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.

Dm: Method invokes dubious new String(String) constructor; just use the argument

Using the java.lang.String(String) constructor wastes memory because the object so constructed will be functionally indistinguishable from the String passed as a parameter. Just use the argument String directly.

Dm: Method invokes dubious String.equals(\String.length() == 0 instead

An object is compared to the empty String object using the equals() method here. Checking that the String object's length is zero may be faster, and removes String constants from the class file.

Dm: Method invokes toString() method on a String; just use the String

Calling String.toString() is just a redundant operation. Just use the String.

Dm: Method invokes dubious new String() constructor; just use \

Creating a new java.lang.String object using the no-argument constructor wastes memory because the object so created will be functionally

indistinguishable from the empty string constant \. Java guarantees that identical string constants will be represented by the same String object. Therefore, you should just use the empty string constant directly.

FI: Empty finalizer should be deleted

Empty finalize() methods are useless, so they should be deleted.

FI: Finalizer does nothing but call superclass finalizer

The only thing this finalize() method does is call the superclass's finalize() method, making it redundant. Delete it.

ITA: Method uses toArray() with zero-length array argument

This method uses the toArray() method of a collection derived class, and passes in a zero-length prototype array argument. It is more efficient to use

myCollection.toArray(new Foo[myCollection.size()])

If the array passed in is big enough to store all of the elements of the collection, then it is populated and returned directly. This avoids the need to create a second array (by reflection) to return as the result.

SBSC: 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 quadractic 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();

SIC: Should be a static inner class

This class is an inner class, but does not use its embedded reference to the object which created it. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary. If possible, the class should be made into a static inner class.

SIC: Could be refactored into a named static inner class

This class is an inner class, but does not use its embedded reference to the object which created it. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary. If possible, the class should be made into a static inner class. Since anonymous inner classes cannot be

marked as static, doing this will requiring refactoring the inner class so that it is a named inner class.

SIC: Could be refactored into a static inner class

This class is an inner class, but does not use its embedded reference to the object which created it except during construction of the inner object. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than

necessary. If possible, the class should be made into a static inner class. Since the reference to the outer object is required during construction of the inner instance, the inner class will need to be refactored so as to pass a reference to the outer instance to the constructor for the inner class.

SS: Unread field: should this field be static?

This class contains an instance final field that is initialized to a compile-time static value. Consider making the field static.

UPM: Private method is never called

This private method is never called. Although it is possible that the method will be invoked through reflection, it is more likely that the method is never used, and should be removed.

UrF: Unread field

This field is never read. Consider removing it from the class.

UuF: Unused field

This field is never used. Consider removing it from the class.


Findbugs缺陷等级对照表(5).doc 将本文的Word文档下载到电脑 下载失败或者文档不完整,请联系客服人员解决!

下一篇:四数据库写SQL题

相关阅读
本类排行
× 注册会员免费下载(下载后可以自由复制和排版)

马上注册会员

注:下载文档有可能“只有目录或者内容不全”等情况,请下载之前注意辨别,如果您已付费且无法下载或内容有问题,请联系我们协助你处理。
微信: QQ: