Java并发编程-各类锁

时间  2019-11-16
标签 java 并发 编程 各类 栏目 Java 繁體版
原文   原文链接

安全性和活跃度一般相互牵制。咱们使用锁来保证线程安全，可是滥用锁可能引发锁顺序死锁。相似地，咱们使用线程池和信号量来约束资源的使用，redis

可是缺不能知晓哪些管辖范围内的活动可能造成的资源死锁。Java应用程序不能从死锁中恢复，因此确保你的设计可以避免死锁出现的先决条件是很是有价值。算法

一.死锁sql

经典的“哲学家进餐”问题很好的阐释了死锁。5个哲学家一块儿出门去吃中餐，他们围坐在一个圆桌边。他们只有五只筷子(不是5双)，每两我的中间放有一只。数据库

哲学家边吃边思考，交替进行。每一个人都须要得到两只筷子才能吃东西，可是吃后要把筷子放回原处继续思考。有一些管理筷子的算法，使每个人都可以或多或少，及时安全

吃到东西(一个饥饿的哲学家试图得到两只临近的筷子，可是若是其中的一只正在被别人占用，那么他英爱放弃其中一只可用的筷子，等待几分钟再尝试)。可是这样作可能致使数据结构

一些哲学家或者全部哲学家都饿死 (每一个人都迅速捉住本身左边的筷子，而后等待本身右边的筷子变成可用，同时并不放下左边的筷子)。这最后一种状况，当每一个人都拥有他人须要的多线程

资源，而且等待其余人正在占有的资源，若是你们一致占有资源，直到得到本身须要却没占有的其余资源，若是你们一致占有资源，直到得到本身须要却没被占有的其余资源，那么就会产生死锁。并发

　　当一个线程永远占有一个锁，而其余线程尝试去得到这个锁，那么他们将永远被阻塞。当线程Thread1占有锁A时，想要得到锁B，可是同时线程Thread2持有B锁，并尝试得到A锁，两个线程将永远等待下去。分布式

这种状况是死锁最简单的形式.ide

例子以下代码：

public class DeadLock {

    private static Object lockA = new Object();

    private static Object lockB = new Object();

    public static void main(String[] args) {
        new DeadLock().deadLock();
    }

    private void deadLock() {

        Thread thread1 = new Thread(new Runnable() {
            public void run() {
                synchronized (lockA){
                    try {
                        System.out.println(Thread.currentThread().getName() + "获取A锁 ing！");
                        Thread.sleep(500);
                        System.out.println(Thread.currentThread().getName() + "睡眠500ms");
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "须要B锁！！！");
                    synchronized (lockB){
                        System.out.println(Thread.currentThread().getName() + "B锁获取成功");
                    }
                }
            }
        },"Thread1");

        Thread thread2 = new Thread(new Runnable() {
            public void run() {
                synchronized (lockB){
                    try {
                        System.out.println(Thread.currentThread().getName() + "获取B锁 ing！");
                        Thread.sleep(500);
                        System.out.println(Thread.currentThread().getName() + "睡眠500ms");
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "须要A锁！！！");
                    synchronized (lockA){
                        System.out.println(Thread.currentThread().getName() + "A锁获取成功");
                    }
                }
            }
        },"Thread2");

        thread1.start();
        thread2.start();

    }

}

运行结果以下图：

结果很明显了，这两个线程陷入了死锁状态了，发生死锁的缘由是，两个线程试图经过不一样的顺序得到多个相同的锁。若是请求锁的顺序相同，

就不会出现循环的锁依赖现象(你等我放锁，我等你放锁)，也就不会产生死锁了。若是你可以保证同时请求锁A和锁B的每个线程，都是按照从锁A到锁B的顺序，那么就不会发生死锁了。

若是全部线程以通用的固定秩序获取锁，程序就不会出现锁顺序死锁问题了。

 

什么状况下会发生死锁呢？

　　1.锁的嵌套容易发生死锁。解决办法：获取锁时，查看是否有嵌套。尽可能不要用锁的嵌套，若是必需要用到锁的嵌套，就要指定锁的顺序，由于参数的顺序是超乎咱们控制的，为了解决这个问题，咱们必须指定锁的顺序，而且在整个应用程序中，

