Java 并发：ReentrantLock 是不是设计错了？答案

【问题标题】：Java concurrent:Is ReentrantLock a wrong design?Java 并发：ReentrantLock 是不是设计错了？
【发布时间】：2017-08-15 10:53:40
【问题描述】：

我知道ReentrantLock使用AbstractQueuedSynchronizer(AQS)来实现Lock。但是实现的细节，我看不懂。

我知道 AQS 使用 volatile、CAS 和 spin 进行同步。但是，这些操作只控制“状态”成员。

虽然 LockSupport.park 和 LockSupport.unpark 可以同步线程的缓存行。但如果从不存在争用，则永远不会调用 LockSupport 方法。像这样： 1.线程A启动并运行

2.线程B启动并运行

3.线程A：

lock.lock();
try{
  //modify some shared members
  ....
}finally{
  lock.unlock();
}

4.然后线程B：

lock.lock();
try{
  //read shared members
  ....
}finally{
  lock.unlock();
}

没有争用，线程 B 不调用 LockSupport 方法。

lock.lock()只有CAS“状态”成员，而lock.unlock()修改易失的“状态”为0 .

为什么线程B可以看到线程A对共享成员的修改？

为什么ReentrantLock可以用作“同步”？

我没有看到任何类似 fullFence 的代码来同步内存。

哪个代码实现了线程的cacheline的同步？

谢谢！

【问题讨论】：

【解决方案1】：

CAS 操作定义了 happens-before 关系，因此 Java 内存模型保证来自一个线程的内存修改对另一个线程可见。

【讨论】：