Java多线程拾遗(四) 使用ReentrantLock和synchronized来保证线程安全

叁歲伎倆 2023-07-16 11:58 109阅读 0赞

#### 前言 ####

在多个线程，同时对共享资源进行操作时，会因为线程不安全，造成数据错误。在java中有不同的锁机制来避免这一问题，除此之外，还有一些线程安全的集合也供我们使用。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70]  
可能我们耳熟能详的是某些集合是线程安全的，某些是线程不安全的。线程安全的集合保证线程安全的方法也不是都一样的。

今天我们看看如何使用可重入锁`ReentrantLock`和`synchronized`来保证线程安全。

#### 线程不安全的情况 ####

在java中，ArrayList是线程不安全的，我们先模拟一个线程不安全的场景。

/**
     * @author 阳光大男孩！！！
     */
    public class CopyOnWriteArrayListTest {
        
        private static List<Integer> list = new ArrayList<>();
    
        public  static void add() {
        
            list.add(1);
        }
        public static void main(String[] args) {
        
    
            for (int i = 0; i < 10000; i++) {
        
                new Thread(() -> add()).start();
            }
    
            try {
        
                Thread.sleep(3000);
            } catch (InterruptedException e) {
        
                e.printStackTrace();
            }
            System.out.println(list.size());
        }
    
    }

在上面的代码中，我们开启10000个线程，分别对`ArrayList`对象进行`add`操作，为了让其执行完，我们让线程阻塞3s，最后打印`ArrayList`对象的大小。

看看执行结果

第一次输出了 `9907`，第二次输出了`9998`，第三次输出了`10000`，很显然这就是一个多线程操作同一个资源导致的线程不安全问题。

#### 使用synchronized关键字来保证线程安全 ####

`synchronized`关键字的就是加锁，通俗来讲，就是你在网吧打游戏，突然想小便，网吧厕所只能容纳一个人方便，所以你得等，在厕所里面的人把门锁上了，你就进不去。 相当于在厕所里面的人占住了资源。

在上例中，多线程操作的是静态的add方法，所以我们可以对add方法使用synchronized关键字来加锁。

public  synchronized static void add() {
        
            list.add(1);
        }

再次运行， 你会发现结果一直都是10000，即正确的，避免了多线程操作同一个资源带来的线程不安全问题。

#### 使用ReentrantLock锁来保证线程安全 ####

使用ReentrantLock锁来保证线程安全也是一样的，多线程操作的是add方法，所以我们要在add方法中加锁

private static final Lock lock = new ReentrantLock();
     
     public static void add() {
        
     		//加锁
            lock.lock();
            try {
        
                list.add(1);
            }catch (Exception e)
            {
        
                e.printStackTrace();
            }
            finally {
        
            //释放锁
                lock.unlock();
            }
        }

#### ReentrantLock原理分析 ####

ReentrantLock内部实现有两种方式，公平锁和非公平锁。

默认是非公平锁

public ReentrantLock() {
        
            sync = new NonfairSync();
        }

也可以在构造方法中指定公平锁

public ReentrantLock(boolean fair) {
        
            sync = fair ? new FairSync() : new NonfairSync();
        }

需要特别注意的是，都是上面都是直接new的锁对象，这两个锁对象都是继承于Sync这个内部类的，下面贴出非公平锁的代码

static final class NonfairSync extends Sync {
        
            private static final long serialVersionUID = 7316153563782823691L;
    
            /**
             * Performs lock.  Try immediate barge, backing up to normal
             * acquire on failure.
             */
            final void lock() {
        
                if (compareAndSetState(0, 1))
                    setExclusiveOwnerThread(Thread.currentThread());
                else
                    acquire(1);
            }
    
            protected final boolean tryAcquire(int acquires) {
        
                return nonfairTryAcquire(acquires);
            }
        }

而Sync又是继承于AQS同步器的，所以归根到底还是通过AQS的思想来实现可重入锁，这也难怪AQS被称为JUC并发控制的基础框架了。

abstract static class Sync extends AbstractQueuedSynchronizer {
        
            private static final long serialVersionUID = -5179523762034025860L;
    
          	// 供子类实现
            abstract void lock();
    
            // 尝试获取锁
            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;
            }
    		// 尝试释放锁
            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);
                }
                setState(c);
                return free;
            }

接下来以最核心的lock()和unlock()来说明原理。

![在这里插入图片描述][20200623084700135.png]  
可以看到ReentrantLock的lock方法就是调用sync变量的lock()。

前面通过构造方法可以看出来事实上sync指向的是是Sync的子类对象变量，即默认的`NofairSync`类，即Sync类的具体实现类，也就是AQS的子类。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 1]

所以说实现锁，其实就是调用NonfairSync的lock()方法:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 2]  
如果CAS成功，设置当前拥有独占权的线程  
![在这里插入图片描述][2020062421503241.png]  
否则的话，执行`acquire()`  
![在这里插入图片描述][20200624215248858.png]