得到锁都必须始终遵照这个既定的顺序。

 

上面的例子出现死锁的根本缘由就是获取所的顺序是乱序的，超乎咱们控制的。上面例子最理想的状况就是把业务逻辑抽离出来，把获取锁的代码放在一个公共的方法里面，让这两个线程获取锁

都是从个人公共的方法里面获取，当Thread1线程进入公共方法时，获取了A锁，另外Thread2又进来了，可是A锁已经被Thread1线程获取了，Thread1接着又获取锁B，Thread2线程就不能再获取不到了锁A，更别说再去获取锁B了，这样就有必定的顺序了。

上面例子的改造以下：

public class DeadLock {

    private static Object lockA = new Object();

    private static Object lockB = new Object();

    public static void main(String[] args) {
        new DeadLock().deadLock();
    }

    private void deadLock() {

        Thread thread1 = new Thread(new Runnable() {
            public void run() {
                getLock();
            }
        },"Thread1");

        Thread thread2 = new Thread(new Runnable() {
            public void run() {
                getLock();
            }
        },"Thread2");

        thread1.start();
        thread2.start();

    }

    public void getLock() {
        synchronized (lockA){
            try {
                System.out.println(Thread.currentThread().getName() + "获取A锁 ing！");
                Thread.sleep(500);
                System.out.println(Thread.currentThread().getName() + "睡眠500ms");
            } catch (Exception e) {
                e.printStackTrace();
            }
            System.out.println(Thread.currentThread().getName() + "须要B锁！！！");
            synchronized (lockB){
                System.out.println(Thread.currentThread().getName() + "B锁获取成功");
            }
        }
    }

}

运行结果以下：

能够看到把业务逻辑抽离出来，把获取锁的代码放在一个公共的方法里面，得到锁都必须始终遵照这个既定的顺序。

 

2.引入显式锁的超时机制特性来避免死锁

超时机制是监控死锁和从死锁中恢复的技术，是使用每一个显式所Lock类中定时tryLock特性，来替代使用颞部所机制。在内部锁的机制中，只要没有得到锁，就永远保持等待，而

显示的锁使你能狗定义超时的时间，在规定时间以后tryLock尚未得到锁就会返回失败。经过使用超时，尽管这段时间比你预期可以得到所的时间长不少，你仍然能够在乎外发生后从新

得到控制权。当尝试得到定时锁失败时，你并不须要知道缘由。也许是由于有死锁发生，也许是线程在持有锁的时候错误地进入无限循环；也有多是执行一些活动所花费的时间比你

预期慢了许多。不过至少你有机会了解到你的尝试已经失败，记录下此次尝试中有用的信息，并从新开始计算，这远比关闭整个线程要优雅得多。

　　即便定时锁并无应用于整个系统，使用它来得到多重锁仍是可以有效应对死锁。若是获取锁的请求超时，你能够释放这个锁，并后退，等待一会后再尝试，这极可能消除了死锁发生的条件，

而且循序程序恢复。(这项技术只有在同时得到两个锁的时候才有效；若是多个锁是在嵌套的方法中被请求的，你没法仅仅释放外层的锁，尽管你知道本身已经持有该锁)

 

显式锁Lock，Lock是一个接口，定义了一些抽象的所操做。与内部锁机制不一样，Lock提供了无条件，可轮询，定时的，可中断的锁获取操做，全部加锁和解锁的方法都是显式的。

Lock的实现必须提供举报与内部锁相同的内存可见性的语义。可是加锁的语义，调度算法，顺序保证，性能特性这些能够不一样。

Lock接口源码以下：

public interface Lock {
    //加锁
    void lock();

    //可中断的锁，打算线程的等待状态，即A线程已经获取该锁，B线程又来获    
    //取，可是A线程会通知B，来打算B线程的等待。
     void lockInterruptibly() throws InterruptedException;   
     //尝试去获取锁，失败返回False
     boolean tryLock(); 


    //超时机制获取锁
     boolean tryLock(long time, TimeUnit unit) throws 
     InterruptedException;

    //释放锁
     void unlock();

     Condition newCondition();

}

 

