Findbugs缺陷等级对照表

FindBugs Bug Descriptions

This document lists the standard bug patterns reported by version 0.8.5.

Summary

序等号 级 14 A Description Category Correctness Correctness EC: Call to equals() with null argument 调用Equal方法的参数为空 EC: Call to equals() comparing different 15 A interface types 调用Equal方法去比较不同的接口类型 EC: Call to equals() comparing different 16 A types 调用Equal方法去比较不同的数据类型 ES: Comparison of String objects using == 17 A or != 使用== 或者 != 去比较字符串或对象 IJU: TestCase implements setUp but doesn't call super.setUp() 29 B 测试实例实现了setUp（）但没有调用super.setUp（） 36 A NP: Null pointer dereference in method 方法中存在空指针 Correctness Correctness Correctness Correctness Correctness NP: Null pointer dereference in method on 37 A exception path 方法中存在某异常路径中的空指针 NP: Possible null pointer dereference in 38 A method 方法中存在可能在运行时出现的空指针异常 Correctness NP: Possible null pointer dereference in method on exception path 39 A Correctness 方法中存在可能在某些异常路径下出现的空指针异常 Nm: Class defines equal(); should it be equals()? 41 C 类中定义了equal方法，但是没有重写Correctness java.lang.Object中equal方法，这也有可能是有意这么做的 42 B 43 B Nm: Confusing method names 一些方法名只有大小写的区别，容易混绕 Nm: Confusing method name 方法名和其超类的类名相同 Correctness Correctness Nm: Class defines hashcode(); should it be hashCode()? 44 C 类中定义了hashCode()方法，但是没有重写java.lang.Object中的hashCode()方法，这也有可能是有意这么做的 Nm: Class defines tostring(); should it be toString()? 45 C 类中定义了tostring()方法，但是没有重写java.lang.Object中的tostring()方法，这也有可能是有意这么做的 46 A Nm: Very confusing method names 一些方法名只有大小写的区别，特别容易混绕 Correctness Correctness Correctness Correctness ODR: Method may fail to close database 47 A resource 方法可能没有关闭数据源 ODR: Method may fail to close database 48 A resource on exception 方法在异常时可能无法关闭数据源 49 A OS: Method may fail to close stream 方法可能没有关闭流 Correctness Correctness Correctness OS: Method may fail to close stream on 50 A exception 方法在异常时可能无法关闭流 RCN: Redundant comparision to null of 53 C previously checked value 预测值的几个比较的值中有null值 54 C 57 C RCN: Redundant comparison to null 几个比较的值中有null值 RV: Method ignores return value 方法忽略了返回值 Correctness Correctness Correctness SI: Static initializer for class creates instance before all static final fields 59 A assigned Correctness 类的静态初始化器实例化一个该类对象要在所有的常量属性定义之前 72 C UwF: Unwritten field 永远不会写到的字段，所有读取将返回默认值 Correctness 83 A 86 A MS: Field isn't final but should be 字段应该为常量的却不是常量 IS2: Inconsistent synchronization 类中字段访问不同步 Malicious code vulnerability Multithreaded correctness ML: Method synchronizes on an updated field 方法从一个可变字段对象的引用中同步。这是不太Multithreaded 88 A 可能有用的，因为不同的线程可以在不同的对象上correctness 同步。 Ru: Invokes run on a thread (did you mean to start it instead?) Multithreaded 92 C 当一个类继承Runnable接口时候，还去调用run方correctness 法，实际上只需要调用Start方法就可以启动新的线程， 93 C SC: Constructor invokes Thread.start() 构造函数调用Thread.start（） Multithreaded correctness Dm: Method invokes dubious new String(String) constructor; just use the 102 C argument 方法中调用String的构造函数来新建一个字符串，直接使用其参数即可 Performance Dm: Method invokes dubious String.equals(\103 A instead Performance 方法中调用了不确定的String.equals(\，使用String.length() == 0来代替 Dm: Method invokes toString() method on a String; just use the String 104 A Performance 方法中用一个字符串去调用方法toString（），用String就可以了 Dm: Method invokes dubious new String() constructor; just use \ 105 C Performance 方法中新建一个空字符串用new String（）。直接用“”就可以了 FI: Empty finalizer should be deleted 106 C 空finalizer（）方法是没有用的，所以应该予Performance 以删除 114 C 115 C UPM: Private method is never called 这个私有方法从来没有被调用到 UrF: Unread field 读不到的字段，应该从类中删除 Performance Performance Performance 116 C UuF: Unused field 读不到的字段，应该从类中删除 Descriptions

AM: Creates an empty jar file entry

The code calls putNextEntry(), immediately followed by a call to

closeEntry(). This results in an empty JarFile entry. The contents of the entry should be written to the JarFile between the calls to putNextEntry() and closeEntry().

AM: Creates an empty zip file entry

The code calls putNextEntry(), immediately followed by a call to

closeEntry(). This results in an empty ZipFile entry. The contents of the entry should be written to the ZipFile between the calls to putNextEntry() and closeEntry().

BIT: Incompatible bit masks

This method compares an expression of the form (a & C) to D, which will always compare unequal due to the specific values of constants C and D. This may indicate a logic error or typo.

BIT: Incompatible bit masks

This method compares an expression of the form (a & 0) to 0, which will always compare equal. This may indicate a logic error or typo.

BIT: Incompatible bit masks

This method compares an expression of the form (a | C) to D. which will always compare unequal due to the specific values of constants C and D. This may indicate a logic error or typo.

Typically, this bug occurs because the code wants to perform a

membership test in a bit set, but uses the bitwise OR operator (\instead of bitwise AND (\

BOA: Class overrides a method implemented in super class Adapter wrongly

This method overrides a method found in a parent class, where that class is an Adapter that implements a listener defined in the

java.awt.event or javax.swing.event package. As a result, this method will not get called when the event occurs.

BRSA: Method attempts to access a result set field with index 0

A call to getXXX or updateXXX methods of a result set was made where the field index is 0. As ResultSet fields start at index 1, this is always a mistake.

CN: Class implements Cloneable but does not define or use clone method

Class implements Cloneable but does not define or use the clone method.

CN: clone method does not call super.clone()

This class defines a clone() method that does not call super.clone(), and is not final. If this class (\A\B\and the subclass B calls super.clone(), then it is likely that B's clone() method will return an object of type A, which violates the standard contract for clone().

If all clone() methods call super.clone(), then they are guaranteed to use Object.clone(), which always returns an object of the correct type.

Co: Covariant compareTo() method defined

This class defines a covariant version of compareTo(). To correctly override the compareTo() method in the Comparable interface, the parameter of compareTo() must have type java.lang.Object.

DE: Method might drop exception

This method might drop an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.

DE: Method might ignore exception

This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.

Dm: Method invokes System.exit(...)

Invoking System.exit shuts down the entire Java virtual machine. This should only been done when it is appropriate. Such calls make it hard or impossible for your code to be invoked by other code. Consider throwing a RuntimeException instead.

EC: Call to equals() with null argument

This method calls equals(Object), passing a null value as the argument. According to the contract of the equals() method, this call should always return false.

EC: Call to equals() comparing different interface types

This method calls equals(Object) on two references of unrelated

interface types (neither is a subtype of the other). According to the contract of equals(), objects of different classes should always

compare as unequal. Note that it is possible that the program contains classes that implement both interfaces, so the comparison may be valid. However, it is worth inspecting closely.

EC: Call to equals() comparing different types

This method calls equals(Object) on two references of different types. According to the contract of equals(), objects of different classes should always compare as unequal; therefore, it is likely that the result of this comparision will always be false at runtime.

ES: Comparison of String objects using == or !=

This code compares java.lang.String objects for reference equality using the == or != operators. Unless both strings are either constants in a source file, or have been interned using the String.intern() method, the same string value may be represented by two different String objects. Consider using the equals(Object) method instead.

Eq: Covariant equals() method defined

This class defines a covariant version of equals(). To correctly

override the equals() method in java.lang.Object, the parameter of equals() must have type java.lang.Object.

Eq: Covariant equals() method defined, Object.equals(Object)

inherited

This class defines a covariant version of the equals() method, but calls the normal equals(Object) method defined in the base java.lang.Object class. The class should probably define a non-covariant version of equals(). (I.e., a method with the signature boolean equals(java.lang.Object).

FI: Explicit invocation of finalizer

This method contains an explicit invocation of the finalize() method on an object. Because finalizer methods are supposed to be executed once, and only by the VM, this is a bad idea.

FI: Finalizer does not call superclass finalizer

This finalize() method does not make a call to its superclass's finalize() method. So, any finalizer actions defined for the superclass will not be performed. Add a call to super.finalize().

FI: Finalizer nullifies superclass finalizer

This empty finalize() method explicitly negates the effect of any

finalizer defined by its superclass. Any finalizer actions defined for the superclass will not be performed. Unless this is intended, delete this method.

HE: Class defines equals() but not hashCode()

This class overrides equals(Object), but does not override

hashCode(). Therefore, the class may violate the invariant that equal objects must have equal hashcodes.

HE: Class defines equals() and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the

object by the VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't want to define a hashCode method, and/or don't believe the object will ever be put into a HashMap/Hashtable, define the hashCode() method to throw UnsupportedOperationException.

HE: Class defines hashCode() but not equals()

This class defines a hashCode() method but not an equals()

method. Therefore, the class may violate the invariant that equal objects must have equal hashcodes.

HE: Class defines hashCode() and uses Object.equals()

This class defines a hashCode() method but inherits its equals() method from java.lang.Object (which defines equality by comparing object

references). Although this will probably satisfy the contract that equal objects must have equal hashcodes, it is probably not what was intended by overriding the hashCode() method. (Overriding hashCode() implies that the object's identity is based on criteria more complicated than simple reference equality.)

HE: Class inherits equals() and uses Object.hashCode()

This class inherits equals(Object) from an abstract superclass, and hashCode() from from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the

VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't want to define a hashCode method, and/or don't believe the object will ever be put into a HashMap/Hashtable, define the hashCode() method to throw UnsupportedOperationException.

IC: Initialization circularity

A circularity was detected in the static initializers of the two classes referenced by the bug instance. Many kinds of unexpected behavior may arise from such circularity.

IJU: TestCase implements setUp but doesn't call super.setUp()

Class is a JUnit TestCase and implements the setUp method. The setUp method should call super.setUp(), but doesn't.

IMSE: Dubious catching of IllegalMonitorStateException

IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).

It: Iterator next() method can't throw NoSuchElement exception

This class implements the java.util.Iterator interface. However, its next() method is not capable of throwing

java.util.NoSuchElementException. The next() method should be changed so it throws NoSuchElementException if is called when there are no more elements to return.

MF: Class defines field that obscures a superclass field

This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.

MF: Method defines a variable that obscures a field

This method defines a local variable with the same name as a field in this class or a superclass. This may cause the method to read an

uninitialized value from the field, leave the field uninitialized, or both.

MWN: Mismatched notify()

This method calls Object.notify() or Object.notifyAll() without obviously holding a lock on the object. Calling notify() or notifyAll() without a lock held will result in an IllegalMonitorStateException being thrown.

MWN: Mismatched wait()

This method calls Object.wait() without obviously holding a lock on the object. Calling wait() without a lock held will result in an IllegalMonitorStateException being thrown.

NP: Null pointer dereference in method

A null pointer is dereferenced here. This will lead to a NullPointerException when the code is executed.

NP: Null pointer dereference in method on exception path

A pointer which is null on an exception path is dereferenced here. This will lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune

infeasible exception paths, this may be a false warning.

Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible.

NP: Possible null pointer dereference in method

A reference value dereferenced here might be null at runtime. This may lead to a NullPointerException when the code is executed.

NP: Possible null pointer dereference in method on exception path

A reference value which is null on some exception control path is

dereferenced here. This may lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning.

Also note that FindBugs considers the default case of a switch

statement to be an exception path, since the default case is often infeasible.

NS: Questionable use of non-short-circuit logic

This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.

Nm: Class defines equal(); should it be equals()?

This class defines a method equal(Object). This method does not

override the equals(Object) method in java.lang.Object, which is probably what was intended.

Nm: Confusing method names

The referenced methods have names that differ only by capitalization.

Nm: Confusing method name

This method has the same name as the superclass of the class it is

defined in.

Nm: Class defines hashcode(); should it be hashCode()?

This class defines a method called hashcode(). This method does not override the hashCode() method in java.lang.Object, which is probably what was intended.

Nm: Class defines tostring(); should it be toString()?

This class defines a method called tostring(). This method does not override the toString() method in java.lang.Object, which is probably what was intended.

Nm: Very confusing method names

The referenced methods have names that differ only by capitalization.

ODR: Method may fail to close database resource

The method creates a database resource (such as a database connection or row set), does not assign it to any fields, pass it to other

methods, or return it, and does not appear to close the object on all paths out of the method. Failure to close database resources on all paths out of a method may result in poor performance, and could cause the application to have problems communicating with the database.

ODR: Method may fail to close database resource on exception

The method creates a database resource (such as a database connection or row set), does not assign it to any fields, pass it to other

methods, or return it, and does not appear to close the object on all exception paths out of the method. Failure to close database

resources on all paths out of a method may result in poor performance, and could cause the application to have problems communicating with the database.

OS: Method may fail to close stream

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 the stream on all 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.

OS: 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.

PZLA: Consider returning a zero length array rather than null

It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.

On the otherhand, using null to indicate \question\File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

RC: Suspicious reference comparison

This method compares two reference values using the == or != operator, where the correct way to compare instances of this type is generally with the equals() method. Examples of classes which should generally not be compared by reference are java.lang.Integer, java.lang.Float, etc.

RCN: Redundant comparision to null of previously checked value

This method contains a redundant comparison of a reference value to null. Two types of redundant comparison are reported:

Both values compared are definitely null

? One value is definitely null and the other is definitely not null

?

This particular warning generally indicates that a value known not to be null was checked against null. While the check is not necessary, it may simply be a case of defensive programming.

RCN: Redundant comparison to null

This method contains a redundant comparison of a reference value to null. Two types of redundant comparison are reported:

Both values compared are definitely null

? One value is definitely null and the other is definitely not null

?

This particular warning represents two specific kinds of redundant comparisions:

1. A value was dereferenced, and later explicitly compared to null: this often indicates an error in the method

2. A literal null value was explicitly compared to null: this may indicate that the method was modified without complete understanding of the invariants of the method

RR: Method ignores results of InputStream.read()

This method ignores the return value of one of the variants of

java.io.InputStream.read() which can return multiple bytes. If the return value is not checked, the caller will not be able to correctly handle the case where fewer bytes were read than the caller requested. This is a particularly insidious kind of bug, because in many programs, reads from input streams usually do read the full amount of data requested, causing the program to fail only sporadically.

RR: Method ignores results of InputStream.skip()

This method ignores the return value of java.io.InputStream.skip() which can skip multiple bytes. If the return value is not checked, the caller will not be able to correctly handle the case where fewer bytes were skipped than the caller requested. This is a particularly insidious kind of bug, because in many programs, skips from input

streams usually do skip the full amount of data requested, causing the program to fail only sporadically. With Buffered streams, however, skip() will only skip data in the buffer, and will routinely fail to skip the requested number of bytes.

RV: Method ignores return value

The return value of this method should be checked.

SA: Self assignment of field

This method contains a self assignment of a field; e.g.

int x;

public void foo() {

x = x; }

Such assignments are useless, and may indicate a logic error or typo.

SI: Static initializer for class creates instance before all static final fields assigned

The class's static initializer creates an instance of the class before all of the static final fields are assigned.

SIO: Unnecessary type check done using instanceof operator

Type check performed using the instanceof operator where it can be statically determined whether the object is of the type requested.

SW: Certain swing methods should only be invoked from the Swing event thread

(From JDC Tech Tip): The Swing methods show(), setVisible(), and pack() will create the associated peer for the frame. With the creation of the peer, the system creates the event dispatch thread. This makes things problematic because the event dispatch thread could be notifying

listeners while pack and validate are still processing. This situation could result in two threads going through the Swing component-based GUI -- it's a serious flaw that could result in deadlocks or other related threading issues. A pack call causes components to be realized. As they are being realized (that is, not necessarily visible), they could trigger listener notification on the event dispatch thread.

Se: Non-transient non-serializable instance field in serializable class

This Serializable class defines a non-primitive instance field which is neither transient, Serializable, or java.lang.Object, and does not appear to implement the Externalizable interface or the readObject() and

writeObject() methods. Objects of this class will not be deserialized correctly if a non-Serializable object is stored in this field.

Se: serialVersionUID isn't final

This class defines a serialVersionUID field that is not final. The

field should be made final if it is intended to specify the version UID for purposes of serialization.

Se: serialVersionUID isn't long

This class defines a serialVersionUID field that is not long. The field should be made long if it is intended to specify the version UID for purposes of serialization.

Se: serialVersionUID isn't static

This class defines a serialVersionUID field that is not static. The field should be made static if it is intended to specify the version UID for purposes of serialization.

Se: Class is Serializable but its superclass doesn't define a void constructor

This class implements the Serializable interface and its superclass does not. When such an object is deserialized, the fields of the superclass need to be initialized by invoking the void constructor of the

superclass. Since the superclass does not have one, serialization and deserialization will fail at runtime.

Se: Class is Externalizable but doesn't define a void constructor

This class implements the Externalizable interface, but does not define a void constructor. When Externalizable objects are deserialized, they first need to be constructed by invoking the void constructor. Since this class does not have one, serialization and deserialization will fail at runtime.

SnVI: Class is Serializable, but doesn't define serialVersionUID

This class implements the Serializable interface, but does not define a serialVersionUID field. A change as simple as adding a reference to a .class object will add synthetic fields to the class, which will unfortunately change the implicit serialVersionUID (e.g., adding a reference to String.class will generate a static field

class$java$lang$String). Also, different source code to bytecode compilers may use different naming conventions for synthetic variables generated for references to class objects or inner classes. To ensure

interoperability of Serializable across versions, consider adding an explicit serialVersionUID.

UCF: Useless control flow in method

This method contains a useless control flow statement. Often, this is caused by inadvertently using an empty statement as the body of an if statement, e.g.:

if (argv.length == 1);

System.out.println(\

UI: Usage of GetResource may be unsafe if class is extended

Calling this.getClass().getResource(...) could give results other than expected if this class is extended by a class in another package.

UR: Uninitialized read of field in constructor

This constructor reads a field which has not yet been assigned a

value. This is often caused when the programmer mistakenly uses the field instead of one of the constructor's parameters.

UwF: Unwritten field

This field is never written. All reads of it will return the default value. Check for errors (should it have been initialized?), or remove it if it is useless.

EI: Method may expose internal representation by returning reference to mutable object

Returning a reference to a mutable object value stored in one of the object's fields exposes the internal representation of the object. If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Returning a new copy of the object is better approach in many situations.

FI: Finalizer should be protected, not public

A class's finalize() method should have protected access, not public.

MS: Method may expose internal static state by storing a mutable object into a static field

This code stores a reference to an externally mutable object into a

static field. If unchecked changes to the mutable object would

compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.

MS: Field isn't final and can't be protected from malicious code

A mutable static field could be changed by malicious code or by

accident from another package. Unfortunately, the way the field is used doesn't allow any easy fix to this problem.

MS: Public static method may expose internal representation by returning array

A public static method returns a reference to an array that is part of the static state of the class. Any code that calls this method can freely modify the underlying array. One fix is to return a copy of the array.

MS: Field should be both final and package protected

A mutable static field could be changed by malicious code or by accident from another package. The field could be made package protected and/or made final to avoid this vulnerability.

MS: Field is a mutable array

A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.

MS: Field is a mutable Hashtable

A final static field references a Hashtable and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the Hashtable.

MS: Field should be moved out of an interface and made package protected

A final static field that is defined in an interface references a

mutable object such as an array or hashtable. This mutable object could be changed by malicious code or by accident from another package. To

solve this, the field needs to be moved to a class and made package protected to avoid this vulnerability.

MS: Field should be package protected

A mutable static field could be changed by malicious code or by accident. The field could be made package protected to avoid this vulnerability.

MS: Field isn't final but should be

A mutable static field could be changed by malicious code or by

accident from another package. The field could be made final to avoid this vulnerability.

2LW: Wait with two locks held

Waiting on a monitor while two locks are held may cause

deadlock. Performing a wait only releases the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining closely.

DC: Possible double check of field

This method may contain an instance of double-checked locking. This idiom is not correct according to the semantics of the Java memory model. For more information, see the web page

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.

IS2: Inconsistent synchronization

The fields of this class appear to be accessed inconsistently with respect to synchronization. This bug report indicates that the bug pattern detector judged that

1. The class contains a mix of locked and unlocked accesses,

2. At least one locked access was performed by one of the class's own methods, and

3. The number of unsynchronized field accesses (reads and writes) was no more than one third of all accesses, with writes being weighed twice as high as reads A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe.

You can select the nodes labeled \code locations where the detector believed that a field was accessed without synchronization.

Note that there are various sources of inaccuracy in this detector; for example, the detector cannot statically detect all situations in which a lock is held. Also, even when the detector is accurate in

distinguishing locked vs. unlocked accesses, the code in question may still be correct.

This description refers to the \which has more accurate ways of detecting locked vs. unlocked accesses than the older \

LI: Incorrect lazy initialization of static field

This method contains an unsynchronized lazy initialization of a non-volatile static field. Because the compiler or processor may reorder instructions, threads are not guaranteed to see a completely

initialized object, if the method can be called by multiple threads. You can make the field volatile to correct the problem. For more information, see the Java Memory Model web site.

ML: Method synchronizes on an updated field

This method synchronizes on an object references from a mutable field. This is unlikely to have useful semantics, since different threads may be synchronizing on different objects.

NN: Naked notify in method

A call to notify() or notifyAll() was made without any (apparent) accompanying modification to mutable object state. In general, calling a notify method on a monitor is done because some condition another thread is waiting for has become true. However, for the condition to be meaningful, it must involve a heap object that is visible to both threads.

This bug does not necessarily indicate an error, since the change to mutable object state may have taken place in a method which then called the method containing the notification.

No: Using notify() rather than notifyAll() in method

This method calls notify() rather than notifyAll(). Java monitors are

often used for multiple conditions. Calling notify() only wakes up one thread, meaning that the thread woken up might not be the one waiting for the condition that the caller just satisfied.

RS: Class's readObject() method is synchronized

This serializable class defines a readObject() which is

synchronized. By definition, an object created by deserialization is only reachable by one thread, and thus there is no need for readObject() to be synchronized. If the readObject() method itself is causing the object to become visible to another thread, that is an example of very dubious coding style.

Ru: Invokes run on a thread (did you mean to start it instead?)

This method explicitly invokes run() on an object. In general,

classes implement the Runnable interface because they are going to have their run() method invoked in a new thread, in which case Thread.start() is the right method to call.

SC: Constructor invokes Thread.start()

The constructor starts a thread. This is likely to be wrong if the class is ever extended/subclassed, since the thread will be started before the subclass constructor is started.

SP: Method spins on field

This method spins in a loop which reads a field. The compiler may legally hoist the read out of the loop, turning the code into an infinite loop. The class should be changed so it uses proper synchronization (including wait and notify calls).

UG: Unsynchronized get method, synchronized set method

This class contains similarly-named get and set methods where the set method is synchronized and the get method is not. This may result in incorrect behavior at runtime, as callers of the get method will not necessarily see a consistent state for the object. The get method should be made synchronized.

UW: Unconditional wait in method

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.

本文来源：https://www.bwwdw.com/article/5jzr.html