*  tryAcquire：会尝试再次通过CAS获取一次锁。
 *  addWaiter：将当前线程加入上面锁的双向链表（等待队列）中  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 3]
 *  acquireQueued：通过自旋，判断当前队列节点是否可以获取锁。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 4]  
整体的流程如下  
![在这里插入图片描述][format_png_pic_center]  
再看看unlock()，释放锁的方法  
![在这里插入图片描述][20200624220019343.png]  
可以看出，释放锁就是对AQS中的状态值State进行修改。![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 5]  
唤醒下一个结点  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 6]

#### synchronized原理分析 ####

synchronized内部是通过monitorenter和monitorexit一组指令来加锁的。

JDK6之前，synchronized是依靠操作系统内部的互斥锁实现的，这设计到操作系统用户态和系统态的切换，性能很低。

JDK6之后，提供了三种monitor的实现方式，分别是偏向锁，轻量级锁，重量级锁。

这是锁的三级状态，从偏向锁到重量级锁，就是锁升级过程。

*  偏向锁：被锁对象的对象头有一个threadid，这个threadid初始为空，当被线程访问时，如果锁对象头中threadid为空，那么置为线程id，当线程访问结束时，再次置空。
 *  轻量级锁: 可以看出来偏向锁当只有一个线程访问资源时，是没有问题的，但此时，访问线程会发现对象头中threadid与当前线程id不同，代表有其他线程正在访问，此时升级为轻量级锁。
 *  重量级锁：升级成轻量级锁后，不断自旋去获取锁，当一定次数仍获取不到锁时，升级为重量级锁。

synchronized**如何保证可见性**：当读取时，从主内存读取，当释放锁时，将工作内存中的写入到主内存中。

以使用synchronized同步实现代码块锁，为例，在执行同步代码块之前之后都有一个monitor字样，其中前面的是monitorenter，后面的是离开monitorexit，不难想象一个线程也执行同步代码块，首先要获取锁，而获取锁的过程就是monitorenter ，在执行完代码块之后，要释放锁，释放锁就是执行monitorexit指令。  
![在这里插入图片描述][format_png_pic_center 1]  
**为什么会有两个monitorexit呢？**

这个主要是防止在同步代码块中线程因异常退出，而锁没有得到释放，这必然会造成死锁（等待的线程永远获取不到锁）。因此最后一个monitorexit是保证在异常情况下，锁也可以得到释放，避免死锁。  
仅有`ACC_SYNCHRONIZED`这么一个标志，该标记表明线程进入该方法时，需要monitorenter，退出该方法时需要monitorexit。

**synchronized修饰静态方法和非静态的区别？**

synchronized修饰静态方法时，是对整个类加锁，叫类锁。

synchronized修饰非静态方法时，是对调用改方法的对象加锁，叫对象锁。

#### ReentrantLock和synchronized的异同 ####

1.  ReentrantLock是Lock接口的一个实现类，synchronized是一个java 关键字
2.  synchronized无法判断是否获取到锁，ReentrantLock可以
3.  synchronized会自动释放锁，ReentrantLock需要显式地手动加锁和释放锁。如果不释放锁，可能会出现死锁问题
4.  广义来讲， synchronized和ReentrantLock都是可重入锁，但是synchronized是非公平的、不可以中断的。 ReentrantLock是一个类，其中有构造方法，可以设置非公平锁和公平锁。

### 补充：什么是可重入锁？ ###

线程可以多次获得锁，以避免一定程度的死锁问题。

#### 总结 ####

保证线程安全的一个有效方法就是互斥同步，互斥是实现同步的一种方法，当达到了同步，也就解决了线程安全的问题。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70]: /images/20230528/4ee472dd817f486b85eead9063302329.png
[20200623084700135.png]: /images/20230528/74d89a38b5854cde962d7234ee16a0e0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 1]: /images/20230528/02cacf83093443af828523e1abd4547b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 2]: /images/20230528/83c8f7c127e144a69f9fafb68cd27a29.png
[2020062421503241.png]: /images/20230528/5d87429513e24ac2baae26987933b21e.png
[20200624215248858.png]: /images/20230528/c0165daa470d4a81bcc3673e6916ac50.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 3]: /images/20230528/73e1a014337a43f2af801661d9e34300.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 4]: /images/20230528/fc52ea84efcf46b69093113798f18aa6.png
[format_png_pic_center]: /images/20230528/7515c4e033f145eda3516149c3ceb1d1.png
[20200624220019343.png]: /images/20230528/51c9b8772c44421dbd4a9d510ea36e0c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 5]: /images/20230528/a652b58805324496b34f84711a8819cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzg4OTg0MQ_size_16_color_FFFFFF_t_70 6]: /images/20230528/8b554b3565c0414ea2a4d5444ab59509.png
[format_png_pic_center 1]: /images/20230528/409f38dafb214aa2b9245903d3a393d9.png