互斥锁的示例

Posted 2023-04-15

参考技术A

下面举例：
在Posix Thread中定义有一套专门用于线程同步的mutex函数。
1． 创建和销毁
有两种方法创建互斥锁，静态方式和动态方式。POSIX定义了一个宏PTHREAD_MUTEX_INITIALIZER来静态初始化互斥锁，方法如下： pthread_mutex_t mutex=PTHREAD_MUTEX_INITIALIZER; 在LinuxThreads实现中，pthread_mutex_t是一个结构，而PTHREAD_MUTEX_INITIALIZER则是一个结构常量。
动态方式是采用pthread_mutex_init()函数来初始化互斥锁，API定义如下： int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mutexattr) 其中mutexattr用于指定互斥锁属性（见下），如果为NULL则使用缺省属性。
pthread_mutex_destroy ()用于注销一个互斥锁，API定义如下： int pthread_mutex_destroy(pthread_mutex_t *mutex) 销毁一个互斥锁即意味着释放它所占用的资源，且要求锁当前处于开放状态。由于在Linux中，互斥锁并不占用任何资源，因此LinuxThreads中的 pthread_mutex_destroy()除了检查锁状态以外（锁定状态则返回EBUSY）没有其他动作。
2． 互斥锁属性
互斥锁的属性在创建锁的时候指定，在LinuxThreads实现中仅有一个锁类型属性，不同的锁类型在试图对一个已经被锁定的互斥锁加锁时表现不同。当前（glibc2.2.3,linuxthreads0.9）有四个值可供选择：
* PTHREAD_MUTEX_TIMED_NP，这是缺省值，也就是普通锁。当一个线程加锁以后，其余请求锁的线程将形成一个等待队列，并在解锁后按优先级获得锁。这种锁策略保证了资源分配的公平性。
* PTHREAD_MUTEX_RECURSIVE_NP，嵌套锁，允许同一个线程对同一个锁成功获得多次，并通过多次unlock解锁。如果是不同线程请求，则在加锁线程解锁时重新竞争。
* PTHREAD_MUTEX_ERRORCHECK_NP，检错锁，如果同一个线程请求同一个锁，则返回EDEADLK，否则与PTHREAD_MUTEX_TIMED_NP类型动作相同。这样就保证当不允许多次加锁时不会出现最简单情况下的死锁。
* PTHREAD_MUTEX_ADAPTIVE_NP，适应锁，动作最简单的锁类型，仅等待解锁后重新竞争。
3．锁操作
锁操作主要包括加锁pthread_mutex_lock()、解锁pthread_mutex_unlock()和测试加锁 pthread_mutex_trylock()三个，不论哪种类型的锁，都不可能被两个不同的线程同时得到，而必须等待解锁。对于普通锁和适应锁类型，解锁者可以是同进程内任何线程；而检错锁则必须由加锁者解锁才有效，否则返回EPERM；对于嵌套锁，文档和实现要求必须由加锁者解锁，但实验结果表明并没有这种限制，这个不同还没有得到解释。在同一进程中的线程，如果加锁后没有解锁，则任何其他线程都无法再获得锁。
int pthread_mutex_lock(pthread_mutex_t *mutex)
int pthread_mutex_unlock(pthread_mutex_t *mutex)
int pthread_mutex_trylock(pthread_mutex_t *mutex)
pthread_mutex_trylock()语义与pthread_mutex_lock()类似，不同的是在锁已经被占据时返回EBUSY而不是挂起等待。
4． 其他
POSIX 线程锁机制的Linux实现都不是取消点，因此，延迟取消类型的线程不会因收到取消信号而离开加锁等待。值得注意的是，如果线程在加锁后解锁前被取消，锁将永远保持锁定状态，因此如果在关键区段内有取消点存在，或者设置了异步取消类型，则必须在退出回调函数中解锁。
这个锁机制同时也不是异步信号安全的，也就是说，不应该在信号处理过程中使用互斥锁，否则容易造成死锁。
互斥锁属性使用互斥锁（互斥）可以使线程按顺序执行。通常，互斥锁通过确保一次只有一个线程执行代码的临界段来同步多个线程。互斥锁还可以保护单线程代码。
要更改缺省的互斥锁属性，可以对属性对象进行声明和初始化。通常，互斥锁属性会设置在应用程序开头的某个位置，以便可以快速查找和轻松修改。表 4–1列出了用来处理互斥锁属性的函数。
表 4–1 互斥锁属性例程 操作 相关函数说明 初始化互斥锁属性对象 pthread_mutexattr_init 语法 销毁互斥锁属性对象 pthread_mutexattr_destroy 语法 设置互斥锁范围 pthread_mutexattr_setpshared 语法 获取互斥锁范围 pthread_mutexattr_getpshared 语法 设置互斥锁的类型属性 pthread_mutexattr_settype 语法 获取互斥锁的类型属性 pthread_mutexattr_gettype 语法 设置互斥锁属性的协议 pthread_mutexattr_setprotocol 语法 获取互斥锁属性的协议 pthread_mutexattr_getprotocol 语法 设置互斥锁属性的优先级上限 pthread_mutexattr_setprioceiling 语法 获取互斥锁属性的优先级上限 pthread_mutexattr_getprioceiling 语法 设置互斥锁的优先级上限 pthread_mutex_setprioceiling 语法 获取互斥锁的优先级上限 pthread_mutex_getprioceiling 语法 设置互斥锁的强健属性 pthread_mutexattr_setrobust_np 语法 获取互斥锁的强健属性 pthread_mutexattr_getrobust_np 语法 表 4–2中显示了在定义互斥范围时 Solaris 线程和 POSIX 线程之间的差异。
表 4–2 互斥锁范围比较 Solaris POSIX 定义 USYNC_PROCESS PTHREAD_PROCESS_SHARED 用于同步该进程和其他进程中的线程 USYNC_PROCESS_ROBUST 无 POSIX 等效项 用于在进程间可靠地同步线程 USYNC_THREAD PTHREAD_PROCESS_PRIVATE 用于仅同步该进程中的线程

