Find Bugs自己的bug. Find Bugs‘ bug._dc: possible doublecheck on-优快云博客

博客讨论了在Java中静态变量的懒初始化问题，涉及线程安全和FindBugs检测工具。文章首先介绍了使用`synchronized`关键字的解决方案，然后转向自定义锁以避免效率问题，但FindBugs误报了双重检查锁定问题。最后，通过使用`volatile`关键字解决了这个问题，确保了可见性和避免指令重排序，消除了错误提示。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一个静态变量，特定情况才需要实例化.

private static ConcurrentMap<String, String> table2entity = null; //静态变量，特定情况才需要实例化.

static ConcurrentMap<String, String> getTable2entityMap() {
       if (table2entity == null) {
           table2entity = new ConcurrentHashMap<>();
           initTable2Entity();
       }

return table2entity;
}

用Find Bugs检测，会报：

Incorrect lazy initialization of static field.

Incorrect lazy initialization of static field org.xxx.Abc.table2entity in org.xxx.Abc..getTable2entityMap() [Troubling(14), Normal confidence]

主要原因是线程安全问题。多线程有可能会对该方法调用造成实例化多次。在该方法加synchronized，错误就可消除。但synchronized效率不高。

后来改成加自定义锁，

//private static byte lock[] = new byte[0];

private static final byte lock[] = new byte[0];

   static ConcurrentMap<String, String> getTable2entityMap() { //just create the Javabean files would use
       if (table2entity == null) {
           synchronized (lock) {
               if (table2entity == null) {
                   table2entity = new ConcurrentHashMap<>();
                   initTable2Entity();
               }
           }
       }
       return table2entity;
   }

然后Find Bugs看不懂了，报了以下错误，认为作了双重检测了。

Possible doublecheck on Field.

Possible doublecheck on org.xxx.Abc.table2entity in org.xxx.Abc..getTable2entityMap()[Troubling(14), Normal confidence]

到这里，假如认为，这是Find Bugs自己的bug, 那就需要了解另一个概念了——Java多线程双重加锁，及可能问题.

例子：

(指令重排优化导致)

private static ActivityLifeManager sInstance;

public static ActivityLifeManager getInstance() {
    if (sInstance == null) {
        synchronized (ActivityLifeManager.class) {
            if (sInstance == null) {
                sInstance = new ActivityLifeManager();
            }
        }
    }
    return sInstance;
}

双重加锁可能存在的一个问题就是

例如线程1已经分配了地址给instance 但是还没有初始化, 此时线程2 判断intance不是null 直接返回

解决：
volatile的一个语义是禁止指令重排序优化，也就保证了instance变量被赋值的时候对象已经是初始化过的，从而避免了上面说到的问题。

对于可见性，Java提供了volatile关键字来保证可见性。

　　当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。

一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义：

　　1）保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。

　　2）禁止进行指令重排序。

但是用volatile修饰之后就变得不一样了：

　　第一：使用volatile关键字会强制将修改的值立即写入主存；

　　第二：使用volatile关键字的话，当线程2进行修改时，会导致线程1的工作内存中缓存变量stop的缓存行无效（反映到硬件层的话，就是CPU的L1或者L2缓存中对应的缓存行无效）；

　　第三：由于线程1的工作内存中缓存变量stop的缓存行无效，所以线程1再次读取变量stop的值时会去主存读取。

另外需要注意：volatile没办法保证对变量的操作的原子性。

最终改为如下：

private static volatile ConcurrentMap<String, String> table2entity = null;

   static ConcurrentMap<String, String> getTable2entityMap() {
       if (table2entity == null) {
//           synchronized (HoneyContext.class) {
           synchronized (lock) {
               if (table2entity == null) {
                   table2entity = new ConcurrentHashMap<>();
                   initTable2Entity();
               }
           }
       }
       return table2entity;
   }

至此，错误提示消失。