【问题标题】:Memory visibility guarantees provided by intrinsic locking in Java?Java中的内在锁定提供的内存可见性保证?
【发布时间】:2015-05-13 11:13:01
【问题描述】:

我需要弄清楚在 Java 中使用内部锁提供了哪些内存可见性保证。

例如,如果我有一个 HashMap 对象,它将字符串映射到 Person 对象,如下所示:

HashMap<String,Person> m = new HashMap<String, Person>();

假设我们在同一个类中有一个同步方法,如下所示:

public synchronized void addToMap(String name, Person p){
   m.put(name, p);
}

而且同一个类还有另一个同步方法叫做get,像这样:

public synchronized Person get(String name){
   return m.get(name);
}

所以我有两个问题。

1

现在假设线程 A 获取锁并执行 addToMap 方法。然后退出该方法并释放锁。

然后线程 B 出现在 lock 方法之外,并改变了引用 p 所指的 Person 对象的状态。

那么,当线程 C 获得与线程 A 相同的锁并执行 get() 方法时,线程 C 是否保证检索到最近状态的 Person 对象?即在线程 B 更改它之后。

现在这个例子是高度人为的,如果我使用多线程映射,那么我知道我应该使用 ConcurrentHashMap 等,这个例子只是用来更好地解释我对可见性保证的困惑。

我知道当一个线程获得一个锁时,可以保证看到前一个持有该锁的线程对对象状态所做的任何更改, 那么我是否正确地认为因为线程 B 的活动是在没有获得锁的情况下执行的,所以不能保证线程 C 会看到更改?

2

现在,如果我对问题 1 的假设是正确的,那么可以说线程 B 确实改变了引用 p 在同步方法中引用的 Person 对象的状态, 所以它已经获得了锁,那么 C 是否保证看到 B 所做的更改? 我最初的假设是 C 保证看到 B 所做的更改,但是当我考虑时,我不确定实际更改是否对 Person 对象 p 指的是,实际上 更改 HashMap 的状态(它是锁定对象状态的一部分),因为它不是像添加或删除映射这样的结构修改。

我知道内在锁定提供可见性和原子性保证,而 volatile 变量只保证可见性,但我的困惑在于这些保证与实际对象的关系(例如映射中的实际对象) 就像 Person 对象 p 所指的那样),而不仅仅是对象引用。

任何帮助解决这个问题都非常感谢。

【问题讨论】:

    标签: java multithreading synchronization locking volatile


    【解决方案1】:

    我知道当线程获得锁时,可以保证看到前一个持有该锁的线程对对象状态所做的任何更改,所以我认为因为线程 B 的活动是正确的在没有获取锁的情况下执行,那么不保证线程C会看到变化?

    是的。基本上,您如何获取对象并不重要(在这种情况下,通过存储在地图中的人员引用)。

    无论线程发生什么变化,因为它没有持有锁,所以它不是发生前关系的一部分,因此不能保证后续读取会看到更新。

    现在,如果我对问题 1 的假设是正确的,那么假设线程 B 确实改变了引用 p 在同步方法中引用的 Person 对象的状态,因此它已经获得了锁,那么 C 保证看到 B 所做的更改了吗?

    如果线程 B 确实持有一个锁,并且该锁后来被线程 C 获取,那么线程 C 将看到线程 B 所做的更改,无论更改是否在映射内等等。

    但是,重要的是要记住,仅仅因为您引入了锁并不意味着您没有数据竞争。如果没有进一步的同步,就不能保证线程 B 确实在线程 C 之前获得了锁。

    希望我正确理解了您的问题,并且希望我的回答很清楚。否则请告诉我。

    【讨论】:

      【解决方案2】:

      1) 对。

      2) 是的,假设线程 B:

      • 更改了持有 SAME 锁的 p,或者
      • 在修改后调用 addToMap 方法,在这种情况下,线程 B 是在同步块内部还是外部进行更改都无关紧要。

      但是,还有另一个潜在的问题,那就是 m HashMap 本身的可见性:

      m = new HashMap<String, Person>();
      

      这段代码是不同步的,这意味着只有创建包含 m 的对象的线程才能看到 m。其他线程可能会看到地图的 null 或不一致的状态。解决方案是将 m 声明为 volatile 或 final(这就是为什么大多数不可变对象必须将其字段声明为 final,这不仅仅是一个约定)。

      happens-before 关系的完整描述可以在here找到。

      【讨论】:

        【解决方案3】:

        afaict,在您提供的示例中,第一个锁仅在地图上(即它仅影响该地图中给定 Person 的存在/不存在),而第二个锁在 Person 实例上。如果在将 Person 添加到列表时更改了 Person 的某些字段,则隐式同步不应相互影响,因此它们不会改变行为,也不会以任何方式影响 Person 实例的潜在客户(访问者) .

        【讨论】:

        • 你是不是建议他应该获得那个人的锁?
        • 好吧,如果访问者想要检查 Person 是否在地图中,则应该在地图上获取锁。相反,如果访问者想要检查 Person 的状态,则应该在 Person 实例上获取锁。我想说的是,这两个锁有不同的用途,不应该影响彼此的行为。
        • 嗯.. 只要两个线程都同意同一个锁,那么我看不出他们使用哪个锁有什么关系。从逻辑的角度来看,这当然是有道理的,但从语义上讲,我认为他们锁定哪个对象并不重要。
        • 我想我的问题是,内存可见性保证离锁有多远?是否保证线程 C 将看到线程 B 所做的所有更改,或者只看到影响已获取锁的对象状态的更改?而且我不确定对 Person 对象的更改是否真的会影响该锁定对象的状态?请让我知道这个问题是否有意义,如果没有,我会尝试不同的措辞。谢谢:)
        • 所有更改都可见。 (一种常见的模式是使用虚拟对象进行锁定:Object lock = new Object())如果它不涵盖对“不相关”变量的更改,这将毫无意义。
        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-09-08
        • 2017-08-09
        • 1970-01-01
        • 2016-12-08
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多