Java面试-锁的内存语义

简介：

锁的作用是让临界区互斥执行。本文阐述所得另一个重要知识点——锁的内存语义。
​

1、锁的释放-获取建立的happens-before关系

锁是Java并发编程中最重要的同步机制。锁除了让临界区互斥执行外，还可以让释放锁的线程向获取同一个锁的线程发送消息。
锁释放-获取的示例代码：

package com.lizba.p1;

/**
 * <p>
 *      锁示例代码
 * </p>
 *
 * @Author: Liziba
 * @Date: 2021/6/10 21:43
 */
public class MonitorExample {

    int a = 0;

    public synchronized void writer() {     // 1;
        a++;                                // 2;
    }                                       // 3;

    public synchronized void reader() {     // 4;
        int i = a;                          // 5;
        System.out.println(i);
    }                                       // 6;
    
}

假设线程A执行writer()方法，随后线程B执行reader()方法。根据happens-before规范，这个过程包含的happens-before关系可以分为3类。

1. 根据程序次序规则：1 happens-before 2，2 happens-before 3, 4 happens-before 5，5 happens-before 6
2. 根据监视器锁规则：3 happens-before 4
3. 根据happens-before的传递性，2 happens-before 5

​
上述happens-before关系的图形化表现形式如图：

总结：
线程A在释放锁之前所有可见的共享变量，在线程B获取同一个锁之后，将立即变得对B线程可见。
​

2、锁释放和获取的内存语义

当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。以上述MonitorExample程序为例，A线程释放锁后，共享数据的状态示意图如下所示：

共享数据的状态示意图

当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使得被监视器锁保护的临界区代码必须从主内存中读取共享变量。

锁获取的状态示意图

对比锁释放-获取锁的内存语义与volatile写-读的内存语义可以看出：锁释放与volatile写有相同的内存语义；锁获取与volatile读有相同的内存语义。
总结：

• 线程A释放锁，实质上是线程A向接下来要获取这个锁的某个线程发出了（线程A对共享变量所做修改的）消息。
• 线程B获取锁，实质上是线程B接受了之前某个线程发出的（在释放这个锁对共享变量锁做的修改的）消息。
• 线程A是否锁，随后线程B获取这个锁，这个过程实质上是线程A通过主内存向线程B发送消息。

