Java多线程:synchronized关键字和Lock
本文来源:https://www.cnblogs.com/ITtangtang/p/7583917.html
一、synchronized
synchronized关键字可以用于声明方法,也可以用来声明代码块,下面分别看一下具体的场景(摘抄自《大型网站系统与Java中间件实践》)
案例一:其中foo1和foo2是SynchronizedDemo1类的两个静态方法。在不同的线程中,这两个方法的调用是互斥的,不仅是它们之间,任何两个不同线程的调用也互斥。
1public class SynchronizedDemo1 {
2 public synchronized static void foo1(){}
3
4 public synchronized static void foo2(){}
5}
案例二:foo3和foo4是SynchronizedDemo2的两个成员方法,在多线程环境中,调用同一个对象的foo3或者foo4是互斥的,与案例一的差别在于,这是针对于同一个对象的多线程方法调用互斥。
1public class SynchronizedDemo2 {
2 public synchronized void foo3(){}
3
4 public synchronized void foo4(){}
5}
案例三:synchronized后面会有一个参数,该参数就是用于同步的锁所属的对象。
1public class SynchronizedDemo3 {
2 public void foo5(){
3 synchronized (this){}
4 }
5
6 public void foo6(){
7 synchronized (SynchronizedDemo3.class){}
8 }
9}
在该案例中,synchronized (this)与SynchronizedDemo3中加 synchronized的成员方法是互斥的,而synchronized (SynchronizedDemo3.class)与SynchronizedDemo3中加synchronized 的静态方法是互斥的
代码块synchronized,当一个线程获取了对应的锁,并执行该代码块时,其他线程便只能一直等待,等待获取锁的线程释放锁,而这里释放锁只会有两种情况:
1)获取锁的线程执行完了该代码块,然后线程释放对锁的占有;
2)线程执行发生异常,此时JVM会让线程自动释放锁。
那么如果这个获取锁的线程由于要等待IO或者其他原因(比如调用sleep方法)被阻塞了,但是又没有释放锁,其他线程便只能干巴巴地等待,影响程序执行效率。
因此就需要有一种机制可以不让等待的线程一直无期限地等待下去(比如只等待一定的时间或者能够响应中断),通过Lock就可以办到。
再举个例子:
当有多个线程读写文件时,读操作和写操作会发生冲突现象,写操作和写操作会发生冲突现象,但是读操作和读操作不会发生冲突现象。但是采用synchronized关键字来实现同步的话,就会导致一个问题:
如果多个线程都只是进行读操作,所以当一个线程在进行读操作时,其他线程只能等待无法进行读操作。
因此就需要一种机制来使得多个线程都只是进行读操作时,线程之间不会发生冲突,通过Lock就可以办到。
另外,通过Lock可以知道线程有没有成功获取到锁。这个是synchronized无法办到的。
二、Lock
参考http://www.cnblogs.com/dolphin0520/p/3923167.html
三、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。所以说,在具体使用时要根据适当情况选择。
● JVM:基础
● 打开黑盒:从 MySQL 架构设计出发,看它是如何执行一条 SQL 语句的?
● 记一次神奇的 sql 查询经历,group by 慢查询优化!
● 花了一个月时间梳理了一下公司的微服务核心架构,原来也不是太难.
● 一次900万+数据量的 SQL 查询优化分析【上百倍性能优化】
● 花了一个月时间梳理了一下公司的微服务核心架构,原来也不是太难.
● API规范约定