Non-primitive fields should not be "volatile" sonar检查问题

今天解决sonar问题，下面的这段代码竟然报出了Non-primitive fields should not be "volatile" 的错误，很诧异，这可是多线程下标准的单例模式啊。

 

public class SLSHeadersManger {
    private static volatile SLSHeadersManger instance;


    private SLSHeadersManger() {

    }

    public static SLSHeadersManger getInstance() {
        if (instance == null) {
            synchronized (SLSHeadersManger.class) {
                if (instance == null) {
                    instance = new SLSHeadersManger();
                }
            }
        }
        return instance;
    }
」

sonar的描述如下，大体意思就是因为对象不是final的，所以对象引用可以变化，如果引用发生了变化，那么仍然解决不了多线程不可见的问题。但是单例模式下就需要这种方式啊，因为代码逻辑上保证了对象引用只会有一个。

 

Non-primitive fields should not be "volatile"

• Bug
• 次要

Marking an array volatile means that the array itself will always be read fresh and never thread cached, but the items in the array will not be. Similarly, marking a mutable object field volatile means the object reference is volatile but the object itself is not, and other threads may not see updates to the object state.

This can be salvaged with arrays by using the relevant AtomicArray class, such as AtomicIntegerArray, instead. For mutable objects, the volatile should be removed, and some other method should be used to ensure thread-safety, such as synchronization, or ThreadLocal storage.

Noncompliant Code Example

private volatile int [] vInts;  // Noncompliant
private volatile MyObj myObj;  // Noncompliant

Compliant Solution

private AtomicIntegerArray vInts;
private MyObj myObj;

See

• CERT, CON50-J. - Do not assume that declaring a reference volatile guarantees safe publication of the members of the referenced object