ReentranLock实现了Lock接口，提供了与synchronized相同的互斥和内存可见性的保证。得到ReentrantLock的锁与进入synchronized块有着相同内存含义，释放ReentrantLock锁与退出synchronized块有着相同内存含义。

ReentrantLock提供了与synchronized同样可重入加锁的语义。ReentrantLock支持Lock接口定义的全部获取锁的方式。与synchronized相比，ReentranLock为处理不可用的锁提供了更多灵活性。

可是对于如今的JDK的更新，synchronized的性能被优化的愈来愈好，内部锁(synchronized)已经得到至关可观的性能，性能不只仅是个不断变化的目标，并且变化的很是快。

以下图：

看到图，随着JDK的更新迭代，内部锁的性能愈来愈快，这不是ReentrantLock的衰退，而是内部锁(synchronized)愈来愈快，特别在JDK目前跟新到如今1.9.

 

下面用显式锁Lock再来改造上面的例子

public class DeadLock {

    Lock lock = new ReentrantLock();

    private static Object lockA = new Object();

    private static Object lockB = new Object();

    public static void main(String[] args) {
        new DeadLock().deadLock();
    }

    private void deadLock() {

        Thread thread1 = new Thread(new Runnable() {
            public void run() {
                try {
                    lock.lock();
                    System.out.println(Thread.currentThread().getName() + "获取A锁 ing！");
                    Thread.sleep(500);
                    System.out.println(Thread.currentThread().getName() + "睡眠500ms");
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    lock.unlock();
                }
                System.out.println(Thread.currentThread().getName() + "须要B锁！！！");
                try {
                    lock.lock();
                    System.out.println(Thread.currentThread().getName() + "B锁获取成功");
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    lock.unlock();
                }
            }
        }, "Thread1");

        Thread thread2 = new Thread(new Runnable() {
            public void run() {
                try {
                    lock.lock();
                    System.out.println(Thread.currentThread().getName() + "获取B锁 ing！");
                    Thread.sleep(500);
                    System.out.println(Thread.currentThread().getName() + "睡眠500ms");
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    lock.unlock();
                }
                System.out.println(Thread.currentThread().getName() + "须要A锁！！！");
                try {
                    lock.lock();
                    System.out.println(Thread.currentThread().getName() + "A锁获取成功");
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    lock.unlock();
                }
            }
        }, "Thread1");

        thread1.start();
        thread2.start();
    }

}

运行结果以下：

 

能够看到显示锁Lock是能够避免死锁的。

 

注意：Lock接口规范形式。这种模式在某种程度上比使用内部锁更加复杂：锁必须在finally块中释放。另外一方面，若是锁守护的代码在try块以外抛出了异常，它将永远都不会被释放了；若是对象

可以被置于不一致状态，可能须要额外的try-catch，或try-finally块。(当你在使用任何形式的锁时，你老是应该关注异常带来的影响，包括内部锁)。

忘记时候finally释放Lock是一个定时炸弹。当不幸发生的时候，你将很难追踪到错误的发生点，由于根本没有记录锁本应该被释放的位置和时间。这就是ReentrantLock不能彻底替代synchronized的缘由：它更加危险，

由于当程序的控制权离开守护的块，不会自动清除锁。尽管记得在finally块中释放锁并不苦难，但忘记的可能仍然存在。

sy

 

可轮询的和可定时的锁请求

　　可定时的与可轮询的锁获取模式，是由tryLock方法实现，与物体爱建的锁获取相比，它具备更完善的错误恢复机制。在内部锁中，死锁是致命的，惟一的恢复方法是从新启动程序，惟一的预防方法是在构建程序时不要出错，

因此不可能循序不一致的锁顺序。可定时的与可轮询的锁提供了另一个选择：能够规避死锁的放生。

　　若是你不能得到全部须要的锁，那么使用可定时的与可轮询的获取方式(tryLock)使你可以从新拿到控制权，它会释放你已经得到的这些锁，而后再从新尝试(或者至少会记录这个失败，抑或者采起其余措施)。使用tryLock试图得到两个锁，

若是不能同时得到两个，就回退，并从新尝试。休眠时间由一个特定的组件管理，并由一个随机组件减小活锁发生的可能性。若是必定时间内，没有得到全部须要的锁，就会返回一个失败状态，这样操做就能优雅的失败了。