3、锁内存的语义实现

分析ReentrantLock的源代码，来分析锁内存语义的具体实现机制。
示例代码：

package com.lizba.p1;

import java.util.concurrent.locks.ReentrantLock;

/**
 * <p>
 *		ReentrantLock示例代码
 * </p>
 *
 * @Author: Liziba
 * @Date: 2021/6/10 22:17
 */
public class ReentrantLockExample {

    int a = 0;
    ReentrantLock lock = new ReentrantLock();

    public void writer() {
        lock.lock();                 // 获取锁
        try {
            a++;
        } finally {
            lock.unlock();          // 释放锁
        }
    }

    public void reader() {
        lock.lock();                // 获取锁
        try {
            int i = a;
            System.out.println(i);
        } finally {
            lock.unlock();          // 释放锁
        }
    }

}

在ReentrantLock中，调用lock()方法获取锁；调用unlock()方法释放锁。
ReentrantLock的实现依赖于Java同步器框架AbstractQueuedSynchronized(AQS)。AQS使用一个整型的volatile变量（state）来维护同步状态，这个volatile变量是ReentrantLock内存语义实现的关键。

ReetrantLock的类图

ReentrantLock分为公平锁和非公平锁，首先分析公平锁。
使用公平锁时，加锁方法lock()的调用轨迹如下。

1. ReentrantLock: lock()
2. FairSync: lock()
3. AbstractQueuedSynchronizer: acquire(int arg)
4. ReentrantLock: tryAcquire(int acquires)

第4步开始真的加锁，下面是该方法的源代码：

 protected final boolean tryAcquire(int acquires) {
     final Thread current = Thread.currentThread();
     // 获取锁开始，首先读取volatile变量state
     int c = getState();
     if (c == 0) {
         if (!hasQueuedPredecessors() &&
             compareAndSetState(0, acquires)) {
             setExclusiveOwnerThread(current);
             return true;
         }
     }
     else if (current == getExclusiveOwnerThread()) {
         int nextc = c + acquires;
         if (nextc < 0)
             throw new Error("Maximum lock count exceeded");
         setState(nextc);
         return true;
     }
     return false;
 }

从上面的代码中可以看出，加锁方法首先读取volatile变量state。
​

在使用公平锁时，解锁方法unlock()调用轨迹如下：

1. ReentrantLock: unlock()
2. AbstractQueuedSynchronizer: release(int arg)
3. Sync: tryRelease(int release)

第3步开始真的释放锁，下面是该方法的源代码：

  protected final boolean tryRelease(int releases) {
      int c = getState() - releases;
      if (Thread.currentThread() != getExclusiveOwnerThread())
          throw new IllegalMonitorStateException();
      boolean free = false;
      if (c == 0) {
          free = true;
          setExclusiveOwnerThread(null);
      }
      // 释放锁的最后，写volatile变量state
      setState(c);
      return free;
  }

从上面的代码中可以看出，释放锁的最后写volatile变量state。
总结公平锁：
根据volatile的happens-before规则，释放锁的线程在写volatile变量之前可见的共享变量，在获取锁的线程读取到同一个volatile变量后将立即变得对获取锁的线程可见。
​

现在分析非公平锁：
注意，非公平锁的释放和公平锁的释放完全一致，都是上面的源代码。所以下面只分析非公平锁的获取过程。
​

使用非公平锁，加锁方法lock()的调用轨迹如下：

1. ReentrantLock: lock()
2. NonfairSync: lock()
3. AbstractQueuedSynchronizer: compareAndSetState(int expect, int update)

第3步开始真的加锁，下面是该方法的源代码：

// 方法1  
final boolean nonfairTryAcquire(int acquires) {
      final Thread current = Thread.currentThread();
      int c = getState();
      if (c == 0) {
          // 此方法中开始加锁
          if (compareAndSetState(0, acquires)) {
              setExclusiveOwnerThread(current);
              return true;
          }
      }
      else if (current == getExclusiveOwnerThread()) {
          int nextc = c + acquires;
          if (nextc < 0) // overflow
              throw new Error("Maximum lock count exceeded");
          setState(nextc);
          return true;
      }
      return false;
  }

