This rule reports occurrences of nested synchronized statements.
Nested synchronized statements should be avoided. Nested synchronized statements are either useless (if the lock objects are identical) or prone to deadlock.
Note that a closure or an anonymous inner class carries its own context (scope). A synchronized statement within a closure or an anonymous inner class defined within an outer synchronized statement does not cause a violation (though nested synchronized statements within either of those will).
Here is an example of code that produces a violation:
def myMethod() { synchronized(this) { // do something ... synchronized(this) { // do something else ... } } }
This rule reports uses of the synchronized keyword on methods. Synchronized methods are the same as synchronizing on 'this', which effectively make your synchronization policy public and modifiable by other objects. To avoid possibilities of deadlock, it is better to synchronize on internal objects.
Here is an example of code that produces a violation:
synchronized def myMethod() { // do stuff ... }
This rule reports uses of the synchronized blocks where the synchronization reference is 'this'. Doing this effectively makes your synchronization policy public and modifiable by other objects. To avoid possibilities of deadlock, it is better to synchronize on internal objects.
Here is an example of code that produces a violation:
def method3() { synchronized(this) { // do stuff ... } }
This rule reports uses of the System.runFinalizersOnExit() method.
Method calls to System.runFinalizersOnExit() should not be allowed. This method is inherently non-thread-safe, may result in data corruption, deadlock, and may affect parts of the program far removed from it's call point. It is deprecated, and it's use strongly discouraged.
Here is an example of code that produces a violation:
def method() { System.runFinalizersOnExit(true) }
This rule reports definition of the ThreadLocal fields that are not static and final.
ThreadLocal fields should be static and final. In the most common case a java.lang.ThreadLocal instance associates state with a thread. A non-static non-final java.lang.ThreadLocal field associates state with an instance-thread combination. This is seldom necessary and often a bug which can cause memory leaks and possibly incorrect behavior.
Here is an example of code that produces a violation:
private static ThreadLocal local1 = new ThreadLocal() private final ThreadLocal local2 = new ThreadLocal() protected ThreadLocal local3 = new ThreadLocal() ThreadLocal local4 = new ThreadLocal()
This rule reports uses of the Thread.yield() method.
Method calls to Thread.yield() should not be allowed. This method has no useful guaranteed semantics, and is often used by inexperienced programmers to mask race conditions.
Here is an example of code that produces a violation:
def method() { Thread.yield() }
This rule reports on long or double fields that are declared volatile.
Long or double fields should not be declared as volatile. Java specifies that reads and writes from such fields are atomic, but many JVM's have violated this specification. Unless you are certain of your JVM, it is better to synchronize access to such fields rather than declare them volatile. This rule flags fields marked volatile when their type is double or long or the name of their type is "Double" or "Long".
Here is an example of code that produces a violation:
def method() { private volatile double d private volatile long f }