tryLock（）常常与if esle一块儿使用。

 

读-写锁

 

　　ReentrantLock实现了标准的互斥锁：一次最多只有一个线程可以持有相同ReentrantLock。可是互斥一般作为保护数据一致性的很强的加锁约束，所以，过度的限制了并发性。互斥是保守的加锁策略，避免了

“写/写”和“写/读"的重读，可是一样避开了"读/读"的重叠。在不少状况下，数据结构是”频繁被读取“的——它们是可变的，有时候会被改变，但多数访问只进行读操做。此时，若是可以放宽，容许多个读者同时访问数据结构就

很是好了。只要每一个线程保证可以读到最新的数据(线程的可见性)，而且在读者读取数据的时候没有其余线程修改数据，就不会发生问题。这就是读-写锁容许的状况：一个资源可以被多个读者访问，或者被一个写者访问，二者不能同时进行。

ReadWriteLock，暴露了2个Lock对象，一个用来读，另外一个用来写。读取ReadWriteLock锁守护的数据，你必须首先得到读取的锁，当须要修改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();
}

读写锁实现的加锁策略容许多个同时存在的读者，可是只容许一个写者。与Lock同样，ReadWriteLock容许多种实现，形成性能，调度保证，获取优先，公平性，以及加锁语义等方面的不尽相同。

读写锁的设计是用来进行性能改进的，使得特定状况下可以有更好的并发性。时间实践中，当多处理器系统中，频繁的访问主要为读取数据结构的时候哦，读写锁可以改进性能；在其余状况下运行的状况比独占

的锁要稍微差一些，这归因于它更大的复杂性。使用它可否带来改进，最好经过对系统进行剖析来判断：好在ReadWriteLock使用Lock做为读写部分的锁，因此若是剖析得的结果发现读写锁没有能提升性能，把读写锁置换为独占锁是比较容易。

 

下面咱们用synchonized来进行读操做，对于读操做性能如何呢？

例子以下：

public class ReadWriteLockTest {
    private ReentrantReadWriteLock rw1 = new ReentrantReadWriteLock();

    public static void main(String[] args) {
        final ReadWriteLockTest test = new ReadWriteLockTest();

        new Thread(){
            @Override
            public void run() {
                test.get(Thread.currentThread());
            }
        }.start();

        new Thread(){
            @Override
            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() + "读操做完成");

    }

}

运行结果以下：

能够看到要线程Thread0读操做完了，Thread1才能进行读操做。明显这样性能很慢。

 

如今咱们用ReadWriteLock来进行读操做，看一下性能如何

例子以下：

public class ReadWriteLockTest {
    private ReentrantReadWriteLock rw1 = new ReentrantReadWriteLock();

    public static void main(String[] args) {
        final ReadWriteLockTest test = new ReadWriteLockTest();

        new Thread(){
            @Override
            public void run() {
                test.get(Thread.currentThread());
            }
        }.start();

        new Thread(){
            @Override
            public void run() {
                test.get(Thread.currentThread());
            }
        }.start();

    }

    public  void get(Thread thread) {
        try {
            rw1.readLock().lock();
            long start = System.currentTimeMillis();
            while (System.currentTimeMillis() - start <= 1){
                System.out.println(thread.getName() + "正在读操做");
            }
            System.out.println(thread.getName() + "读操做完成");
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            rw1.readLock().unlock();
        }

    }

}

运行结果以下：

能够看到线程间是不用排队来读操做的。这样效率明显很高。

 

咱们再看一下写操做，以下：

public class ReadWriteLockTest {
    private ReentrantReadWriteLock rw1 = new ReentrantReadWriteLock();

    public static void main(String[] args) {
        final ReadWriteLockTest test = new ReadWriteLockTest();

        new Thread(){
            @Override
            public void run() {
                test.get(Thread.currentThread());
            }
        }.start();

        new Thread(){
            @Override
            public void run() {
                test.get(Thread.currentThread());
            }
        }.start();

    }

    public  void get(Thread thread) {
        try {
            rw1.writeLock().lock();
            long start = System.currentTimeMillis();
            while (System.currentTimeMillis() - start <= 1){
                System.out.println(thread.getName() + "正在写操做");
            }
            System.out.println(thread.getName() + "写操做完成");
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            rw1.writeLock().unlock();
        }

    }

}

