zoukankan      html  css  js  c++  java
  • Java中的Lock与synchronized

    并发编程学习笔记之Lock与synchronized

    一、什么是可重入锁

    Lcok在Java中是一个接口,一般在面试问题中问到的可能是ReentrantLock与synchronized的区别。ReentrantLock是Lock的一个实现类,字面意思的话就是可重入锁,那么什么是可重入锁呢。

    可重入锁是锁的一个相关概念,并不是特指我们的ReentrantLock,而是如果一个锁具备可重入性,那我们就说这是一个可重入锁。ReentrantLock和synchronized都是可重入锁。至于什么是可重入性,这里举个简单的例子,现在在一个类里我们有两个方法(代码如下),一个叫做去北京,一个叫做买票,那我们在去北京的方法里可以直接调用买票方法,假如两个方法全都用synchronized修饰的话,在执行去北京的方法,线程获取了对象的锁,接着执行买票方法,如果synchronized不具备可重入性,那么线程已经有这个对象的锁了,现在又来申请,就会导致线程永远等待无法获取到锁。而synchronized和ReentrantLock都是可重入锁,就不会出现上述的问题。

    class Trip {
    public synchronized void goToBeiJing() {
      // 去北京
      buyATicket();
    }
    public synchronized void buyATicket() {
      // 买票
    }
    }

    二、Lock与synchronized的不同

    二者都是可重入锁,那么为什么要有两个呢?既然存在,那么就一定是有意义的。synchronized是Java中的一个关键字,而Lock是Java1.5后在java.util.concurrent.locks包下提供的一种实现同步的方法,那么显然的,synchronized一定是有什么做不到的或者缺陷,才导致了Lock的诞生。

    1.synchronized的缺点

    1)当一个代码块被synchronized修饰的时候,一个线程获取到了锁,并且执行代码块,那么其他的线程需要等待正在使用的线程释放掉这个锁,那么释放锁的方法只有两种,一种是代码执行完毕自动释放,一种是发生异常以后jvm会让线程去释放锁。那么如果这个正在执行的线程遇到什么问题,比如等待IO或者调用sleep方法等等被阻塞了,无法释放锁,而这时候其他线程只能一直等待,将会特别影响效率。那么有没有一种办法让其他线程不必一直傻乎乎的等在这里吗?

    2)当一个文件,同时被多个线程操作时,读操作和写操作会发生冲突,写操作和写操作会发生冲突,而读操作和读操作并不会冲突,但是如果我们用synchronized的话,会导致一个线程在读的时候,其他线程想要读的话只能等待,那么有什么办法能不锁读操作吗?

    3)在使用synchronized时,我们无法得知线程是否成功获取到锁,那么有什么办法能知道是否获取到锁吗?

    2.java.util.concurrent.locks包

    1)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();
    }

    ReentrantLock是Lock的一个实现类(另外两个实现类是ReentrantReadWriteLock类下的两个静态内部类:WriteLock和ReadLock),它的意思是可重入锁,可重入锁前面已经讲过了。ReentrantLock中提供了更多的一些方法。不过常用的就是Lock中的这些。

    来看一下Lock接口这些方法的使用,lock()、tryLock()、tryLock(long time, TimeUnit unit)和lockInterruptibly()是用来获取锁的。unLock()方法是用来释放锁的。

    这里有四个方法来获取锁,那么区别在哪里呢?

    lock()使我们平时用的最多的,最用是用来获取锁,如果锁已经被其他线程获取,那么就等待。但是采用Lock必须要主动释放锁,所以我们一般在try{}catch{}块中处理然后在finally中释放锁,举个例子:

    lock.lock();
    try{
      // 处理
     }catch(Exception ex){
      // 捕获异常
     }finally{
      // 释放锁
      lock.unlock();
    }

    tryLock()是一个boolean类型的方法,当调用这个方法的时候,线程会去尝试获取锁,如果获取到的话会返回true,如果获取不到返回false,也就是说这个方法会立马返回一个结果,线程不会等待。

    tryLock(long time, TimeUnit unit)是上面tryLock()方法的一个重载方法,加了两个参数,给定了等待的时间,如果在规定时间拿到锁返回true,如果拿不到返回false。这两个方法的一般用法和Lock类似。

    ReentrantLock是Lock的常用实现类,lock.lock()是以lock对象为锁,代码中使用的同一个lock对象,所以使用的是同一把锁,一个线程通过lock()方法拿到了锁,执行了System.out.println("执行了方法");打印出结果,之后没有调用lock.unlock()方法,所以没有释放锁,第二个线程在调用lock.lock()控制台就一直阻塞在那,说明lock.lock()是一个阻塞方法,而lock.tryLock()是不同,他是一个有返回值的方法,在没有设置longTime和TimeUnit时,即试图获取锁,没有获取到就返回false,获取到就返回true,这个方法是立即返回的,当你调用lock.lock(long time,TimeUnit unit),意思就是 在指定时间范围内阻塞,规定时间范围内获取到锁就返回true,否则就返回false,注意:如果在当前线程中以将中断表示位设为true,例如Thread.currentThread().interrupt();执行lock.lock(long time,TimeUnit unit)就会报java.lang.InterruptedException异常

    if (lock.tryLock()) {
    try{
      // 处理
    }catch(Exception ex){
      // 捕获异常
    }finally{
      // 释放锁
      lock.unlock();
    }
    }

    2)ReadWriteLock

    ReadWriteLock也是一个接口,这个接口中只有两个方法,如果一个线程获取了读锁,那么另外的线程想要获取写锁则需要等待释放;而如果一个线程已经获取了写锁,则另外的线程想获取读锁或写锁都需要等待写锁被释放。

    三、总结

    总结一下二者:

    1.synchronized是Java的关键字,是内置特性,而Lock是一个接口,可以用它来实现同步。

    2.synchronized同步的时候,其中一条线程用完会自动释放锁,而Lock需要手动释放,如果不手动释放,可能会造成死锁。

    3.使用synchronized如果其中一个线程不释放锁,那么其他需要获取锁的线程会一直等待下去,知道使用完释放或者出现异常,而Lock可以使用可以响应中断的锁或者使用规定等待时间的锁

    4.synchronized无法得知是否获取到锁,而Lcok可以做到。

    5.用ReadWriteLock可以提高多个线程进行读操作的效率。

    所以综上所述,在两种锁的选择上,当线程对于资源的竞争不激烈的时候,效率差不太多,但是当大量线程同时竞争的时候,Lock的性能会远高于synchronized。

  • 相关阅读:
    SQL Server 2008 R2的发布订阅配置实践
    【SQL Server高可用性】数据库复制:SQL Server 2008R2中数据库复制
    sql server几种读写分离方案的比较
    SQL Server 数据库文件管理
    SQL Server 表和索引存储结构
    SQL Server 查询优化 索引的结构与分类
    C#延迟初始化Lazy<T>
    【转】编写高质量代码改善C#程序的157个建议——建议157:从写第一个界面开始,就进行自动化测试
    【转】编写高质量代码改善C#程序的157个建议——建议156:利用特性为应用程序提供多个版本
    【转】编写高质量代码改善C#程序的157个建议——建议155:随生产代码一起提交单元测试代码
  • 原文地址:https://www.cnblogs.com/alex-xyl/p/11190152.html
Copyright © 2011-2022 走看看