原始数组写入的 Java 并发可见性

Question

我最近在我的代码库中发现了这个 gem：

/** This class is used to "publish" changes to a non-volatile variable.
 *
 * Access to non-volatile and volatile variables cannot be reordered,
 * so if you make changes to a non-volatile variable before calling publish,
 * they are guaranteed to be visible to a thread which calls syncChanges
 *
 */
private static class Publisher {
    //This variable may not look like it's doing anything, but it really is.
    //See the documentaion for this class.
    private volatile AtomicInteger sync = new AtomicInteger(0);

    void publish() {
        sync.incrementAndGet();
    }

    /**
     *
     * @return the return value of this function has no meaning.
     * You should not make *any* assumptions about it.
     */
    int syncChanges() {
        return sync.get();
    }
}

这样使用：

线程 1

float[][] matrix;
matrix[x][y] = n;
publisher.publish();

线程 2

publisher.syncChanges();
myVar = matrix[x][y];

线程 1 是一个持续运行的后台更新线程。线程 2 是一个 HTTP 工作线程，它不关心它所读取的内容是否一致或原子，只关心写入“最终”到达那里并且不会丢失作为并发之神的祭品。

现在，这会触发我所有的警钟。自定义并发算法编写在不相关代码的深处。

不幸的是，修复代码并非易事。 Java 对并发原始矩阵的支持不好。看起来最清晰的解决方法是使用ReadWriteLock，但这可能会对性能产生负面影响。显然，正确性更重要，但似乎我应该在将其从性能敏感区域中剔除之前证明这是不正确的。

根据the java.util.concurrent documentation，以下创建happens-before关系：

线程中的每个动作都发生在该线程中按程序顺序稍后出现的每个动作之前。

对 volatile 字段的写入发生在对同一字段的每次后续读取之前。 volatile 字段的写入和读取具有与进入和退出监视器类似的内存一致性效果，但不需要互斥锁定。

听起来像：

• 矩阵写入发生在发布之前（）（规则 1）
• publish() 发生在 syncChanges() 之前（规则 2）
• syncChanges() 发生在矩阵读取之前（规则 1）

所以代码确实为矩阵建立了一个happens-before链。

但我不相信。并发很难，而且我不是领域专家。 我错过了什么？这真的安全吗？

Answer 1

就可见性而言，您只需要在任何 volatile 字段上进行 volatile 读写操作。这会工作

final    float[][] matrix  = ...;
volatile float[][] matrixV = matrix;

线程 1

matrix[x][y] = n;
matrixV = matrix; // volatile write

线程 2

float[][] m = matrixV;  // volatile read
myVar = m[x][y];

or simply
myVar = matrixV[x][y];

但这仅适用于更新一个变量。如果写入线程正在写入多个变量，而读取线程正在读取它们，则读取器可能会看到不一致的画面。通常它由读写锁处理。 Copy-on-write 可能适用于某些使用模式。

Doug Lea 为 Java8 提供了一个新的“StampedLock”http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166edocs/jsr166e/StampedLock.html，这是一个读写锁版本，对于读锁来说要便宜得多。但它也更难使用。基本上读者得到当前版本，然后继续读取一堆变量，然后再次检查版本；如果版本没有更改，则在读取会话期间没有并发写入。

Answer 2

这对于向矩阵发布单个更新看起来确实是安全的，但当然它不提供任何原子性。这是否可行取决于您的应用程序，但它可能应该记录在这样的实用程序类中。

但是，它包含一些冗余，可以通过将sync 字段设置为final 来改进。该字段的volatile 访问是两个内存屏障中的第一个；按照约定，调用incrementAndGet() 对内存的影响与对易失性变量的写入和读取具有相同的效果，而调用get() 与读取具有相同的效果。

所以，代码可以单独依赖这些方法提供的同步，将字段本身设为final。

Answer 3

使用volatile 并不是同步所有内容的灵丹妙药。可以保证，如果另一个线程读取 volatile 变量的更新值，他们也会看到在此之前对非 volatile 变量所做的每一次更改。但无法保证其他线程会读取更新后的值。

在示例代码中，如果您对matrix 进行多次写入然后调用publish()，而另一个线程调用synch() 然后读取矩阵，那么另一个线程可能会看到一些、全部或没有变化：

• 所有更改，如果它从 publish() 读取更新的值
• 没有任何更改，如果它读取旧的发布值并且没有任何更改泄漏
• 某些更改，如果它读取之前发布的值，但某些更改已经泄漏

见this article

Answer 4

您正确地提到了发生在关系之前的规则 #2

对 volatile 字段的写入发生在对同一字段的每次后续读取之前。

但是，它不能保证在绝对时间轴上的 syncChanges() 之前会调用 publish()。让我们稍微改变一下你的例子。

线程 1：

matrix[0][0] = 42.0f;
Thread.sleep(1000*1000); // assume the thread was preempted here
publisher.publish(); //assume initial state of sync is 0 

线程 2：

int a = publisher.syncChanges();
float b = matrix[0][0];

a 和 b 变量有哪些可用选项？

• a 是 0，b 可以是 0 或 42
• a 是 1，b 是 42，因为之前发生的关系
• a 大于 1（线程 2 由于某种原因很慢，线程 1 很幸运地发布了多次更新），b 的值取决于业务逻辑和矩阵的处理方式 - 是否取决于之前的状态或不？

如何处理？这取决于业务逻辑。

• 如果线程 2 不时轮询矩阵的状态，并且中间有一些过时的值是完全可以的，如果最终处理正确的值，则保持原样。
• 如果线程 2 不关心错过的更新，但它总是想观察最新的矩阵，则使用写时复制集合或使用上面提到的 ReaderWriteLock。
• 如果线程 2 确实关心单个更新，那么应该以更智能的方式处理它，您可能需要考虑 wait() / notify() 模式并在矩阵更新时通知线程 2。