运行结果以下：

能够看到ReadWriteLock只容许一个写者。

 

公平锁

ReentrantReadWriteLock为两个锁提供了可重入的加锁语义，它是继承了ReadWriteLock，扩展了ReadWriteLock。它与ReadWriteLock相同，ReentrantReadWriteLock可以被构造

为非公平锁(构造方法不设置参数，默认是非公平)，或者公平。在公平锁中，选择权交给等待时间最长的线程；若是锁由读者得到，而一个线程请求写入锁，那么再也不容许读者得到读取锁，直到写者被受理，平且已经释放了写锁。

在非公平的锁中，线程容许访问的顺序是不定的。由写者降级为读者是容许的；从读者升级为写者是不容许的(尝试这样的行为会致使死锁)

　　当锁被持有的时间相对较长，而且大部分操做都不会改变锁守护的资源，那么读写锁可以改进并发性。ReadWriteMap使用了ReentrantReadWriteLock来包装Map,使得它可以在多线程间

被安全的共享，并仍然可以避免 "读-写" 或者 ”写-写“冲突。显示中ConcurrentHashMap并发容器的性能已经足够好了，因此你能够是使用他，而没必要使用这个新的解决方案，若是你须要并发的部分

只有哈希Map，可是若是你须要为LinkedHashMap这种可替换元素Map提供更好的并发访问，那么这项技术是很是有用的。

用读写锁包装的Map以下图：

读写锁的性能以下图：

 

总结：

　　显式的Lock与内部锁相比提供了一些扩展的特性，包括处理不可用的锁时更好的灵活性，以及对队列行为更好的控制。可是ReentrantLock不能彻底替代synchronized;只有当你须要

synchronized没能提供的特性时才应该使用。

　　读-写锁容许多个读者并发访问被守护的对象，当访问多为读取数据结构的时候，它具备改进可伸缩性的潜力。

 

数据库层面上的锁——悲观锁和乐观锁

乐观锁：他对世界比较乐观，认为别人访问正在改变的数据的几率是很低的，因此直到修改完成准备提交所作的的修改到数据库的时候才会将数据锁住。完成更改后释放。

我想一下一个这样的业务场景：咱们从数据库中获取了一条数据，咱们正要修改他的数据时，恰好另一个用户此时已经修改过了这条数据，这是咱们是不知作别人修改过这条数据的。

　　解决办法，咱们能够在表中增长一个version字段，让这个version自增或者自减，或者用一个时间戳字段，这个时间搓字段是惟一的。咱们写数据的时候带上version，也就是每一个人更新的时候都会判断当前的版本号是否跟我查询出来获得的版本号是否一致，不一致就更新失败，一致就更新这条记录并更改版本号。

例子以下：

1.查询出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

用户体验表现层面一般表现为系统繁忙之类的。

在这里还要注意乐观锁的一个细节：就是version字段要自增或者自减，否者会出现ABA问题。

ABA问题：线程Thread1拿到了version字段为A，因为CAS操做(即先进行比较而后设值)，线程Thread2先拿到的version,将version改为B，线程Thread3来拿到version，将version值又改回了A。此时Thread1的CAS(先比较后set值)操做结束了，继续执行，它发现version的值仍是A，觉得没有发生变化，因此就继续执行了。这个过程当中，version从A变为B，再由B变为A就被形象地称为ABA问题了。

 

悲观锁：也称排它锁，当事务在操做数据时把这部分数据进行锁定，直到操做完毕后再解锁，其余事务操做才可操做该部分数据。这将防止其余进程读取或修改表中的数据。

通常使用 select ...for update 对所选择的数据进行加锁处理，例如

select * from account where name=”JAVA” for update，

 

 

 这条sql 语句锁定了account 表中全部符合检索条件（name=”JAVA”）的记录。本次事务提交以前（事务提交时会释放事务过程当中的锁），外界没法修改这些记录。

用户界面常表现为转圈圈等待。

 

若是数据库分库分表了，再也不是单个数据库了，那么咱们能够用分布式锁，好比redis的setnx特性，zookeeper的节点惟一性和顺序性特性来作分布式锁。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程