目录
参考了这篇文章,围绕这篇文章扩展和整理:
总结:Java中的锁_小魏的博客的博客-CSDN博客_java中的锁
1、synchronized
底层是通过 Monitor 实现的,Monitor 是在 JVM 底层实现的,底层代码是 C++。
synchronized的锁会经历:无锁、偏向锁、轻量级锁(自旋锁)、重量级锁(悲观锁)。
(锁升级过程不可逆)
锁的信息存于对象头,synchronized是否要升级锁,会根据对象头中的锁信息判断。
偏向锁:当没有其他线程竞争(只有一个线程在竞争同步块时), 那么当前锁就是偏向锁;
轻量级锁(自旋锁):当存在多个线程竞争锁, 锁就会从偏向锁升级为轻量级锁;
重量级锁(互斥锁):在升级到轻量级锁后,未抢到锁的线程会自旋等待锁的释放。会消耗CPU资源, 所以Java设置了轻量级锁自旋次数限制 默认10次(通过-XX:PreBlockSpin 设置),当自旋超过10次就会升级为重量级锁。
自旋锁和互斥锁区别
自旋锁:一直占用着CPU,在未获得锁的情况下,一直运行(自旋),性能高,但是废资源,适合等待时间短,并发量不高的情况;
互斥锁:进入内核态的线程阻塞,唤醒时性能低下,适合在等待时间长的情况下使用。
自旋锁的实现
CAS是自旋锁的一种实现方式(CAS是乐观锁的一种实现方式)
CAS有三个操作值:
内存值V、预期值A与修改值B。
根据CAS自己写一个自旋锁:
CAS与自旋锁_皮卡P的博客-CSDN博客_自旋锁和cas的区别
2、Lock
Lock 是接口,实现类有: ReentrantLock,ReentrantReadWriteLock.ReadLock,ReentrantReadWriteLock.WriteLock
常用的就是ReentrantLock。
ReentrantLock的底层实现是AQS+CAS
ReentrantLock实现是一种自旋锁,通过循环调用CAS操作来实,性能上比较好是因为避免了使线程进入内核态的阻塞状态。
ReentrantLock的实现原理及AQS和CAS - 踏月而来 - 博客园
AQS: 队列同步器
线程通过CAS获取并设置同步器状态,如果获取失败,会被丢进队列,在队列中自旋获取,直到获取到同步器状态后,退出队列。
CAS:Compare-And-Swap比较并交换
CAS并不局限于实现自旋锁或者实现AQS
CAS只是一种在并发环境下,线程对共享变量的操作方式,是一种乐观锁的思想
3、synchronized与Lock区别
synchronized与Lock都是可重入锁,防止在同一线程中多次获取锁而导致死锁发生。
-
来源
lock是一个接口,而synchronized是java的一个关键字,synchronized是内置的语言实现; -
异常是否释放锁
synchronized在发生异常时候会自动释放占有的锁,因此不会出现死锁;而lock发生异常时候,不会主动释放占有的锁,必须手动unlock来释放锁,可能引起死锁的发生。(所以最好将同步代码块用try catch包起来,finally中写入unlock,避免死锁的发生。) -
是否响应中断
lock等待锁过程中可以用interrupt来中断等待,而synchronized只能等待锁的释放,不能响应中断; -
是否知道获取锁
Lock可以通过trylock来知道有没有获取锁,而synchronized不能; -
Lock可以提高多个线程进行读操作的效率。(可以通过readwritelock实现读写分离)
-
性能差异
在性能上来说,如果竞争资源不激烈,两者的性能是差不多的,而当竞争资源非常激烈时(即有大量线程同时竞争),此时Lock的性能要远远优于synchronized。所以说,在具体使用时要根据适当情况选择。 -
线程调度方式
synchronized使用Object对象本身的wait 、notify、notifyAll调度机制,而Lock可以使用Condition进行线程之间的调度。 -
是否公平锁
公平锁是指多个线程等待同一个锁时,必须按照申请锁的时间顺序获得锁。Synchronized锁非公平锁,ReentrantLock默认的构造函数是创建的非公平锁,可以通过参数true设为公平锁,但公平锁表现的性能不是很好。 -
指定唤醒线程
一个ReentrantLock对象可以同时绑定对个对象。ReenTrantLock提供了一个Condition(条件)类,用来实现分组唤醒需要唤醒的线程们,而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程。
4、补充锁的一些概念
偏向锁
偏向锁的字面意思是“偏向于第一个获得它的线程”的锁。执行完同步代码块后,线程并不会主动释放偏向锁。当第二次到达同步代码块时,线程会判断此时持有锁的线程是否就是自己(持有锁的线程ID也在对象头里),如果是则正常往下执行。由于之前没有释放锁,这里也就不需要重新加锁。如果自始至终使用锁的线程只有一个,很明显偏向锁几乎没有额外开销,性能极高。
可重入锁
可重入锁的字面意思是“可以重新进入的锁”,即允许同一个线程多次获取同一把锁。比如一个递归函数里有加锁操作,递归过程中这个锁会阻塞自己吗?如果不会,那么这个锁就是可重入锁(因为这个原因可重入锁也叫做递归锁)。防止在同一线程中多次获取锁而导致死锁发生。
5、线程安全类
通常,能不用锁就不要用锁,再怎么性能高的锁都会有性能损失,一些类如果能用线程安全类解决线程安全就不要用锁。
常见类的线程安全类
ArrayList Vector、CopyOnWriteArrayList
Set CopyOnWriteArraySet
HashMap HashTable、ConcurrentHashMap
StringBuilder StringBuffer
1、所有集合类均可通过Collections.synchronizedXXX获取同步类,同Vector和HashTable一样,并发时直接在整个对象上锁Synchrnoized,效率低
2、CopyOnWriteArrayXXX:实现原理类似读写分离。读的时候允许并发读,写的时候先复制一份,在复制的那份上写,写完合并回去,效率低。
- CopyOnWriteArrayList的“线程安全”机制是通过volatile和监视器锁Synchrnoized来实现的。
- CopyOnWriteArrayList是通过“volatile数组”来保存数据的。一个线程读取volatile数组时,总能看到其它线程对该volatile变量最后的写入,因此通过volatile提供了“读取到的数据总是最新的”这个机制的保证。
- CopyOnWriteArrayList通过监视器锁Synchrnoized来保护数据。在“添加/修改/删除”数据时,会先“获取监视器锁”,再修改完毕之后,先将数据更新到“volatile数组”中,然后再“释放互斥锁”;这样,就达到了保护数据的目的。
3、ConcurrentHashMap
jdk1.8之前Segment+ReentrantLock
jdk1.8之后CAS+Synchronized(插入时,table对应位置为null时,用CAS,不为空时用Synchronized)
jdk1.8之前存取数据时,需要进行两次hash,第一次hash确定Segment,第二次确定Segment中的数组位置,ReentrantLock是加在Segment上的,每个Segment可以认为是一个大Map被分成了多个小Map,相比HashTable直接在整个Map上加锁,ConcurrentHashMap对每个分段加锁,细粒度要细;
jdk1.8之后Synchronized本身已经做了优化,不再是始终是重量级锁,Synchronized是加在table中链表(红黑树)的单个结点上的,细粒度比Segment更细,冲突概率很小,Synchronized相比ReentrantLock,在使用偏向锁时甚至都不需要自旋。因此在锁细粒度很小的情况下,Synchronized不太会升级为重量级锁,此时性能上会比ReentrantLock更加优秀。