在Java中，我可以依靠原子引用引用来实现写时复制吗？

Question

如果我在多线程环境中有一个未同步的Java集合，并且不想强制该集合的读者进行同步[1]，那么我可以同步编写器并使用引用分配的原子性的解决方案是否可行？就像是：

private Collection global = new HashSet(); // start threading after this

void allUpdatesGoThroughHere(Object exampleOperand) {
  // My hypothesis is that this prevents operations in the block being re-ordered
  synchronized(global) {
    Collection copy = new HashSet(global);
    copy.remove(exampleOperand);
    // Given my hypothesis, we should have a fully constructed object here. So a 
    // reader will either get the old or the new Collection, but never an 
    // inconsistent one.
    global = copy;    
  }
}

// Do multithreaded reads here. All reads are done through a reference copy like:
// Collection copy = global;
// for (Object elm: copy) {...
// so the global reference being updated half way through should have no impact

在这种情况下，推出自己的解决方案似乎常常会失败，因此我会对了解其他可用来防止对象创建和阻止数据使用者的模式，集合或库感兴趣。

[1]原因是与写入相比，读取所花费的时间比例更大，并且存在引入死锁的风险。

编辑：在一些答案和评论中有很多好的信息，重要的是：

1. 我发布的代码中存在一个错误。交换后，在全局变量（命名错误的变量）上进行同步可能无法保护同步块。
2. 您可以通过在类上同步（将synced关键字移到方法上）来解决此问题，但是可能还有其他错误。一个更安全，更可维护的解决方案是使用java.util.concurrent中的内容。
3. 我发布的代码中没有“最终一致性保证”，一种确保读者可以一定程度地看到作者的更新的方法是使用volatile关键字。
4. 经过反思，促使这个问题出现的一般问题是试图用Java中的锁定写入来实现无锁定读取，但是我的（已解决）问题与集合有关，这可能会给以后的读者带来不必要的困惑。因此，在不太明显的情况下，我发布的代码可以一次允许一个作者对“某个对象”进行编辑，而该对象正在不受多个读取器线程保护的情况下进行编辑。编辑的提交是通过原子操作完成的，因此读者只能获得编辑前或编辑后的“对象”。当/如果读取器线程获得更新，则该更新不能在读取中间发生，因为读取发生在“对象”的旧副本上。在Java中提供更好的并发支持之前，可能已经发现并证明以某种方式破坏了一个简单的解决方案。

Answer 1

与其尝试推出自己的解决方案，不为何使用ConcurrentHashMap作为您的集合，而只是将所有值设置为某个标准值？（像Boolean.TRUE这样的常量会很好用。）

我认为这种实现方式在许多读者很少的情况下效果很好。甚至还有一个构造函数，可让您设置预期的“并发级别”。

更新： Veer建议使用
Collections.newSetFromMap
实用程序方法将ConcurrentHashMap转换为Set。由于该方法令人Map<E,Boolean>怀疑，因此它会将所有值设置Boolean.TRUE为幕后操作。

更新：解决海报的示例

那可能是我最终要解决的问题，但是我仍然对我的极简解决方案如何失败感到好奇。– MilesHampson

通过一些调整，您的极简解决方案将可以正常工作。我担心的是，尽管现在它很小，但将来可能会变得更加复杂。很难记住在进行线程安全操作时要假设的所有条件，尤其是如果您要在几周/几个月/几年后返回代码以进行看似微不足道的调整时。如果ConcurrentHashMap具有足够的性能来满足您的所有需求，那么为什么不使用它呢？所有令人讨厌的并发详细信息都被封装了起来，甚至从现在开始的6个月，您将很难将其弄乱！

您确实需要至少一项调整才能使当前解决方案生效。正如已经指出的那样，您可能应该将volatile修饰符添加到global的声明中。我不知道您是否具有C
/ C ++背景，但是当我得知volatile
Java的语义实际上比C复杂得多时，我感到非常惊讶。如果您打算使用Java进行大量并发编程，那么熟悉Java内存模型的基础是一个好主意。如果您不引用global某个volatile引用，那么在global尝试更新它之前，没有线程会看到该值的任何更改。synchronized
块将刷新本地缓存并获取更新的参考值。

但是，即使添加了volatile，仍然存在 很大的 问题。这是一个有两个线程的问题场景：

1. 我们从空集或开始global={}。线程A和B两者在其线程本地缓存的内存中均具有此值。
2. 线程A获取获得synchronized锁定global并通过复制副本global并将新密钥添加到集合中来开始更新。
3. 当Thread A仍在synchronized块内时，Thread B将其本地值读取global到堆栈上并尝试进入该synchronized块。由于线程A当前位于监视器的线程B块内。
4. 线程A通过设置参考并退出监视器来完成更新，结果为global={1}。
5. 线程B现在能够进入监视器并制作副本global={1}。
6. 线程A决定进行另一次更新，读取其本地global引用，然后尝试进入该synchronized块。 由于线程B当前保持锁定状态，{}因此没有任何锁定{1}，线程A成功进入监视器！
7. 线程A还制作的副本以{1}进行更新。

现在，线程A和B都在synchronized块内，并且它们具有相同的副本global={1}集。 这意味着他们的更新之一将丢失！
这种情况是由于您正在对存储在synchronized块中要更新的引用中的对象进行同步而引起的。您应该始终非常小心地使用要同步的对象。您可以通过添加新变量来充当锁来解决此问题：

private volatile Collection global = new HashSet(); // start threading after this
private final Object globalLock = new Object(); // final reference used for synchronization

void allUpdatesGoThroughHere(Object exampleOperand) {
  // My hypothesis is that this prevents operations in the block being re-ordered
  synchronized(globalLock) {
    Collection copy = new HashSet(global);
    copy.remove(exampleOperand);
    // Given my hypothesis, we should have a fully constructed object here. So a 
    // reader will either get the old or the new Collection, but never an 
    // inconsistent one.
    global = copy;    
  }
}

这个错误非常阴险，其他答案都没有解决。
这些疯狂的并发细节使我建议使用已经调试过的java.util.concurrent库中的某些内容，而不是尝试自己编写一些内容。
我认为上述解决方案会奏效-但是将其再次拧紧有多容易？这样会容易得多：

private final Set<Object> global = Collections.newSetFromMap(new ConcurrentHashMap<Object,Boolean>());

由于是引用，因此final您不必担心使用陈旧引用的线程，并且由于ConcurrentHashMap内部处理了所有讨厌的内存模型问题，因此您不必担心监视器和内存屏障的所有讨厌的细节！