// 方法2
 protected final boolean compareAndSetState(int expect, int update) {
     // See below for intrinsics setup to support this
     // 该方法是native方法，在JVM中实现
     return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
 }

该方法以原子操作的方式更新state变量，也就是compareAndSet() (CAS)操作。JDK文档对该方法说明如下：如果当前状态值等于预期值，则以原子方式同步状态设置为给定更新的值。此操作具有volatile读和写的内存语义。

接下来分别从编译器和处理器的角度来分析，CAS如何同时具有volatile读和volatile写的内存语义。
编译器的角度：
前文已经讲过，编译器不会对volatile读与volatile读后面的任意内存操作重排序；编译器不会对volatile写和volatile写后前面的任意内存操作重排序。组合这两个条件，意味着同时实现volatile读和volatile写的内存语义，编译器不能对CAS与CAS前面和后面任意内存操作重排序。
​

处理器的角度：
（本人不太懂C++）这一块总结需要看JVM源码，可能会总结错误，如需要深入理解这一块请查看《Java并发编程艺术》53页。
sun.misc.Unsafe中的compareAndSwapInt源码如下：（不懂Unsafe请看往期文章）

 public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

这是一个本地方法。这个本地方法会在openJDK中调用C++代码，假设当前是X86处理器，程序会根据当前处理器的类型来决定是非cmpxchg指令添加lock前缀。如果：

• 程序运行在多处理器上，就为cmpxchg指令加上lock前缀（Lock Cmpxchg）
• 程序运行在单处理器上，就省略lock前缀（单处理器自身会维护单处理器内的顺序一致性，不需要lock前缀提供的内存屏障效果）

​

intel手册对lock前缀的说明

1. 对内存的读-改-写操作原子执行。（总线锁定/缓存锁定）
2. 禁止该指令，与之前的读和写指令重排序
3. 把写缓冲区的所有数据刷新到内存中

上面的2、3两点所具有的内存屏障的效果，足以同时实现volatile读和volatile写的内存语义。所以JDK文档说CAS 具有volatile读和volatile写的内存语义对于处理器也是符合的。
​

公平锁和非公平锁的总结

1. 公平锁和非公平锁的释放，最后都需要写一个volatile变量state
2. 公平锁获取时，首先会去读volatile变量
3. 非公平锁获取锁时，首先会用CAS更新volatile变量，这个操作同时具有volatile读和volatile写的内存语义

​

释放锁-获取锁的内存语义的实现方式总结

1. 利用volatile变量的写-读所具有的内存语义
2. 利用CAS所附带的volatile读和volatile写的内存语义

​

4、concurrent包的实现

由于Java的CAS同时具有volatile读和volatile写的内存语义，因此Java线程之间的通信方式有以下4种方式

1. A线程写volatile变量，随后B线程读这个volatile变量
2. A线程写volatile变量，随后B线程用CAS更新这个volatile变量
3. A线程利用CAS更新一个volatile变量，随后B线程用CAS更新这个volatile变量
4. A线程利用CAS更新一个volatile变量，随后B线程读这个volatile变量

Java的CAS会使用现代处理器上提供的高效机器级别的原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器实现同步的关键。同时volatile变量的读/写和CAS可以实现线程之间的通信。这些特性就是Java整个concurrent包的基石。
​

concurrent包的通用化实现模式

1. 声明共享变量volatile
2. 使用CAS的原子条件更新来实现线程之间的同步
3. 配合volatile的读/写和CAS具有的volatile读和写的内存语义来实现线程之间的通信。

AQS（java.util.concurrent.locks.AbstractQueuedSynchronizer）、非阻塞数据结构和原子变量类（java.util.concurrent.atomic包中的类），这些concurrent包中基础类都是使用这个模式来实现的，而concurrent包中的高层类又是依赖于这些基础类。
图示concurrent包的实现示意图

concurrent包的实现示意图

文章总结至《Java并发编程艺术》，下篇总结“final域的内存语义”，敬请关注。