为什么lockStatic在android中不稳定？

Question

我试图理解这个 android 实现，但我就是不明白为什么静态字段 lockStatic 是 volatile，因为它的使用只能通过 getLock 方法并且它是一个同步块，所以应该没有并发或对象发布问题。

abstract public class WakefulIntentService extends IntentService {
    abstract protected void doWakefulWork(Intent intent);
    static final String NAME=
      "com.commonsware.cwac.wakeful.WakefulIntentService";
    static final String LAST_ALARM="lastAlarm";

    private static volatile PowerManager.WakeLock lockStatic=null;

    synchronized private static PowerManager.WakeLock getLock(Context context) {
       if (lockStatic == null) {
           PowerManager mgr = (PowerManager)context.getSystemService(Context.POWER_SERVICE);

           lockStatic=mgr.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, NAME);
           lockStatic.setReferenceCounted(true);
       }

       return(lockStatic);
    }

如果允许 lockStatic 以任何其他方式访问，我认为只有 volatile 需要，但它的私有且唯一处理它的方法是 getLock 方法。这只是一个断言还是背后有其他原因？

提前感谢您为解决此问题提供的任何帮助。

WeakfullIntentService

Answer 1

在代码示例中，不需要volatile，因为该变量只能在该synchronized 块中访问。

但是，synchronized 可能有点过于昂贵，尤其是考虑到对该方法的多数调用只是读取变量并返回。每次阅读都用synchronized 包围感觉太沉重了。因此我们有所谓的双重检查模式，它在大多数情况下都会避免synchronized

if(var==null)
    synchronized(lock)
        if(var==null)         // double-check
            var = something
return var

（但是，OP 的代码示例不是双重检查锁定；它是全时锁定。）

在双重检查锁定中，通常var 应该是volatile——但并非总是如此。如果分配给它的对象是原始的（如int）或不可变的（如String），则非易失性是可以的。

还有更多情况下非易失性是可以的。这需要对用例进行仔细评估。例如，java.util.concurrent（例如ReentrantLock）中的所有实用程序类的设计方式使其能够在“不安全的发布”中存活。当它们用于双重检查锁定模式时，它们不必是volatile。看到WakeLock的源码，我相信在双重检查锁定中也不需要volatile。

当然，这有点过分了。因此，除非您确切知道自己在做什么，否则请放心使用volatile。 volatile 读取并不比普通读取贵多少。