正确使用volatile关键字

Question

我觉得我有在Java中volatile关键字一个不错的主意，但我想重新分解了一些代码，我认为这将是使用它是一个好主意。

我有一个类，基本上工作作为一个数据库缓存。它拥有一堆的对象，它已经从数据库中读取，用于对那些对象的请求，然后偶尔刷新数据库（基于超时）。继承人的骨架

public class Cache 
{ 
    private HashMap mappings =....; 
    private long last_update_time; 
    private void loadMappingsFromDB() 
    { 
     //.... 
    } 
    private void checkLoad() 
    { 
     if(System.currentTimeMillis() - last_update_time > TIMEOUT) 
      loadMappingsFromDB(); 
    } 
    public Data get(ID id) 
    { 
     checkLoad(); 
     //.. look it up 
    } 
} 

所以值得关注的是loadMappingsFromDB可能是一个高延迟操作和多数民众无法接受的，所以最初我以为我可以旋转了一个线程缓存启动，然后只是有它睡觉，然后更新在后台缓存。但后来我需要同步我的课程（或地图）。然后我只是偶尔进行一次大的停顿，让每个缓存访问速度变慢。

当时我就想，为什么不使用volatile

我可以定义绘图参照挥发性

private volatile HashMap mappings =....; 

，然后在get（或其他地方使用该映射变量）我只想让本地参考副本：

public Data get(ID id) 
{ 
    HashMap local = mappings; 
    //.. look it up using local 
} 

然后后台线程会加载到临时表中，然后交换r类别中的推理

HashMap tmp; 
//load tmp from DB 
mappings = tmp;//swap variables forcing write barrier 

这种方法是否有意义？它实际上是线程安全的吗？

Answer 1

有在现有的回答这个问题的一些误传。使用volatile实际上是确保线程安全性的一个很好的步骤。参见IBM的Peter Haggar的item 3 in Dispelling Java programming language myths。 Haggar给出了一些背景和示例，但是坚果是这样的：

那么，原子操作怎么能不是线程安全的呢？主要的一点是它们可能确实是线程安全的，但不能保证它们是。允许Java线程将变量的私有副本与主内存分开。

通过使用volatile，您将保证线程指向主内存，而不是使用您不知道或期望的变量的私有副本。

要回答你的问题，那么：是的，你的策略是安全的。

编辑：
为了应对另一篇文章，这里是the JLS section about volatile fields。

Answer 2

我认为这种一般的方法是有效的（重新加载缓存在后台线程，而不是阻止访问缓存，而负载是通过将数据装入进步分离实例），但我不知道什么声明参考为volatile真的给你。

您可以轻松地使用get(id)方法和loadMappingsFromDB()中覆盖引用（而不是来自DB的全部加载，但只是重新分配mappings）在同一个锁上同步的部分。

老实说，虽然我会考虑重新使用已建立的缓存库，例如EhCache，它具有后台加载或启动时加载功能，因为很久以前，这些库可能已经解决了所有的同步问题。可以回去担心你的应用程序的逻辑，而不是自酿缓存的低级别的安全性。

Answer 3

实际上，你提出的做法是有道理的，即使没有使用“挥发性”关键字。由于参考分配（mappings = tmp;）是一个原子操作（转换为一个机器指令）没有记忆不一致的机会：
http://java.sun.com/docs/books/tutorial/essential/concurrency/atomic.html
读取和写入原子参考变量和最原始的变量（所有类型除了长和双）。

'volatile'关键字后面的想法是，如果你在时间T改变这个变量，任何其他在时间T + x（x> 0）访问它的线程都会看到新的值。否则，即使在更改值后，仍有一段时间，其他线程可能会看到旧值。但是这对你来说似乎不成问题。
编辑
相同的想法在上面的链接中描述。

Answer 4

这种方法是否有意义？它实际上是线程安全的吗？

它确实有意义，它是线程安全的。无论如何，在某种程度上。有些事情需要考虑：

• 更新时，让应用程序读取过时的旧值。这是你的意图吗？对于某些应用程序很好，在其他情况下，您可能希望阻塞，直到更新缓存（FutureTask使此行为变得相当容易）。
• 当loadMappingsFromDB()开始时，最初调用get(ID)的线程将会阻塞，直到更新完成。

• 有几个线程可能会同时调用checkLoad()，这意味着如果重新加载速度很慢，并且您有多个线程调用get(ID)，则最终可能会产生大量并发更新。虽然结果是一样的，但这会浪费系统资源。一个简单的方法来解决它在当前的代码将有一个AtomicBoolean您在更新前检查：

  private final AtomicBoolean isUpdating = new AtomicBoolean(false); 
  private void checkLoad() 
  { 
      if (System.currentTimeMillis() - last_update_time <= TIMEOUT) return; 
      if (!isUpdating.compareAndSet(false, true)) return; // already updating 
      try { 
       loadMappingsFromDB(); 
      } finally { 
       isUpdating.set(false); 
      } 
  }