# 一、synchronized synchronized是Java中的关键字，是一种同步锁。它修饰的对象有以下几种： 1. 修饰一个代码块，被修饰的代码块称为同步语句块，其作用的范围是大括号{}括起来的代码，作用的对象是调用这个代码块的对象； ```java class SyncLock implements Runnable{ @Override public void run() { synchronized (this){ for (int i = 0; i < 5; i++) { try { System.out.println("线程名:"+Thread.currentThread().getName() + ":" + (count++)); Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } } } } } ``` synchronized (this)锁定的是当前对象，如果new一个其他对象的话，会生成新锁。 2. 修饰一个方法，被修饰的方法称为同步方法，其作用的范围是整个方法，作用的对象是调用这个方法的对象； ```java public synchronized void run() { { for (int i = 0; i < 5; i++) { try { System.out.println("线程名:"+Thread.currentThread().getName() + ":" + (count++)); Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } } } } ``` 在用synchronized修饰方法时要注意以下几点： + synchronized关键字不能继承 + 在定义接口方法时不能使用synchronized关键字 + 构造方法不能使用synchronized关键字，但可以使用synchronized代码块来进行同步 3. 修饰一个静态的方法，其作用的范围是整个静态方法，作用的对象是这个类的所有对象； 静态方法是属于类的而不属于对象的。同样的，synchronized修饰的静态方法锁定的是这个类的所有对象。 ```java class SyncThread implements Runnable { private static int count; public SyncThread() { count = 0; } public synchronized static void method() { for (int i = 0; i < 5; i ++) { try { System.out.println(Thread.currentThread().getName() + ":" + (count++)); Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } } } public synchronized void run() { method(); } } ``` 假如创建了2个SyncThread对象，但是由于有静态方法锁且锁属于这个类，无论创建多少对象，run()方法的锁依然生效。 4. 修饰一个类，其作用的范围是synchronized后面括号括起来的部分，作用主的对象是这个类的所有对象。 ```java class SyncThread implements Runnable { private static int count; public SyncThread() { count = 0; } public static void method() { synchronized(SyncThread.class) { for (int i = 0; i < 5; i ++) { try { System.out.println(Thread.currentThread().getName() + ":" + (count++)); Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } } } } public synchronized void run() { method(); } } ``` 效果与修饰静态方法相同 # 二、volatile 不能用于自增操作，例如count ++ 作用如下： 1. 保证可见性，不保证原子性 当写一个volatile变量时，JMM会把该线程本地内存中的变量强制刷新到主内存中去； 这个写会操作会导致其他线程中的volatile变量缓存无效。 2. 禁止指令重排 重排序在单线程下一定能保证结果的正确性，但是在多线程环境下，可能发生重排序，影响结果 假设线程A先执行writer方法，线程B随后执行reader方法，初始时线程的本地内存中flag和a都是初始状态，下图是线程A执行volatile写后的状态图。 ![[Snipaste_2023-02-28_13-09-43 2.png]] 当volatile变量写后，线程中本地内存中共享变量就会置为失效的状态，因此线程B再需要读取从主内存中去读取该变量的最新值。下图就展示了线程B读取同一个volatile变量的内存变化示意图。 ![[Snipaste_2023-02-28_13-09-43 3.png]] 从横向来看，线程A和线程B之间进行了一次通信，线程A在写volatile变量时，实际上就像是给B发送了一个消息告诉线程B你现在的值都是旧的了，然后线程B读这个volatile变量时就像是接收了线程A刚刚发送的消息。既然是旧的了，那线程B该怎么办了？自然而然就只能去主内存去取啦。 # 三、ReentrantLock ```java public class ReentrantLockDemo { // 实例化一个非公平锁，构造方法的参数为true表示公平锁，false为非公平锁。 private final ReentrantLock lock = new ReentrantLock(false); private int i; public void testLock() { // 拿锁，如果拿不到会一直等待 lock.lock(); try { // 再次尝试拿锁(可重入)，拿锁最多等待100毫秒 if (lock.tryLock(100, TimeUnit.MILLISECONDS)) i++; } catch (InterruptedException e) { e.printStackTrace(); } finally { // 释放锁 lock.unlock(); lock.unlock(); } } } ``` 代码中创建了非公平锁，lock.lock()会进行拿锁操作，如果拿不到锁则会一直等待。如果拿到锁之后则会执行try代码块中的代码。接下来在try代码块中又通过tryLock(100, TimeUnit.MILLISECONDS)方法尝试再次拿锁，此时，拿锁最多会等待100毫秒，如果在100毫秒内能获得锁，则tryLock方法返回true，拿锁成功，执行i++操作，如果返回false，获取锁失败，i++不会被执行。（因为第一次线程已经拿到锁了，由于ReentrantLock是可重入，因此，第二次必定能拿到锁。此处仅仅为了演示ReetranLock的使用，不必纠结）。 另外，要注意被ReentrantLock加锁区域必须用try代码块包裹，且释放锁需要在finally中来避免死锁。执行几次加锁，就需要几次释放锁。 ## 3.1 公平与非公平 **公平锁**是指多个线程按照申请锁的顺序来获取锁，线程直接进入同步队列中排队，队列中最先到的线程先获得锁。**非公平锁**是多个线程加锁时每个线程都会先去尝试获取锁，如果刚好获取到锁，那么线程无需等待，直接执行，如果获取不到锁才会被加入同步队列的队尾等待执行。 公平锁的优点在于各个线程公平平等，每个线程等待一段时间后，都有执行的机会，而它的缺点相较于于非公平锁整体执行速度更慢，吞吐量更低。同步队列中除第一个线程以外的所有线程都会阻塞，CPU唤醒阻塞线程的开销比非公平锁大。 而非公平锁非公平锁的优点是可以减少唤起线程的开销，整体的吞吐效率高，因为线程有几率不阻塞直接获得锁，CPU不必唤醒所有线程。它的缺点呢也比较明显，即队列中等待的线程可能一直或者长时间获取不到锁。 ## 3.2 可重入与非可重入 可重入锁不会阻塞 **可重入锁**又名递归锁，是指同一个线程在获取外层同步方法锁的时候，再进入该线程的内层同步方法会自动获取锁（前提锁对象得是同一个对象或者class），不会因为之前已经获取过还没释放而阻塞。**非可重入锁**与可重入锁是对立的关系，即一个线程在获取到外层同步方法锁后，再进入该方法的内层同步方法无法获取到锁，即使锁是同一个对象。 synchronized与本篇讲的ReentrantLock都属于可重入锁。可重入锁可以有效避免死锁的产生。 # 四、CAS与原子类 原子操作类，指的是java.util.concurrent.atomic包下，一系列以Atomic开头的包装类。例如`AtomicBoolean`，`AtomicInteger`，`AtomicLong`。它们分别用于`Boolean`，`Integer`，`Long`类型的原子性操作。它们都是基于CAS实现。 ## 4.1 CAS机制 CAS是英文单词Compare And Swap的缩写，翻译过来就是比较并替换。 CAS机制当中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。 更新一个变量的时候，只有当变量的预期值A和内存地址V当中的实际值相同时，才会将内存地址V对应的值修改为B。 用伪代码解释就是： if(V=A){ ----- 比较相等 swap() ----- 替换旧值，此时V=B，A=B，新的B需要到下一次修改 }else { retry() ----- 重试（自旋） } 在 Java 中，Java 并没有直接实现 CAS，CAS 相关的实现是通过 C++ 内联汇编的形式实现的。Java 代码需通过 JNI 才能调用。CAS 是一条 CPU 的原子指令（cmpxchg指令），不会造成所谓的数据不一致问题，Unsafe 提供的 CAS 方法（如compareAndSwapXXX）底层实现即为 CPU 指令 cmpxchg。 ![[Snipaste_2023-02-28_13-09-43 5.png]] ```cpp inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) { // alternative for InterlockedCompareExchange int mp = os::is_MP(); __asm { mov edx, dest mov ecx, exchange_value mov eax, compare_value LOCK_IF_MP(mp) cmpxchg dword ptr [edx], ecx } } ``` 如上面源代码所示，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀。如果程序是在多处理器上运行，就为cmpxchg指令加上lock前缀（Lock Cmpxchg）。反之，如果程序是在单处理器上运行，就省略lock前缀（单处理器自身会维护单处理器内的顺序一致性，不需要lock前缀提供的内存屏障效果）。 ## 4.2 示例 1. 在内存地址V中，存储着值为10的变量 ![[5630287-350bc3c474eef0e8.jpg]] 2. 此时线程1想要把变量的值增加1。对线程1来说，旧的预期值A=10，要修改的新值B=11。 ![[5630287-350bc3c474eef0e8 1.jpg]] 3. 在线程1要提交更新之前，另一个线程2抢先一步，把内存地址V中的变量值率先更新成了11。 ![[5630287-350bc3c474eef0e8 2.jpg]] 4. 线程1开始提交更新，首先进行A和地址V的实际值比较（Compare），发现A不等于V的实际值，提交失败。 ![[5630287-350bc3c474eef0e8 3.jpg]] 5. 线程1重新获取内存地址V的当前值，并重新计算想要修改的新值。此时对线程1来说，A=11，B=12。这个重新尝试的过程被称为自旋。 ![[5630287-f638cadea7b6cb96.webp]] 6. 这一次比较幸运，没有其他线程改变地址V的值。线程1进行Compare，发现A和地址V的实际值是相等的 ![[5630287-0a3d0b3926366d63.jpg]] 7. 线程1进行SWAP，把地址V的值替换为B，也就是12。 ![[5630287-0a3d0b3926366d63 1.jpg]] ## 4.3 优缺点 #### 优点： - 可以保证变量操作的原子性； - 并发量不是很高的情况下，使用CAS机制比使用锁机制效率更高； - 在线程对共享资源占用时间较短的情况下，使用CAS机制效率也会较高。 #### 缺点： 1. CPU开销较大 在并发量比较高的情况下，如果许多线程反复尝试更新（自旋锁 ）某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。 2. 不能保证代码块的原子性 CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。 3. ABA问题 CAS在操作的时候会检查变量的值是否被更改过，如果没有则更新值，但是带来一个问题，最开始的值是A，接着变成B，最后又变成了A。经过检查这个值确实没有修改过，因为最后的值还是A，但是实际上这个值确实已经被修改过了。为了解决这个问题，在每次进行操作的时候加上一个版本号，每次操作的就是两个值，一个版本号和某个值，A——>B——>A问题就变成了1A——>2B——>3A。在jdk中提供了AtomicStampedReference类解决ABA问题，用Pair这个内部类实现，包含两个属性，分别代表版本号和引用，在compareAndSet中先对当前引用进行检查，再对版本号标志进行检查，只有全部相等才更新值。 # 五、AQS CAS中的自旋锁有2个缺点： + 第一个是锁饥饿问题。在锁竞争激烈的情况下，可能存在一个线程一直被其他线程”插队“而一直获取不到锁的情况。 + 第二是性能问题。在实际的多核上运行的自旋锁在锁竞争激烈时性能较差。 TASLock 和 TTASLock 与上文代码类似，都是针对**一个原子状态变量**轮询的自旋锁实现，显然，自旋锁的性能和理想情况相距甚远。这是因为自旋锁锁状态中心化，在竞争激烈的情况下，锁状态变更会导致多个 CPU 的高速缓存的频繁同步，从而拖慢 CPU 效率。 为了解决这2个问题就有了CLH锁，CLH是AQS的核心。 ![[721070-20170504110246211-10684485.png]] CLH 锁是对自旋锁的一种改进，有效的解决了以上的两个缺点。首先它将线程组织成一个队列，保证先请求的线程先获得锁，避免了饥饿问题。其次锁状态去中心化，**让每个线程在不同的状态变量中自旋**，这样当一个线程释放它的锁时，只能使其后续线程的高速缓存失效，缩小了影响范围，从而减少了 CPU 的开销。 CLH 锁数据结构很简单，类似一个链表队列，所有请求获取锁的线程会排列在链表队列中，自旋访问队列中前一个节点的状态。当一个节点释放锁时，只有它的后一个节点才可以得到锁。CLH 锁本身有一个队尾指针 Tail，它是一个原子变量，指向队列最末端的 CLH 节点。每一个 CLH 节点有两个属性：所代表的线程和标识是否持有锁的状态变量。当一个线程要获取锁时，它会对 Tail 进行一个 getAndSet 的原子操作。该操作会返回 Tail 当前指向的节点，也就是当前队尾节点，然后使 Tail 指向这个线程对应的 CLH 节点，成为新的队尾节点。入队成功后，该线程会轮询上一个队尾节点的状态变量，当上一个节点释放锁后，它将得到这个锁。 AQS定义两种资源共享方式：Exclusive（独占，只有一个线程能执行，如ReentrantLock）和Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。 不同的自定义同步器争用共享资源的方式也不同。**自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可**，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法： - isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。 - tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。 - tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。 - tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。 - tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。 以ReentrantLock为例，state（同步状态）初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。 再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。 ## 5.1 CLH的数据结构 CLH中的节点表示待获取锁的对象，里面包含6个方法及属性 | 方法和属性值 | 含义 | | ------------ | -------------------------------------------------------------------------------------------- | | waitStatus | 当前节点在队列中的状态 | | thread | 表示处于该节点的线程 | | prev | 前驱指针 | | predecessor | 返回前驱节点，没有的话抛出npe | | nextWaiter | 指向下一个处于CONDITION状态的节点（由于本篇文章不讲述Condition Queue队列，这个指针不多介绍） | | next | 后继指针 | waitStatus有下面几个枚举值： | 枚举 | 含义 | | --------- | ---------------------------------------------- | | 0 | 当一个Node被初始化的时候的默认值 | | CANCELLED | 为1，表示线程获取锁的请求已经取消了 | | CONDITION | 为-2，表示节点在等待队列中，节点线程等待唤醒 | | PROPAGATE | 为-3，当前线程处在SHARED情况下，该字段才会使用 | | SIGNAL | 为-1，表示线程已经准备好了，就等资源释放了 | ## 5.2 同步状态State AQS中维护了一个名为state的字段，意为同步状态，是由Volatile修饰的，用于展示当前临界资源的获锁情况。 | 方法名 | 描述 | | ------------------------------------------------------------------ | -------------------- | | protected final int getState() | 获取State的值 | | protected final void setState(int newState) | 设置State的值 | | protected final boolean compareAndSetState(int expect, int update) | 使用CAS方式更新State | 可以通过修改State字段表示的同步状态来实现多线程的独占模式和共享模式（加锁过程）。 ### 5.2.1 独占模式 ![[27605d483e8935da683a93be015713f331378.png]] 以ReentrantLock为例，state（同步状态）初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。 举个例子：排队打饭，只有一个窗口(state)，第一个站住窗口（lock()，tryAcquire()，state+1），后一个人需要等待前人离开（unlock，state=0） #### 线程加入等待队列 当其他线程tryAcquire()失败时，会调用addWaiter加入到等待队列中去。总的来说，一个线程获取锁失败了，被放入等待队列，acquireQueued会把放入队列中的线程不断去获取锁，直到获取成功或者不再需要获取（中断）。 ### 5.2.2 共享模式 ![[27605d483e8935da683a93be015713f331378 1.png]] 以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。