在这种情况下，FindBugs的'JLM_JSR166_UTILCONCURRENT_MONITORENTER'可以安全地忽略(is FindBugs 'JLM_JSR166_UTILCONCURRENT_MONITORENTER' safe to ignore in this case)

 我有一个我需要使用的库，它有一个静态值的危险初始化（类已被剥离到示例的最小值）： 
 
public TheirBaseClass {
    public static String PathToUse = null;

    public BaseClass(){
        PathToUse = "Configured";

        // ... 
        // do some other stuff with other side effects 
        // ...
    }
}
 
 我有一个案例，我尝试从值ConfigValue读取而不实例化类（以避免一些副作用）。 
 
Paths.get(TheirBaseClass.PathToUse).toFile()....
 
 这会导致NullPointerException 
 
 因为我需要使用这个类，所以我希望继承它，并尝试采取措施确保在访问静态时进行初始化。 
 
public MyBaseClass extends TheirBaseClass{

    private static final AtomicBoolean isInitialized = new AtomicBoolean(false);

    static {
        MyBaseClass.Initialize();
    }

    public static void Initialize(){
        // FindBugs does not like me synchronizing on a concurrent object
        synchronized(isInitialized){
            if( isInitialized.get() ){
                return;
            }
            new TheirBaseClass();
            isInitialized.set(true);
        }
    }

    public MyBaseClass(){
        super();
    }

}
 
 这让我可以 
 
MyBaseClass.Initialize();
Paths.get(MyBaseClass.PathToUse).toFile()....
 
 这似乎运作得相当好（并解决了我们一直有的其他一些幻影缺陷）。 它允许TheirBaseClass自然地运行，同时允许我在我可能需要的几种情况下安全地强制初始化。 
 
 但是，当我针对此代码运行FindBugs时，我得到JLM_JSR166_UTILCONCURRENT_MONITORENTER 。 阅读完描述后，我同意使用AtomicBoolean可能会有危险，因为其他人可能会改变这个值，但...... 
 
 
 
 我认为在这种情况下可以安全地忽略（但有疑问） 
 
 
 我通常更喜欢重写代码而不是放置一个忽略标记 
 
 
 我实际上在做一些危险的事情（而且看不到它）？ 有一个更好的方法吗？ 
 
 不幸的是，使用不同的TheirBaseClass不是一种选择。 
 
 有关 
 
 
 
 Java静态初始化程序是否安全？ 
 

I have a library that I am required to use that has a dangerous initialization of a static value (the classes have been stripped down to the minimum for the example):
 
public TheirBaseClass {
    public static String PathToUse = null;

    public BaseClass(){
        PathToUse = "Configured";

        // ... 
        // do some other stuff with other side effects 
        // ...
    }
}
 
I have a case where I attempt to read from the value ConfigValue without instantiating the class (to avoid some of the sideeffects).
 
Paths.get(TheirBaseClass.PathToUse).toFile()....
 
This causes a NullPointerException
 
Because I am required to use this class, I am looking to inherit from it, and attempt to take action to ensure that initialization has taken place when accessing the static.
 
public MyBaseClass extends TheirBaseClass{

    private static final AtomicBoolean isInitialized = new AtomicBoolean(false);

    static {
        MyBaseClass.Initialize();
    }

    public static void Initialize(){
        // FindBugs does not like me synchronizing on a concurrent object
        synchronized(isInitialized){
            if( isInitialized.get() ){
                return;
            }
            new TheirBaseClass();
            isInitialized.set(true);
        }
    }

    public MyBaseClass(){
        super();
    }

}
 
Which allows me to 
 
MyBaseClass.Initialize();
Paths.get(MyBaseClass.PathToUse).toFile()....
 
This seems to be working reasonably well (and resolves some other phantom defects we've been having). It allows TheirBaseClass to function naturally, while allowing me to safely force initialization in the couple of cases I may need to.
 
However when I run FindBugs against this code, I get JLM_JSR166_UTILCONCURRENT_MONITORENTER. After reading the description, I agree that the use of AtomicBoolean could be dangerous because someone else could change the value, but...
 
 
 
I think its safe to ignore in this case (but have a doubt)
 
 
I generally prefer to rewrite code than put an ignore marker in place
 
 
Am I actually doing something dangerous (and just don't see it)? Is there a better way to do this? 
 
Unfortunately, using a different TheirBaseClass is not an option.
 
Related
 
 
 
Are Java static initializers thread safe?
 

原文：https://stackoverflow.com/questions/39149166