本文探讨了Java内存模型中“正确同步”的概念是否可以应用于程序中较小的部分，例如一个独立的并发集合类，而非仅仅局限于整个程序。通过分析JLS对“正确同步”的定义及其与数据竞争和顺序一致性的关系，文章指出，在满足特定条件（如内部状态的严格封装和对相关共享变量操作的全面考量）下，一个组件可以被设计为内部“正确同步”，从而确保其自身操作的顺序一致性，即使程序其他部分可能存在数据竞争。
理解Java内存模型中的“正确同步”
Java内存模型（JMM）是Java语言并发编程的基础，它定义了线程如何与内存交互。其中一个核心概念是“正确同步”（correctly synchronized）。根据Java语言规范（JLS）第17.4.5节的定义：
如果且仅当所有顺序一致的执行都不存在数据竞争时，一个程序才是正确同步的。 如果一个程序是正确同步的，那么该程序的所有执行都将表现为顺序一致性。
这意味着，一个“正确同步”的程序，其并发执行的结果将与某个串行执行的结果相同，从而极大地简化了并发程序的推理。数据竞争（data race）是指当两个或多个线程同时访问同一个共享变量，并且至少有一个访问是写入操作，同时这些访问之间没有通过同步操作（如synchronized、volatile、Lock等）建立“先行发生”（happens-before）关系时发生的情况。数据竞争会导致不可预测的行为和程序错误。
“正确同步”概念在组件级别的应用
传统的理解认为，“正确同步”是一个应用于整个程序的属性。然而，在构建大型并发系统时，我们通常会设计独立的并发组件，例如自定义的并发集合类。这时，一个自然的问题是：我们能否确保某个组件（如一个类）是“正确同步”的，从而保证其内部操作的正确性，而不必关注整个程序的同步状态？
立即学习“Java免费学习笔记（深入）”；
答案是肯定的，在特定条件下，我们可以将“正确同步”的概念应用于程序中较小的部分，如一个类或一个模块。这种组件级别的“正确同步”是可行的，其核心在于对组件内部共享变量的隔离和操作的全面控制。
核心原理与条件
内部状态的封装与隔离： 如果一个类的内部状态（即其共享变量）不被外部直接访问，那么我们可以将这些共享变量的同步问题与程序其他部分的共享变量隔离开来。这意味着，类外部的代码不能直接读取或修改该类的私有共享变量，所有对这些变量的访问都必须通过该类提供的公共方法进行。
聚焦于特定的共享变量： JLS关于数据竞争和顺序一致性的定义是基于“共享变量”的操作。当我们考虑一个组件时，我们可以将分析范围限定在该组件内部所拥有的共享变量。如果对这些特定共享变量的所有操作（读和写）都符合“正确同步”的条件（即所有顺序一致的执行都不存在数据竞争），那么该组件在自身操作层面上可以被认为是“正确同步”的。
Happens-before关系与总序： 证明“正确同步”通常依赖于构建所有操作的“先行发生”关系图，并在此基础上推导出所有操作的总序。对于一个组件而言，如果其内部所有对共享变量的读写操作都能通过同步机制建立起明确的“先行发生”关系，从而避免数据竞争，那么这些操作在组件内部就能表现出顺序一致性。即使程序其他部分可能存在数据竞争，只要它们不直接影响该组件内部的共享变量，该组件自身的同步性仍然可以保持。
示例：自定义并发集合类
考虑一个自定义的并发哈希表实现。为了使其内部操作是“正确同步”的，我们需要确保：
- 所有对内部数据结构（如存储键值对的数组、链表或树节点）的访问都受到适当的同步保护。 例如，可以使用synchronized关键字、ReentrantLock或ReadWriteLock来保护对内部数组和节点的操作。
- 私有变量的封装。 集合内部的数组、大小计数器等变量应声明为private，并通过公共方法（如put(), get(), remove()）进行访问。
- 并发原语的正确使用。 确保在读写操作中，锁的获取和释放、volatile字段的使用等都遵循JMM的规则，以建立正确的happens-before关系。
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
class MyConcurrentCollection<K, V> {
private final Object[] data; // 内部共享变量
private int size; // 内部共享变量
private final Lock lock = new ReentrantLock(); // 同步机制
public MyConcurrentCollection(int capacity) {
this.data = new Object[capacity];
this.size = 0;
}
public void put(K key, V value) {
lock.lock(); // 获取锁，建立 happens-before 关系
try {
// 对 data 和 size 的操作都在锁的保护下
// 确保这些操作是原子且可见的，避免数据竞争
if (size < data.length) {
data[size++] = new Entry(key, value);
System.out.println("Added: " + key + " -> " + value);
} else {
System.out.println("Collection is full.");
}
} finally {
lock.unlock(); // 释放锁
}
}
public V get(K key) {
lock.lock(); // 获取锁
try {
// 对 data 的读取操作也在锁的保护下
for (int i = 0; i < size; i++) {
Entry entry = (Entry) data[i];
if (entry != null && entry.key.equals(key)) {
return entry.value;
}
}
return null;
} finally {
lock.unlock(); // 释放锁
}
}
public int size() {
lock.lock(); // 获取锁
try {
return size; // 对 size 的读取操作在锁的保护下
} finally {
lock.unlock(); // 释放锁
}
}
private static class Entry<K, V> {
final K key;
final V value;
Entry(K key, V value) {
this.key = key;
this.value = value;
}
}
}在上述MyConcurrentCollection示例中，data数组和size变量是类的内部共享状态。通过使用ReentrantLock来保护所有对这些变量的读写操作，我们确保了在任何并发执行中，对data和size的访问都不会产生数据竞争。因此，从该集合的角度来看，其内部操作是“正确同步”的，并且对这些内部变量的读写将表现出顺序一致性。
注意事项
- 严格的封装是关键： 如果类的内部共享变量可以通过某种方式（例如，返回内部数组的引用，或者通过不安全的迭代器）泄露到外部，并且外部代码在没有同步保护的情况下修改这些变量，那么组件的“正确同步”性就会被破坏。
- 局部顺序一致性与全局不一致性： 一个组件内部的“正确同步”并不意味着整个程序也是“正确同步”的。程序其他部分可能仍然存在数据竞争，导致整个程序的行为不具有顺序一致性。然而，这并不影响该组件自身的内部操作能够保证顺序一致性。
- 全面考虑所有操作： 在分析组件的“正确同步”性时，必须考虑所有对该组件内部共享变量的读写操作。任何遗漏的、未受保护的访问都可能引入数据竞争，从而破坏组件的同步性。
结论
将“正确同步”的概念应用于组件级别是可行的，并且对于构建模块化、可维护的并发系统具有重要意义。通过严格封装组件的内部状态，并确保所有对这些内部共享变量的访问都通过适当的同步机制进行保护，我们可以设计出在自身层面是“正确同步”的并发组件。这使得开发者可以独立地推理和验证组件的并发行为，而无需担心整个程序的复杂性，从而大大简化了并发编程的挑战。然而，开发者必须始终牢记，组件级别的“正确同步”并不等同于整个程序的“正确同步”，对外部交互和数据流的同步考量仍然至关重要。
