网站 制作 报价,湖南专业建站按效果付贿,南宁企业官网设计,微科技h5制作网站模板第15讲 | synchronized和ReentrantLock有什么区别呢#xff1f; 从今天开始#xff0c;我们将进入 Java 并发学习阶段。软件并发已经成为现代软件开发的基础能力#xff0c;而 Java 精心设计的高效并发机制#xff0c;正是构建大规模应用的基础之一#xff0c;所以考察并发…第15讲 | synchronized和ReentrantLock有什么区别呢 从今天开始我们将进入 Java 并发学习阶段。软件并发已经成为现代软件开发的基础能力而 Java 精心设计的高效并发机制正是构建大规模应用的基础之一所以考察并发基本功也成为各个公司面试 Java 工程师的必选项。
今天我要问你的问题是 synchronized 和 ReentrantLock 有什么区别有人说 synchronized 最慢这话靠谱吗
典型回答
synchronized 是 Java 内建的同步机制所以也有人称其为 Intrinsic Locking它提供了互斥的语义和可见性当一个线程已经获取当前锁时其他试图获取的线程只能等待或者阻塞在那里。
在 Java 5 以前synchronized 是仅有的同步手段在代码中 synchronized 可以用来修饰方法也可以使用在特定的代码块儿上本质上 synchronized 方法等同于把方法全部语句用 synchronized 块包起来。
ReentrantLock通常翻译为再入锁是 Java 5 提供的锁实现它的语义和 synchronized 基本相同。再入锁通过代码直接调用 lock() 方法获取代码书写也更加灵活。与此同时ReentrantLock 提供了很多实用的方法能够实现很多 synchronized 无法做到的细节控制比如可以控制 fairness也就是公平性或者利用定义条件等。但是编码中也需要注意必须要明确调用 unlock() 方法释放不然就会一直持有该锁。
synchronized 和 ReentrantLock 的性能不能一概而论早期版本 synchronized 在很多场景下性能相差较大在后续版本进行了较多改进在低竞争场景中表现可能优于 ReentrantLock。
考点分析
今天的题目是考察并发编程的常见基础题我给出的典型回答算是一个相对全面的总结。
对于并发编程不同公司或者面试官面试风格也不一样有个别大厂喜欢一直追问你相关机制的扩展或者底层有的喜欢从实用角度出发所以你在准备并发编程方面需要一定的耐心。
我认为锁作为并发的基础工具之一你至少需要掌握
理解什么是线程安全。
synchronized、ReentrantLock 等机制的基本使用与案例。
更进一步你还需要
掌握 synchronized、ReentrantLock 底层实现理解锁膨胀、降级理解偏斜锁、自旋锁、轻量级锁、重量级锁等概念。
掌握并发包中 java.util.concurrent.lock 各种不同实现和案例分析。
知识扩展
专栏前面几期穿插了一些并发的概念有同学反馈理解起来有点困难尤其对一些并发相关概念比较陌生所以在这一讲我也对会一些基础的概念进行补充。
首先我们需要理解什么是线程安全。
我建议阅读 Brain Goetz 等专家撰写的《Java 并发编程实战》Java Concurrency in Practice虽然可能稍显学究但不可否认这是一本非常系统和全面的 Java 并发编程书籍。按照其中的定义线程安全是一个多线程环境下正确性的概念也就是保证多线程环境下共享的、可修改的状态的正确性这里的状态反映在程序中其实可以看作是数据。
换个角度来看如果状态不是共享的或者不是可修改的也就不存在线程安全问题进而可以推理出保证线程安全的两个办法
封装通过封装我们可以将对象内部状态隐藏、保护起来。
不可变还记得我们在专栏第 3 讲强调的 final 和 immutable 吗就是这个道理Java 语言目前还没有真正意义上的原生不可变但是未来也许会引入。
线程安全需要保证几个基本特性
原子性简单说就是相关操作不会中途被其他线程干扰一般通过同步机制实现。
可见性是一个线程修改了某个共享变量其状态能够立即被其他线程知晓通常被解释为将线程本地状态反映到主内存上volatile 就是负责保证可见性的。
有序性是保证线程内串行语义避免指令重排等。
可能有点晦涩那么我们看看下面的代码段分析一下原子性需求体现在哪里。这个例子通过取两次数值然后进行对比来模拟两次对共享状态的操作。
你可以编译并执行可以看到仅仅是两个线程的低度并发就非常容易碰到 former 和 latter 不相等的情况。这是因为在两次取值的过程中其他线程可能已经修改了 sharedState。 public class ThreadSafeSample {public int sharedState;public void nonSafeAction() {while (sharedState 100000) {int former sharedState;int latter sharedState;if (former ! latter - 1) {System.out.printf(Observed data race, former is former , latter is latter);}}}public static void main(String[] args) throws InterruptedException {ThreadSafeSample sample new ThreadSafeSample();Thread threadA new Thread(){public void run(){sample.nonSafeAction();}};Thread threadB new Thread(){public void run(){sample.nonSafeAction();}};threadA.start();threadB.start();threadA.join();threadB.join();}
}下面是在我的电脑上的运行结果
C:\c:\jdk-9\bin\java ThreadSafeSample
Observed data race, former is 13097, latter is 13099将两次赋值过程用 synchronized 保护起来使用 this 作为互斥单元就可以避免别的线程并发的去修改 sharedState。 synchronized (this) {int former sharedState ;int latter sharedState;// …
}如果用 javap 反编译可以看到类似片段利用 monitorenter/monitorexit 对实现了同步的语义 11: astore_1
12: monitorenter
13: aload_0
14: dup
15: getfield #2 // Field sharedState:I
18: dup_x1
…
56: monitorexit我会在下一讲对 synchronized 和其他锁实现的更多底层细节进行深入分析。
代码中使用 synchronized 非常便利如果用来修饰静态方法其等同于利用下面代码将方法体囊括进来
synchronized (ClassName.class) {}再来看看 ReentrantLock。你可能好奇什么是再入它是表示当一个线程试图获取一个它已经获取的锁时这个获取动作就自动成功这是对锁获取粒度的一个概念也就是锁的持有是以线程为单位而不是基于调用次数。Java 锁实现强调再入性是为了和 pthread 的行为进行区分。
再入锁可以设置公平性fairness我们可在创建再入锁时选择是否是公平的。
ReentrantLock fairLock new ReentrantLock(true);这里所谓的公平性是指在竞争场景中当公平性为真时会倾向于将锁赋予等待时间最久的线程。公平性是减少线程“饥饿”个别线程长期等待锁但始终无法获取情况发生的一个办法。
如果使用 synchronized我们根本无法进行公平性的选择其永远是不公平的这也是主流操作系统线程调度的选择。通用场景中公平性未必有想象中的那么重要Java 默认的调度策略很少会导致 “饥饿”发生。与此同时若要保证公平性则会引入额外开销自然会导致一定的吞吐量下降。所以我建议只有当你的程序确实有公平性需要的时候才有必要指定它。
我们再从日常编码的角度学习下再入锁。为保证锁释放每一个 lock() 动作我建议都立即对应一个 try-catch-finally典型的代码结构如下这是个良好的习惯。 ReentrantLock fairLock new ReentrantLock(true);// 这里是演示创建公平锁一般情况不需要。
fairLock.lock();
try {// do something
} finally {fairLock.unlock();
}ReentrantLock 相比 synchronized因为可以像普通对象一样使用所以可以利用其提供的各种便利方法进行精细的同步操作甚至是实现 synchronized 难以表达的用例如
带超时的获取锁尝试。
可以判断是否有线程或者某个特定线程在排队等待获取锁。
可以响应中断请求。
这里我特别想强调条件变量java.util.concurrent.Condition如果说 ReentrantLock 是 synchronized 的替代选择Condition 则是将 wait、notify、notifyAll 等操作转化为相应的对象将复杂而晦涩的同步操作转变为直观可控的对象行为。
条件变量最为典型的应用场景就是标准类库中的 ArrayBlockingQueue 等。
我们参考下面的源码首先通过再入锁获取条件变量 /** Condition for waiting takes */
private final Condition notEmpty;/** Condition for waiting puts */
private final Condition notFull;public ArrayBlockingQueue(int capacity, boolean fair) {if (capacity 0)throw new IllegalArgumentException();this.items new Object[capacity];lock new ReentrantLock(fair);notEmpty lock.newCondition();notFull lock.newCondition();
}两个条件变量是从同一再入锁创建出来然后使用在特定操作中如下面的 take 方法判断和等待条件满足 public E take() throws InterruptedException {final ReentrantLock lock this.lock;lock.lockInterruptibly();try {while (count 0)notEmpty.await();return dequeue();} finally {lock.unlock();}
}当队列为空时试图 take 的线程的正确行为应该是等待入队发生而不是直接返回这是 BlockingQueue 的语义使用条件 notEmpty 就可以优雅地实现这一逻辑。
那么怎么保证入队触发后续 take 操作呢请看 enqueue 实现 private void enqueue(E e) {// assert lock.isHeldByCurrentThread();// assert lock.getHoldCount() 1;// assert items[putIndex] null;final Object[] items this.items;items[putIndex] e;if (putIndex items.length) putIndex 0;count;notEmpty.signal(); // 通知等待的线程非空条件已经满足
}通过 signal/await 的组合完成了条件判断和通知等待线程非常顺畅就完成了状态流转。注意signal 和 await 成对调用非常重要不然假设只有 await 动作线程会一直等待直到被打断interrupt。
从性能角度synchronized 早期的实现比较低效对比 ReentrantLock大多数场景性能都相差较大。但是在 Java 6 中对其进行了非常多的改进可以参考性能对比在高竞争情况下ReentrantLock 仍然有一定优势。我在下一讲进行详细分析会更有助于理解性能差异产生的内在原因。在大多数情况下无需纠结于性能还是考虑代码书写结构的便利性、可维护性等。
今天作为专栏进入并发阶段的第一讲我介绍了什么是线程安全对比和分析了 synchronized 和 ReentrantLock并针对条件变量等方面结合案例代码进行了介绍。下一讲我将对锁的进阶内容进行源码和案例分析。
一课一练
关于今天我们讨论的 synchronized 和 ReentrantLock 你做到心中有数了吗思考一下你使用过 ReentrantLock 中的哪些方法呢分别解决什么问题
请你在留言区写写你对这个问题的思考我会选出经过认真思考的留言送给你一份学习鼓励金欢迎你与我一起讨论。
构的便利性、可维护性等。
今天作为专栏进入并发阶段的第一讲我介绍了什么是线程安全对比和分析了 synchronized 和 ReentrantLock并针对条件变量等方面结合案例代码进行了介绍。下一讲我将对锁的进阶内容进行源码和案例分析。
一课一练
关于今天我们讨论的 synchronized 和 ReentrantLock 你做到心中有数了吗思考一下你使用过 ReentrantLock 中的哪些方法呢分别解决什么问题
请你在留言区写写你对这个问题的思考我会选出经过认真思考的留言送给你一份学习鼓励金欢迎你与我一起讨论。
你的朋友是不是也在准备面试呢你可以“请朋友读”把今天的题目分享给好友或许你能帮到他。
