Java中的synchronized、ReentrantLock两种锁对比

最新推荐文章于 2024-03-11 16:53:19 发布

Devin__Yang

最新推荐文章于 2024-03-11 16:53:19 发布

阅读量556

点赞数

分类专栏：多线程文章标签： java

本文链接：https://blog.csdn.net/yangding_/article/details/52671236

版权

多线程专栏收录该内容

8 篇文章 0 订阅

订阅专栏

一、结论

1.synchronized或ReentrantLock 分别在什么时候使用呢？

答：在确实需要一些 synchronized 所没有的特性的时候，比如时间锁等候、可中断锁等候、无块结构锁、多个条件变量或者锁投票。 ReentrantLock 还具有可伸缩性的好处，应当在高度争用的情况下使用它，但是，大多数 synchronized 块几乎从来没有出现过争用，所以可以把高度争用放在一边。我建议用 synchronized 开发，直到确实证明 synchronized 不合适，而不要仅仅是假设如果使用 ReentrantLock “性能会更好”。首先要把事情做好，然后再考虑是不是有必要做得更快。

2.synchronized和ReentrantLock使用区别

1.synchronized

synchronized (lockObject) {   
  // update object state  
}

2.ReentrantLock

Lock lock = new ReentrantLock();  
lock.lock();  
try {   
  // update object state  
}  
finally {  
  lock.unlock();   
}

3.ReentrantLock注意事项

一定要记得释放锁，即lock.unlock()操作

二、详细介绍

2.1ReentrantLock的使用场景

场景1：如果发现该操作已经在执行中则不再执行（有状态执行）

a、用在定时任务时，如果任务执行时间可能超过下次计划执行的间隔时间，确保该有状态任务只有一个正在执行，忽略重复触发。
b、用在界面交互时点击执行较长时间请求操作时，防止多次点击导致后台重复执行（忽略重复触发）。

以上两种情况多用于进行非重要任务防止重复执行，（如：清除无用临时文件，检查某些资源的可用性，数据备份操作等）

private ReentrantLock lock = new ReentrantLock();
    if (lock.tryLock()) {   
    /**如果已经被lock，则立即返回false不会等待，
    *达到忽略操作的效果
    */
        try {
            //操作
            } finally {
                lock.unlock();
            }
    }

场景2：如果发现该操作已经在执行，等待一个一个执行（同步执行，类似synchronized）

这种主要是防止资源使用冲突，保证同一时间内只有一个操作可以使用该资源。
但与synchronized的明显区别是性能优势（伴随jvm的优化这个差距在减小）。同时Lock有更灵活的锁定方式，公平锁与不公平锁，而synchronized永远是公平的。

这种情况主要用于对资源的争抢（如：文件操作，同步消息发送，有状态的操作等）

ReentrantLock默认情况下为不公平锁

private ReentrantLock lock = new ReentrantLock(); 
//参数默认false，不公平锁
private ReentrantLock lock = new ReentrantLock(true); //公平锁
try {
    /**
    *如果被其它资源锁定，
    *会在此等待锁释放，
    *达到暂停的效果
    */
    lock.lock(); 

    //操作

    } finally {
        lock.unlock();
    }

不公平锁与公平锁的区别：

公平情况下，操作会排一个队按顺序执行，来保证执行顺序。（会消耗更多的时间来排队）
不公平情况下，是无序状态允许插队，jvm会自动计算如何处理更快速来调度插队。（如果不关心顺序，这个速度会更快）

场景3：如果发现该操作已经在执行，则尝试等待一段时间，等待超时则不执行（尝试等待执行）

这种其实属于场景2的改进，等待获得锁的操作有一个时间的限制，如果超时则放弃执行。
用来防止由于资源处理不当长时间占用导致死锁情况（大家都在等待资源，导致线程队列溢出）。

try {
    /**
    *如果已经被lock，尝试等待5s，
    *看是否可以获得锁
    *如果5s后仍然无法获得锁则返回f*alse继续执行
    */
    if (lock.tryLock(5, TimeUnit.SECONDS)) {  //
        try {
           //操作
            } finally{
                       lock.unlock();
                    }
        }
    } catch (InterruptedException e) {
        e.printStackTrace(); //当前线程被中断时(interrupt)，会抛InterruptedException                 
    }

场景4：如果发现该操作已经在执行，这时可中断正在进行的操作立刻释放锁继续下一操作。

synchronized与Lock在默认情况下是不会响应中断(interrupt)操作，会继续执行完。lockInterruptibly()提供了可中断锁来解决此问题。（场景2的另一种改进，没有超时，只能等待中断或执行完毕）

这种情况主要用于取消某些操作对资源的占用。如：（取消正在同步运行的操作，来防止不正常操作长时间占用造成的阻塞）

try {
        lock.lockInterruptibly();
        //操作
    } catch (InterruptedException e) {
        e.printStackTrace();
    } finally {
        lock.unlock();
    }