我有一个由链接节点组成的数据结构。您可以将其视为简单的LinkedList。列表的每个节点由一些值和指向另一个节点的下一个字段组成,如果它是最后一个节点则为null。第一个节点作为根,它没有值,只指向下一个节点。所有其他节点实际上是不可变的,一旦创建它们的值,或者它们的下一个字段在生命期间都不会发生变化,除非处理的结构与特定情况有关。
一个(仅一个)线程将新节点添加到列表的前面。它是通过构造一个新对象,设置其字段并将下一个字段设置为根指向的对象,然后将根的下一个字段设置为此新节点来完成的。
其他节点浏览仅执行读取的结构。它们引用了根节点,然后它们通过其他节点,直到找到正在查找的内容或到达列表的末尾。
我的问题是:是否足以使下一个字段变得易变?根据我对java内存模型的理解,如果主线程(添加新节点的线程)在添加新节点时将执行易失性写入,那么一切都将很好地同步,并且不会发生任何不一致。
也可以假设在x86架构中读取volatile变量不会导致性能下降?由于其他线程经常浏览读取下一个字段的结构,因此可以自由地完成此操作而不会出现任何内存障碍等。
我还有一个问题。要浏览结构的线程也将保留一些额外的节点。这些节点将完全是线程本地的,它们将仅由创建它们的线程使用,并且根本不会被共享。 对于这些附加节点,下一个字段不必是易失性的。此外,设置易失性下一字段将发出存储器屏障,这将导致不期望的性能损失。 我想知道有没有办法避免这种情况。理想情况下,如果下一个字段有时会作为一个易失性字段而有时作为一个普通字段工作,那将是完美的;)或者如果我有一个完全控制并且可以在我需要的时候自己发出内存屏障。
修改
我也想知道是否有可能以不同的方式将所有这些写入同步到不同的volatile变量上?例如一些其他完全不相关的静态变量?由于volatile写入刷新所有挂起的写入,下一个字段是不是可能不是易失性的,而是在更新线程完成所有工作后会写入不同的volatile变量?
它对我来说看起来不太安全,因为在关系之前没有发生,之前的写入可能会被重新排序。下一个字段分配可以使用值字段分配重新定位,从而导致迭代线程观察到不一致的对象状态。
但也许有可能提出一个安全的方案?这个怎么样:
更新线程首先构造一个新对象,初始化其值字段,将其下一个字段设置为根节点指向的节点,对某个静态变量执行易失性写入,设置下一个字段根节点到新创建的节点
答案 0 :(得分:8)
1
根据你在这里说的话
构建一个新对象,设置其字段和 将下一个字段设置为对象 由根指出,然后设置 root的新节点的下一个字段。
然后是的,将下一个字段设置为volatile将正确同步。了解原因很重要。你手头有三组写,一组是节点对象,一组是字段,另一组是接下来的节点(虽然不完全确定你为什么这样做,也许我想念一些东西)。
这是2 +(N个字段)写入。此时没有发生之前的关系,如果节点正常写入,则无法保证。一旦您写入易失性字段,所有先前的写入现在也将可见。
2
x86(或任何缓存一致性)操作系统上的易失性读/写具有以下属性:
volatile-read: very close to a normal read volatile-write: about 1/3 the time of a synchronization write (whether within intrinsic locking or j.u.c.Lock locking)
3
看起来你必须创建VolatileNode和Node。 Java 7提出了一个Fences API的建议,您可以使用静态实用程序类指定要执行的读/写样式,但看起来不像它的发布
编辑:
Thkala认为值得包括
虽然应该指出 前JSR133 JVM(即Java< 5.0)做到了 没有相同的语义
所以我写的内容不适用于在Java 1.4或更低版本中运行的应用程序。
答案 1 :(得分:2)
使next
字段volatile
对节点类的所有实例施加内存屏障,而不仅仅是根节点。我希望它比在根节点上使用synchronized
更昂贵。此外,JVM可以更好地优化synchronized
方法调用。另请参阅this和this。
那就是说,你应该尝试两者和基准/配置文件来看看会发生什么。
答案 2 :(得分:2)
您的根节点实际上不需要是节点。您只需要引用第一个“真实”节点。
public class LinkedList {
private volatile Node firstNode;
...
addNode(Node node) {
node.next = firstNode;
firstNode = node;
}
}
因此,您不需要在所有节点中使next
字段变为volatile;节点根本不同步。
如果您不介意对第一个节点进行易失性访问的成本,则可以将该类用于非同步链接列表。或者您可以简单地使用非同步版本的非易失性firstNode
重写该类。