• Java锁lock的应用


    从Java 5之后,在java.util.concurrent.locks包下提供了另外一种方式来实现同步访问,那就是Lock。
      也许有朋友会问,既然都可以通过synchronized来实现同步访问了,那么为什么还需要提供Lock?这个问题将在下面进行阐述。本文先从synchronized的缺陷讲起,然后再讲述java.util.concurrent.locks包下常用的有哪些类和接口,最后讨论以下一些关于锁的概念方面的东西

    一.synchronized的缺陷

    synchronized是java中的一个关键字,也就是说是Java语言内置的特性。那么为什么会出现Lock呢?

    我们了解到如果一个代码块被synchronized修饰了,当一个线程获取了对应的锁,并执行该代码块时,其他线程便只能一直等待,等待获取锁的线程释放锁,而这里获取锁的线程释放锁只会有两种情况:
      1)获取锁的线程执行完了该代码块,然后线程释放对锁的占有;
      2)线程执行发生异常,此时JVM会让线程自动释放锁。

    那么如果这个获取锁的线程由于要等待IO或者其他原因(比如调用sleep方法)被阻塞了,但是又没有释放锁,其他线程便只能干巴巴地等待,试想一下,这多么影响程序执行效率。
    因此就需要有一种机制可以不让等待的线程一直无期限地等待下去(比如只等待一定的时间或者能够响应中断),通过Lock就可以办到。

    再举个例子:当有多个线程读写文件时,读操作和写操作会发生冲突现象,写操作和写操作会发生冲突现象,但是读操作和读操作不会发生冲突现象。但是采用synchronized关键字来实现同步的话,就会导致一个问题:
    如果多个线程都只是进行读操作,所以当一个线程在进行读操作时,其他线程只能等待无法进行读操作。

    因此就需要一种机制来使得多个线程都只是进行读操作时,线程之间不会发生冲突,通过Lock就可以办到。

    另外,通过Lock可以知道线程有没有成功获取到锁。这个是synchronized无法办到的。

    总结一下:
    也就是说Lock提供了比synchronized更多的功能。但是要注意以下几点:
      1)Lock不是Java语言内置的,synchronized是Java语言的关键字,因此是内置特性。Lock是一个类,通过这个类可以实现同步访问;
      2)Lock和synchronized有一点非常大的不同,采用synchronized不需要用户去手动释放锁,当synchronized方法或者synchronized代码块执行完之后,系统会自动让线程释放对锁的占用;而Lock则必须要用户去手动释放锁,如果没有主动释放锁,就有可能导致出现死锁现象。

    二.java.util.concurrent.locks包下常用的类

    下面我们就来探讨一下java.util.concurrent.locks包中常用的类和接口。

    2.1 Lock

    首先要说明的就是Lock,通过查看Lock的源码可知,Lock是一个接口:

    public interface Lock {
        void lock();
        void lockInterruptibly() throws InterruptedException;
        boolean tryLock();
        boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
        void unlock();
        Condition newCondition();
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8

    下面来逐个讲述Lock接口中每个方法的使用,lock()、tryLock()、tryLock(long time, TimeUnit unit)和lockInterruptibly()是用来获取锁的。unLock()方法是用来释放锁的。newCondition()这个方法暂且不在此讲述,会在后面的线程协作一文中讲述。

    在Lock中声明了四个方法来获取锁,那么这四个方法有何区别呢?

    lock()方法是平常使用得最多的一个方法,就是用来获取锁。如果锁已被其他线程获取,则进行等待。

    由于在前面讲到如果采用Lock,必须主动去释放锁,并且在发生异常时,不会自动释放锁。因此一般来说,使用Lock必须在try{}catch{}块中进行,并且将释放锁的操作放在finally块中进行,以保证锁一定被被释放,防止死锁的发生。通常使用Lock来进行同步的话,是以下面这种形式去使用的:

    Lock lock = ...;
    lock.lock();
    try{
        //处理任务
    }catch(Exception ex){
         
    }finally{
        lock.unlock();   //释放锁
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9

    tryLock()方法是有返回值的,它表示用来尝试获取锁,如果获取成功,则返回true,如果获取失败(即锁已被其他线程获取),则返回false,也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。

    tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的,只不过区别在于这个方法在拿不到锁时会等待一定的时间,在时间期限之内如果还拿不到锁,就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁,则返回true。
    所以,一般情况下通过tryLock来获取锁时是这样使用的:

    Lock lock = ...;
    if(lock.tryLock()) {
         try{
             //处理任务
         }catch(Exception ex){
             
         }finally{
             lock.unlock();   //释放锁
         } 
    }else {
        //如果不能获取锁,则直接做其他事情
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12

    lockInterruptibly()方法比较特殊,当通过这个方法去获取锁时,如果线程正在等待获取锁,则这个线程能够响应中断,即中断线程的等待状态。也就使说,当两个线程同时通过lock.lockInterruptibly()想获取某个锁时,假若此时线程A获取到了锁,而线程B只有在等待,那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。
    由于lockInterruptibly()的声明中抛出了异常,所以lock.lockInterruptibly()必须放在try块中或者在调用lockInterruptibly()的方法外声明抛出InterruptedException。
    因此lockInterruptibly()一般的使用形式如下:

    public void method() throws InterruptedException {
        lock.lockInterruptibly();
        try {  
         //.....
        }
        finally {
            lock.unlock();
        }  
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9

    注意,当一个线程获取了锁之后,是不会被interrupt()方法中断的。因为本身在前面的文章中讲过单独调用interrupt()方法不能中断正在运行过程中的线程,只能中断阻塞过程中的线程。

    因此当通过lockInterruptibly()方法获取某个锁时,如果不能获取到,只有进行等待的情况下,是可以响应中断的。

    而用synchronized修饰的话,当一个线程处于等待某个锁的状态,是无法被中断的,只有一直等待下去。

    2.2 ReentrantLock

    ReentrantLock,意思是“可重入锁”,关于可重入锁的概念在下一节讲述。ReentrantLock是唯一实现了Lock接口的类,并且ReentrantLock提供了更多的方法。下面通过一些实例看具体看一下如何使用ReentrantLock。
      
    例子1,lock()的正确使用方法

    public class Test {
        private ArrayList<Integer> arrayList = new ArrayList<Integer>();
        public static void main(String[] args)  {
            final Test test = new Test();
             
            new Thread(){
                public void run() {
                    test.insert(Thread.currentThread());
                };
            }.start();
             
            new Thread(){
                public void run() {
                    test.insert(Thread.currentThread());
                };
            }.start();
        }  
         
        public void insert(Thread thread) {
            Lock lock = new ReentrantLock();    //注意这个地方
            lock.lock();
            try {
                System.out.println(thread.getName()+"得到了锁");
                for(int i=0;i<5;i++) {
                    arrayList.add(i);
                }
            } catch (Exception e) {
                // TODO: handle exception
            }finally {
                System.out.println(thread.getName()+"释放了锁");
                lock.unlock();
            }
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34

    各位朋友先想一下这段代码的输出结果是什么?

    Thread-0得到了锁
    Thread-1得到了锁
    Thread-0释放了锁
    Thread-1释放了锁
    
    • 1
    • 2
    • 3
    • 4

    也许有朋友会问,怎么会输出这个结果?第二个线程怎么会在第一个线程释放锁之前得到了锁?原因在于,在insert方法中的lock变量是局部变量,每个线程执行该方法时都会保存一个副本,那么理所当然每个线程执行到lock.lock()处获取的是不同的锁,所以就不会发生冲突。
     
    知道了原因改起来就比较容易了,只需要将lock声明为类的属性即可。

    public class Test {
        private ArrayList<Integer> arrayList = new ArrayList<Integer>();
        private Lock lock = new ReentrantLock();    //注意这个地方
        public static void main(String[] args)  {
            final Test test = new Test();
             
            new Thread(){
                public void run() {
                    test.insert(Thread.currentThread());
                };
            }.start();
             
            new Thread(){
                public void run() {
                    test.insert(Thread.currentThread());
                };
            }.start();
        }  
         
        public void insert(Thread thread) {
            lock.lock();
            try {
                System.out.println(thread.getName()+"得到了锁");
                for(int i=0;i<5;i++) {
                    arrayList.add(i);
                }
            } catch (Exception e) {
                // TODO: handle exception
            }finally {
                System.out.println(thread.getName()+"释放了锁");
                lock.unlock();
            }
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34

    这样就是正确地使用Lock的方法了。

    例子2,tryLock()的使用方法

    public class Test {
        private ArrayList<Integer> arrayList = new ArrayList<Integer>();
        private Lock lock = new ReentrantLock();    //注意这个地方
        public static void main(String[] args)  {
            final Test test = new Test();
             
            new Thread(){
                public void run() {
                    test.insert(Thread.currentThread());
                };
            }.start();
             
            new Thread(){
                public void run() {
                    test.insert(Thread.currentThread());
                };
            }.start();
        }  
         
        public void insert(Thread thread) {
            if(lock.tryLock()) {
                try {
                    System.out.println(thread.getName()+"得到了锁");
                    for(int i=0;i<5;i++) {
                        arrayList.add(i);
                    }
                } catch (Exception e) {
                    // TODO: handle exception
                }finally {
                    System.out.println(thread.getName()+"释放了锁");
                    lock.unlock();
                }
            } else {
                System.out.println(thread.getName()+"获取锁失败");
            }
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37

    输出结果:

    Thread-0得到了锁
    Thread-1获取锁失败
    Thread-0释放了锁
    
    • 1
    • 2
    • 3

    例子3,lockInterruptibly()响应中断的使用方法:

    public class Test {
        private Lock lock = new ReentrantLock();   
        public static void main(String[] args)  {
            Test test = new Test();
            MyThread thread1 = new MyThread(test);
            MyThread thread2 = new MyThread(test);
            thread1.start();
            thread2.start();
             
            try {
                Thread.sleep(2000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            thread2.interrupt();
        }  
         
        public void insert(Thread thread) throws InterruptedException{
            lock.lockInterruptibly();   //注意,如果需要正确中断等待锁的线程,必须将获取锁放在外面,然后将InterruptedException抛出
            try {  
                System.out.println(thread.getName()+"得到了锁");
                long startTime = System.currentTimeMillis();
                for(    ;     ;) {
                    if(System.currentTimeMillis() - startTime >= Integer.MAX_VALUE)
                        break;
                    //插入数据
                }
            }
            finally {
                System.out.println(Thread.currentThread().getName()+"执行finally");
                lock.unlock();
                System.out.println(thread.getName()+"释放了锁");
            }  
        }
    }
     
    class MyThread extends Thread {
        private Test test = null;
        public MyThread(Test test) {
            this.test = test;
        }
        @Override
        public void run() {
             
            try {
                test.insert(Thread.currentThread());
            } catch (InterruptedException e) {
                System.out.println(Thread.currentThread().getName()+"被中断");
            }
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51

    运行之后,发现thread2能够被正确中断。

    2.3 ReadWriteLock

    ReadWriteLock也是一个接口,在它里面只定义了两个方法:

    public interface ReadWriteLock {
        /**
         * Returns the lock used for reading.
         *
         * @return the lock used for reading.
         */
        Lock readLock();
     
        /**
         * Returns the lock used for writing.
         *
         * @return the lock used for writing.
         */
        Lock writeLock();
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15

    一个用来获取读锁,一个用来获取写锁。也就是说将文件的读写操作分开,分成2个锁来分配给线程,从而使得多个线程可以同时进行读操作。下面的ReentrantReadWriteLock实现了ReadWriteLock接口。

    2.4 ReentrantReadWriteLock

    ReentrantReadWriteLock里面提供了很多丰富的方法,不过最主要的有两个方法:readLock()和writeLock()用来获取读锁和写锁。

    下面通过几个例子来看一下ReentrantReadWriteLock具体用法。

    假如有多个线程要同时进行读操作的话,先看一下synchronized达到的效果:

    public class Test {
        private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
         
        public static void main(String[] args)  {
            final Test test = new Test();
             
            new Thread(){
                public void run() {
                    test.get(Thread.currentThread());
                };
            }.start();
             
            new Thread(){
                public void run() {
                    test.get(Thread.currentThread());
                };
            }.start();
             
        }  
         
        public synchronized void get(Thread thread) {
            long start = System.currentTimeMillis();
            while(System.currentTimeMillis() - start <= 1) {
                System.out.println(thread.getName()+"正在进行读操作");
            }
            System.out.println(thread.getName()+"读操作完毕");
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28

    这段程序的输出结果会是,直到thread1执行完读操作之后,才会打印thread2执行读操作的信息。

    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0读操作完毕
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1读操作完毕
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65
    • 66
    • 67
    • 68
    • 69
    • 70
    • 71
    • 72
    • 73

    而改成用读写锁的话:

    public class Test {
        private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
         
        public static void main(String[] args)  {
            final Test test = new Test();
             
            new Thread(){
                public void run() {
                    test.get(Thread.currentThread());
                };
            }.start();
             
            new Thread(){
                public void run() {
                    test.get(Thread.currentThread());
                };
            }.start();
             
        }  
         
        public void get(Thread thread) {
            rwl.readLock().lock();
            try {
                long start = System.currentTimeMillis();
                 
                while(System.currentTimeMillis() - start <= 1) {
                    System.out.println(thread.getName()+"正在进行读操作");
                }
                System.out.println(thread.getName()+"读操作完毕");
            } finally {
                rwl.readLock().unlock();
            }
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34

    此时打印的结果为:

    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-0正在进行读操作
    Thread-1正在进行读操作
    Thread-0读操作完毕
    Thread-1读操作完毕
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49

    说明thread1和thread2在同时进行读操作。
    这样就大大提升了读操作的效率。

    不过要注意的是,如果有一个线程已经占用了读锁,则此时其他线程如果要申请写锁,则申请写锁的线程会一直等待释放读锁。
    如果有一个线程已经占用了写锁,则此时其他线程如果申请写锁或者读锁,则申请的线程会一直等待释放写锁。
    关于ReentrantReadWriteLock类中的其他方法感兴趣的朋友可以自行查阅API文档。

    2.5 Lock和synchronized的选择

    总结来说,Lock和synchronized有以下几点不同:
      1)Lock是一个接口,而synchronized是Java中的关键字,synchronized是内置的语言实现;
      2)synchronized在发生异常时,会自动释放线程占有的锁,因此不会导致死锁现象发生;而Lock在发生异常时,如果没有主动通过unLock()去释放锁,则很可能造成死锁现象,因此使用Lock时需要在finally块中释放锁;
      3)Lock可以让等待锁的线程响应中断,而synchronized却不行,使用synchronized时,等待的线程会一直等待下去,不能够响应中断;
      4)通过Lock可以知道有没有成功获取锁,而synchronized却无法办到。
      5)Lock可以提高多个线程进行读操作的效率。

    在性能上来说,如果竞争资源不激烈,两者的性能是差不多的,而当竞争资源非常激烈时(即有大量线程同时竞争),此时Lock的性能要远远优于synchronized。所以说,在具体使用时要根据适当情况选择。

    2.6 LockSupport

    LockSupport类,是JUC包中的一个工具类,定义了一组静态方法,提供最基本的线程阻塞和唤醒功能,是构建同步组件的基础工具,用来创建锁和其他同步类的基本线程阻塞原语。

    LockSupport类的核心方法其实就两个:park() 和 unpark(),其中 park() 方法用来阻塞线程,unpark()方法用于唤醒指定线程。

    和Object类的wait() 和 signal() 方法有些类似,但是LockSupport的这两种方法从语意上讲比Object类的方法更清晰,而且可以针对指定线程进行阻塞和唤醒。

    LockSupport类使用了一种名为Permit(许可)的概念来做到阻塞和唤醒线程的功能,可以把许可看成是一种(0,1)信号量(Semaphore),但与Semaphore不同的是,许可的量加上限1。

    初始时,permit为0,当调用 unpark() 方法时,线程的permit加1,当调用 park()方法时,如果permit为0,则调用线程进入阻塞状态。

    假设现在需要实现一种FIFO类型的独占锁,可以把这种锁看成是ReentrantLock的公平锁简单版本,且是不可重入的,就是说当一个线程获得锁后,其他等待线程以FIFO的调度方式等待获取锁。

    import java.util.Queue;
    import java.util.concurrent.ConcurrentLinkedQueue;
    import java.util.concurrent.atomic.AtomicBoolean;
    import java.util.concurrent.locks.LockSupport;
    
     class FIFOMutex  {
        private final AtomicBoolean locked = new AtomicBoolean(false);
        private final Queue<Thread> waiters = new ConcurrentLinkedQueue<>();
    
        public void lock(){
            Thread current = Thread.currentThread();
            waiters.add(current);
            // 如果当前线程不在队首,或锁已被占用,则当前线程阻塞
            // 这个判断的内在意图:锁必须由队首元素拿到
            while (waiters.peek() != current || !locked.compareAndSet(false,true)){
                LockSupport.park();
            }
            waiters.remove();// 删除队首元素
        }
    
    
        public void unlock(){
            locked.set(false);
            LockSupport.unpark(waiters.peek());
        }
    }
    public class TestFIFOMutex {
        public static void main(String[] args) throws InterruptedException {
            FIFOMutex mutex = new FIFOMutex();
            MyThread a1 = new MyThread("a", mutex);
            MyThread a2 = new MyThread("b", mutex);
            MyThread a3 = new MyThread("c", mutex);
            a1.start();
            a2.start();
            a3.start();
            a1.join();
            a2.join();
            a3.join();
            System.out.println("Finished");
        }
    }
    
    class MyThread extends Thread{
        private String name;
        private FIFOMutex mutex;
        private static int count;
        public MyThread(String name, FIFOMutex mutex) {
            this.name = name;
            this.mutex = mutex;
    
        }
    
        @Override
        public void run() {
            for (int i = 0; i < 20; i++) {
                mutex.lock();
                count++;
                System.out.println("thread:"+Thread.currentThread().getName()+" name:" + name + " count:" + count);
                mutex.unlock();
            }
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62

    上述FIFOMutex类的实现中,当判断锁已被占用时,会调用 LockSupport.park(this) 方法,将当前调用线程阻塞;当使用完锁时,会调用 LockSupport.unpark(waiters.peek()) 方法将等待队列中的队首线程唤醒。

    通过LockSupport的这两个方法,可以很方便的阻塞和唤醒线程。

    park 方法是会响应中断的,但是不会抛出异常。(也就是说如果当前调用线程被中断,则会立即返回但不会抛出中断异常)

    park 的重载方法 park(Object blocker),会传入一个blocker对象,所谓Blocker对象,其实就是当前线程调用时所在调用对象(如上述示例中的FIFOMutex对象)。该对象一般供监视、诊断工具确定线程受阻塞的原因时使用。

    2.7 Condition

    在没有Lock之前,我们使用synchronized来控制同步,配合Object的wait()、wait(long timeout)、notify()、以及notifyAll 等方法可以实现等待/通知模式。
    Condition接口也提供了类似于Object的监听器方法、与Lock接口配合可以实现等待/通知模式,但是两者还是有很大区别的,下图是两者的对比:

    Condition 将 Object 监视器方法(wait、notify 和 notifyAll)分解成截然不同的对象,以便通过将这些对象与任意 Lock 实现组合使用,为每个对象提供多个等待 set(wait-set)。其中,Lock 替代了 synchronized 方法和语句的使用,Condition 替代了 Object 监视器方法的使用。

    条件(也称为条件队列 或条件变量)为线程提供了一个含义,以便在某个状态条件现在可能为 true 的另一个线程通知它之前,一直挂起该线程(即让其“等待”)。因为访问此共享状态信息发生在不同的线程中,所以它必须受保护,因此要将某种形式的锁与该条件相关联。等待提供一个条件的主要属性是:以原子方式 释放相关的锁,并挂起当前线程,就像 Object.wait 做的那样。

    Condition 实例实质上被绑定到一个锁上。要为特定 Lock 实例获得 Condition 实例,请使用其 newCondition() 方法。

    核心方法
    Condition提供了一系列的方法来对阻塞和唤醒线程:

    await():造成当前线程在接到信号或被中断之前一直处于等待状态。

    await(long time, TimeUnit unit) :造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。

    awaitNanos(long nanosTimeout) :造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。返回值表示剩余时间,如果在nanosTimesout之前唤醒,那么返回值 = nanosTimeout - 消耗时间,如果返回值 <= 0 ,则可以认定它已经超时了。

    awaitUninterruptibly() :造成当前线程在接到信号之前一直处于等待状态。【注意:该方法对中断不敏感】。

    awaitUntil(Date deadline) :造成当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态。如果没有到指定时间就被通知,则返回true,否则表示到了指定时间,返回返回false。

    signal() :唤醒一个等待线程。该线程从等待方法返回前必须获得与Condition相关的锁。

    signalAll() :唤醒所有等待线程。能够从等待方法返回的线程必须获得与Condition相关的锁。

    Condition是一种广义上的条件队列。他为线程提供了一种更为灵活的等待/通知模式,线程在调用await方法后执行挂起操作,直到线程等待的某个条件为真时才会被唤醒。Condition必须要配合锁一起使用,因为对共享状态变量的访问发生在多线程环境下。一个Condition的实例必须与一个Lock绑定,因此Condition一般都是作为Lock的内部实现。

    源码探索
    获取一个Condition必须要通过Lock的newCondition()方法。该方法定义在接口Lock下,返回的结果是绑定到此 Lock 实例的新 Condition 实例。
    Condition为一个接口,其下仅有一个实现类ConditionObject,由于Condition的操作需要获取相关的锁,而AQS则是同步锁的实现基础,所以ConditionObject则定义为AQS的内部类。

    public class ConditionObject implements Condition, java.io.Serializable {
        // 省略方法
    }
    
    • 1
    • 2
    • 3

    等待队列
    每个Condition对象都包含着一个FIFO队列,该队列是Condition对象通知/等待功能的关键。
    在队列中每一个节点都包含着一个线程引用,该线程就是在该Condition对象上等待的线程。
    Condition的定义:

     public class ConditionObject implements Condition, java.io.Serializable {
            private static final long serialVersionUID = 1173984872572414699L;
            
            /** First node of condition queue. */
            private transient Node firstWaiter;
            
            /** Last node of condition queue. */
            private transient Node lastWaiter;
    
            /**
             * Creates a new {@code ConditionObject} instance.
             */
            public ConditionObject() { }
    
            // Internal methods
            // 省略方法
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17

    从上面代码可以看出Condition拥有首节点(firstWaiter),尾节点(lastWaiter)。
    当前线程调用await()方法,将会以当前线程构造成一个节点(Node),并将节点加入到该队列的尾部。

    Node里面包含了当前线程的引用。Node定义与AQS的CLH同步队列的节点使用的都是同一个类。
    Condition的队列结构比CLH同步队列的结构简单些,新增过程较为简单只需要将原尾节点的nextWaiter指向新增节点,然后更新lastWaiter即可。

    等待
    调用Condition的await()方法会使当前线程进入等待状态,同时会加入到Condition等待队列并释放锁。
    当从await()方法返回时,当前线程一定是获取了Condition相的锁。

    public final void await() throws InterruptedException {
                // 当前线程中断、直接异常
                if (Thread.interrupted())
                    throw new InterruptedException();
                    
                //加入等待队列
                Node node = addConditionWaiter();
                
                //释放锁
                int savedState = fullyRelease(node);
                
                int interruptMode = 0;
                
                //检测当前节点是否在同步队列上、如果不在则说明该节点没有资格竞争锁,继续等待。
                while (!isOnSyncQueue(node)) {
                
                    // 挂起线程
                    LockSupport.park(this);
                    
                    // 线程释是否被中断,中断直接退出
                    if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                        break;
                }
                
                // 获取同步状态
                if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                    interruptMode = REINTERRUPT;
                
                // 清理条件队列
                if (node.nextWaiter != null) // clean up if cancelled
                    unlinkCancelledWaiters();
                if (interruptMode != 0)
                    reportInterruptAfterWait(interruptMode);
            }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34

    此段代码的逻辑是:首先将当前线程新建一个节点同时加入到等待队列中,然后释放当前线程持有的同步状态。
    然后则是不断检测该节点代表的线程是否出现在CLH同步队列中(收到signal信号之后就会在AQS队列中检测到),如果不存在则一直挂起,否则参与竞争同步状态。

    加入条件队列(addConditionWaiter())源码如下

    private Node addConditionWaiter() {
                
                //队列的尾节点
                Node t = lastWaiter;
                // If lastWaiter is cancelled, clean out.
                
                // 如果该节点的状态的不是CONDITION,则说明该节点不在等待队列上,需要清除
                if (t != null && t.waitStatus != Node.CONDITION) {
                    
                    // 清除等待队列中状态不为CONDITION的节点
                    unlinkCancelledWaiters();
                    
                    //清除后重新获取尾节点
                    t = lastWaiter;
                }
                
                // 将当前线程构造成等待节点
                Node node = new Node(Thread.currentThread(), Node.CONDITION);
                
                // 将node节点添加到等待队列的尾部
                
                if (t == null)
                    firstWaiter = node;
                else
                    t.nextWaiter = node;
                lastWaiter = node;
                return node;
            }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28

    该方法主要是将当前线程加入到Condition条件队列中。当然在加入到尾节点之前会清除所有状态不为Condition的节点。

    fullyRelease(Node node),负责释放该线程持有的锁

    final int fullyRelease(Node node) {
            boolean failed = true;
            try {
            
                // 获取节点持有锁的数量
                int savedState = getState();
                
                // 释放锁也就是释放共享状态
                if (release(savedState)) {
                    failed = false;
                    return savedState;
                } else {
                    throw new IllegalMonitorStateException();
                }
            } finally {
                if (failed)
                    node.waitStatus = Node.CANCELLED;
            }
        }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19

    isOnSyncQueue(Node node):如果一个节点刚开始在条件队列上,现在在同步队列上获取锁则返回true。

    final boolean isOnSyncQueue(Node node) {
            
            // 状态为CONDITION 、前驱节点为空,返回false
            if (node.waitStatus == Node.CONDITION || node.prev == null)
                return false;
                
             // 如果后继节点不为空,则说明节点肯定在同步队列中
            if (node.next != null) // If has successor, it must be on queue
                return true;
            /*
             * node.prev can be non-null, but not yet on queue because
             * the CAS to place it on queue can fail. So we have to
             * traverse from tail to make sure it actually made it.  It
             * will always be near the tail in calls to this method, and
             * unless the CAS failed (which is unlikely), it will be
             * there, so we hardly ever traverse much.
             */
            return findNodeFromTail(node);
        }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19

    unlinkCancelledWaiters():负责将条件队列中状态不为Condition的节点删除。

    private void unlinkCancelledWaiters() {
                
                // 首节点
                Node t = firstWaiter;
                
                Node trail = null;
                // 从头开始清除状态不为CONDITION的节点
                while (t != null) {
                    Node next = t.nextWaiter;
                    
                    if (t.waitStatus != Node.CONDITION) {
                        t.nextWaiter = null;
                        if (trail == null)
                            firstWaiter = next;
                        else
                            trail.nextWaiter = next;
                        if (next == null)
                            lastWaiter = trail;
                    }
                    else
                        trail = t;
                    t = next;
                }
            }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24

    通知
    调用Condition的signal()方法,将会唤醒在等待队列中等待最长时间的节点(条件队列里的首节点),在唤醒节点前,会将节点移到同步队列中。

    public final void signal() {
    
                // 如果同步是以独占方式进行的,则返回 true;其他情况则返回 false  
                if (!isHeldExclusively())
                    throw new IllegalMonitorStateException();
                
                // 唤醒首节点
                Node first = firstWaiter;
                
                if (first != null)
                    doSignal(first);
            }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12

    该方法首先会判断当前线程是否已经获得了锁,这是前置条件。然后唤醒条件队列中的头节点。

    doSignal(Node first):唤醒头节点

    private void doSignal(Node first) {
                do {
                    // 修改头节点、方便移除
                    if ( (firstWaiter = first.nextWaiter) == null)
                        lastWaiter = null;
                    first.nextWaiter = null;
                    // 将该节点移到同步队列
                } while (!transferForSignal(first) &&
                         (first = firstWaiter) != null);
            }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10

    **doSignal(Node first)**主要是做两件事:
    1.修改头节点;
    2.调用transferForSignal(Node first) 方法将节点移动到CLH同步队列中。

    transferForSignal(Node first)源码如下

    final boolean transferForSignal(Node node) {
            /*
             * If cannot change waitStatus, the node has been cancelled.
             */
             // 将该节点的状态改为初始状态0
            if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
                return false;/*
             * Splice onto queue and try to set waitStatus of predecessor to
             * indicate that thread is (probably) waiting. If cancelled or
             * attempt to set waitStatus fails, wake up to resync (in which
             * case the waitStatus can be transiently and harmlessly wrong).
             */
             
             // 将该节点添加到同步队列的尾部、返回的是旧的尾部节点,也就是 node.prev节点
            Node p = enq(node);
            
            //如果结点p的状态为cancel 或者修改waitStatus失败,则直接唤醒
            int ws = p.waitStatus;
            if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
                LockSupport.unpark(node.thread);
            return true;
        }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24

    整个通知的流程如下:

    判断当前线程是否已经获取了锁,如果没有获取则直接抛出异常,因为获取锁为通知的前置条件。

    如果线程已经获取了锁,则将唤醒条件队列的首节点。

    唤醒首节点是先将条件队列中的头节点移出,然后调用AQS的enq(Node node)方法将其安全地移到CLH同步队列中 。

    最后判断如果该节点的同步状态是否为Cancel,或者修改状态为Signal失败时,则直接调用LockSupport唤醒该节点的线程。

    一个线程获取锁后,通过调用Condition的await()方法,会将当前线程先加入到条件队列中,然后释放锁,最后通过isOnSyncQueue(Node node)方法不断自检看节点是否已经在CLH同步队列了,如果是则尝试获取锁,否则一直挂起。

    当线程调用signal()方法后,程序首先检查当前线程是否获取了锁,然后通过doSignal(Node first)方法唤醒CLH同步队列的首节点。被唤醒的线程,将从await()方法中的while循环中退出来,然后调用acquireQueued()方法竞争同步状态。

    栗子:

    class BoundedBuffer {
       final Lock lock = new ReentrantLock();
       final Condition notFull  = lock.newCondition(); 
       final Condition notEmpty = lock.newCondition(); 
    
       final Object[] items = new Object[100];
       int putptr, takeptr, count;
    
       public void put(Object x) throws InterruptedException {
         lock.lock();
         try {
           while (count == items.length)
             notFull.await();
           items[putptr] = x;
           if (++putptr == items.length) putptr = 0;
           ++count;
           notEmpty.signal();
         } finally {
           lock.unlock();
         }
       }
    
       public Object take() throws InterruptedException {
         lock.lock();
         try {
           while (count == 0)
             notEmpty.await();
           Object x = items[takeptr];
           if (++takeptr == items.length) takeptr = 0;
           --count;
           notFull.signal();
           return x;
         } finally {
           lock.unlock();
         }
       }
     }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37

    三.锁的相关概念介绍

    在前面介绍了Lock的基本使用,这一节来介绍一下与锁相关的几个概念。

    3.1 可重入锁

    如果锁具备可重入性,则称作为可重入锁。像synchronized和ReentrantLock都是可重入锁,可重入性在我看来实际上表明了锁的分配机制:基于线程的分配,而不是基于方法调用的分配。举个简单的例子,当一个线程执行到某个synchronized方法时,比如说method1,而在method1中会调用另外一个synchronized方法method2,此时线程不必重新去申请锁,而是可以直接执行方法method2。
      
    看下面这段代码就明白了:

    class MyClass {
        public synchronized void method1() {
            method2();
        }
         
        public synchronized void method2() {
             
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9

    上述代码中的两个方法method1和method2都用synchronized修饰了,假如某一时刻,线程A执行到了method1,此时线程A获取了这个对象的锁,而由于method2也是synchronized方法,假如synchronized不具备可重入性,此时线程A需要重新申请锁。但是这就会造成一个问题,因为线程A已经持有了该对象的锁,而又在申请获取该对象的锁,这样就会线程A一直等待永远不会获取到的锁。

    而由于synchronized和Lock都具备可重入性,所以不会发生上述现象。

    3.2 可中断锁

    可中断锁:顾名思义,就是可以相应中断的锁。

    在Java中,synchronized就不是可中断锁,而Lock是可中断锁。

    如果某一线程A正在执行锁中的代码,另一线程B正在等待获取该锁,可能由于等待时间过长,线程B不想等待了,想先处理其他事情,我们可以让它中断自己或者在别的线程中中断它,这种就是可中断锁。

    在前面演示lockInterruptibly()的用法时已经体现了Lock的可中断性。

    3.3 公平锁

    公平锁即尽量以请求锁的顺序来获取锁。比如同是有多个线程在等待一个锁,当这个锁被释放时,等待时间最久的线程(最先请求的线程)会获得该所,这种就是公平锁。

    非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁。

    在Java中,synchronized就是非公平锁,它无法保证等待的线程获取锁的顺序。

    而对于ReentrantLock和ReentrantReadWriteLock,它默认情况下是非公平锁,但是可以设置为公平锁。

    看一下这2个类的源代码就清楚了:
      

    在ReentrantLock中定义了2个静态内部类,一个是NotFairSync,一个是FairSync,分别用来实现非公平锁和公平锁。

    我们可以在创建ReentrantLock对象时,通过以下方式来设置锁的公平性:
    ReentrantLock lock = new ReentrantLock(true);

    如果参数为true表示为公平锁,为fasle为非公平锁。默认情况下,如果使用无参构造器,则是非公平锁。

      另外在ReentrantLock类中定义了很多方法,比如:
      isFair()        //判断锁是否是公平锁
      isLocked()    //判断锁是否被任何线程获取了
      isHeldByCurrentThread()   //判断锁是否被当前线程获取了
      hasQueuedThreads()   //判断是否有线程在等待该锁
      在ReentrantReadWriteLock中也有类似的方法,同样也可以设置为公平锁和非公平锁。不过要记住,ReentrantReadWriteLock并未实现Lock接口,它实现的是ReadWriteLock接口。
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    3.4 读写锁

    读写锁将对一个资源(比如文件)的访问分成了2个锁,一个读锁和一个写锁。

    正因为有了读写锁,才使得多个线程之间的读操作不会发生冲突。

    ReadWriteLock就是读写锁,它是一个接口,ReentrantReadWriteLock实现了这个接口。

    可以通过readLock()获取读锁,通过writeLock()获取写锁。

    上面已经演示过了读写锁的使用方法,在此不再赘述。

  • 相关阅读:
    jupyter远程服务器配置以及服务器开机自启
    支持对协议和会话分享动作进行授权,新增API Key白名单功能,JumpServer堡垒机v3.9.0发布
    【LeetCode】136. 只出现一次的数 python
    I/O多路转接
    10. 查询没学过“张三”老师教授的任一门课程的学生姓名
    MySQL 练习<2>
    交叉编译器arm-linux-gcc,aarch64-himix200-linux-gcc命令找不到 not found ,所有原因全方位解析
    java毕业生设计学校食堂订餐管理计算机源码+系统+mysql+调试部署+lw
    R语言使用plot函数可视化数据散点图,使用sub参数为可视化图像添加副标题
    从这两道题重新理解,JS的this、作用域、闭包、对象
  • 原文地址:https://blog.csdn.net/liufang_imei/article/details/132712572