今天运维岗位刚入职,但是目前还没有办理入职手续,但是领导发了一堆资料!看了一下,非常多的新东西,只能说努力一把!!!
Java中提供的synchronized,ReentrantLock,ReentrantReadWriteLock都是可重入锁。
重入:当前线程获取到A锁,在获取之后尝试再次获取A锁是可以直接拿到的。
不可重入:当前线程获取到A锁,在获取之后尝试再次获取A锁,无法获取到的,因为A锁被当前线程占用着,需要等待自己释放锁再获取锁。
Java中提供的synchronized,ReentrantLock,ReentrantReadWriteLock都是悲观锁。
Java中提供的CAS操作,就是乐观锁的一种实现。
悲观锁:获取不到锁资源时,会将当前线程挂起(进入BLOCKED、WAITING),线程挂起会涉及到用户态和内核的太的切换,而这种切换是比较消耗资源的。
用户态:JVM可以自行执行的指令,不需要借助操作系统执行。
内核态:JVM不可以自行执行,需要操作系统才可以执行。
乐观锁:获取不到锁资源,可以再次让CPU调度,重新尝试获取锁资源。
Atomic原子性类中,就是基于CAS乐观锁实现的。
Java中提供的synchronized只能是非公平锁。
Java中提供的ReentrantLock,ReentrantReadWriteLock可以实现公平锁和非公平锁
公平锁:线程A获取到了锁资源,线程B没有拿到,线程B去排队,线程C来了,锁被A持有,同时线程B在排队。直接排到B的后面,等待B拿到锁资源或者是B取消后,才可以尝试去竞争锁资源。
非公平锁:线程A获取到了锁资源,线程B没有拿到,线程B去排队,线程C来了,先尝试竞争一波
拿到锁资源:开心,插队成功。
没有拿到锁资源:依然要排到B的后面,等待B拿到锁资源或者是B取消后,才可以尝试去竞争锁资源。
Java中提供的synchronized、ReentrantLock是互斥锁。
Java中提供的ReentrantReadWriteLock,有互斥锁也有共享锁。
互斥锁:同一时间点,只会有一个线程持有者当前互斥锁。
共享锁:同一时间点,当前共享锁可以被多个线程同时持有。
synchronized的使用一般就是同步方法和同步代码块。
synchronized的锁是基于对象实现的。
如果使用同步方法
static:此时使用的是当前类.class作为锁(类锁)
非static:此时使用的是当前对象做为锁(对象锁)
- public class MiTest {
-
- public static void main(String[] args) {
- // 锁的是,当前Test.class
- Test.a();
-
- Test test = new Test();
- // 锁的是new出来的test对象
- test.b();
- }
-
- }
-
- class Test{
- public static synchronized void a(){
- System.out.println("1111");
- }
-
- public synchronized void b(){
- System.out.println("2222");
- }
- }
在JDK1.5的时候,Doug Lee推出了ReentrantLock,lock的性能远高于synchronized,所以JDK团队就在JDK1.6中,对synchronized做了大量的优化。
锁消除:在synchronized修饰的代码中,如果不存在操作临界资源的情况,会触发锁消除,你即便写了synchronized,他也不会触发。
public synchronized void method(){ // 没有操作临界资源 // 此时这个方法的synchronized你可以认为木有~~ }
锁膨胀:如果在一个循环中,频繁的获取和释放做资源,这样带来的消耗很大,锁膨胀就是将锁的范围扩大,避免频繁的竞争和获取锁资源带来不必要的消耗。
- public void method(){
- for(int i = 0;i < 999999;i++){
- synchronized(对象){
-
- }
- }
- // 这是上面的代码会触发锁膨胀
- synchronized(对象){
- for(int i = 0;i < 999999;i++){
-
- }
- }
- }
锁升级:ReentrantLock的实现,是先基于乐观锁的CAS尝试获取锁资源,如果拿不到锁资源,才会挂起线程。synchronized在JDK1.6之前,完全就是获取不到锁,立即挂起当前线程,所以synchronized性能比较差。
synchronized就在JDK1.6做了锁升级的优化
无锁、匿名偏向:当前对象没有作为锁存在。
偏向锁:如果当前锁资源,只有一个线程在频繁的获取和释放,那么这个线程过来,只需要判断,当前指向的线程是否是当前线程 。
如果是,直接拿着锁资源走。
如果当前线程不是我,基于CAS的方式,尝试将偏向锁指向当前线程。如果获取不到,触发锁升级,升级为轻量级锁。(偏向锁状态出现了锁竞争的情况)
轻量级锁:会采用自旋锁的方式去频繁的以CAS的形式获取锁资源(采用的是自适应自旋锁)
如果成功获取到,拿着锁资源走
如果自旋了一定次数,没拿到锁资源,锁升级。
重量级锁:就是最传统的synchronized方式,拿不到锁资源,就挂起当前线程。(用户态&内核态)
synchronized是基于对象实现的。
先要对Java中对象在堆内存的存储有一个了解。
展开MarkWord
MarkWord中标记着四种锁的信息:无锁、偏向锁、轻量级锁、
为了可以在Java中看到对象头的MarkWord信息,需要导入依赖
-
org.openjdk.jol -
jol-core -
0.9
锁默认情况下,开启了偏向锁延迟。
偏向锁在升级为轻量级锁时,会涉及到偏向锁撤销,需要等到一个安全点(STW),才可以做偏向锁撤销,在明知道有并发情况,就可以选择不开启偏向锁,或者是设置偏向锁延迟开启
因为JVM在启动时,需要加载大量的.class文件到内存中,这个操作会涉及到synchronized的使用,为了避免出现偏向锁撤销操作,JVM启动初期,有一个延迟4s开启偏向锁的操作
如果正常开启偏向锁了,那么不会出现无锁状态,对象会直接变为匿名偏向
- public static void main(String[] args) throws InterruptedException {
- Thread.sleep(5000);
- Object o = new Object();
- System.out.println(ClassLayout.parseInstance(o).toPrintable());
-
- new Thread(() -> {
-
- synchronized (o){
- //t1 - 偏向锁
- System.out.println("t1:" + ClassLayout.parseInstance(o).toPrintable());
- }
- }).start();
- //main - 偏向锁 - 轻量级锁CAS - 重量级锁
- synchronized (o){
- System.out.println("main:" + ClassLayout.parseInstance(o).toPrintable());
- }
- }
整个锁升级状态的转变:
Lock Record以及ObjectMonitor存储的内容
需要去找到openjdk,在百度中直接搜索openjdk,第一个链接就是
找到ObjectMonitor的两个文件,hpp,cpp
先查看核心属性:jdk8u/jdk8u/hotspot: 69087d08d473 src/share/vm/runtime/objectMonitor.hpp
ObjectMonitor() { _header = NULL; // header存储着MarkWord _count = 0; // 竞争锁的线程个数 _waiters = 0, // wait的线程个数 _recursions = 0; // 标识当前synchronized锁重入的次数 _object = NULL; _owner = NULL; // 持有锁的线程 _WaitSet = NULL; // 保存wait的线程信息,双向链表 _WaitSetLock = 0 ; _Responsible = NULL ; _succ = NULL ; _cxq = NULL ; // 获取锁资源失败后,线程要放到当前的单向链表中 FreeNext = NULL ; _EntryList = NULL ; // _cxq以及被唤醒的WaitSet中的线程,在一定机制下,会放到EntryList中 _SpinFreq = 0 ; _SpinClock = 0 ; OwnerIsThread = 0 ; _previous_owner_tid = 0; }
适当的查看几个C++中实现的加锁流程
jdk8u/jdk8u/hotspot: 69087d08d473 src/share/vm/runtime/objectMonitor.cpp
TryLock
- int ObjectMonitor::TryLock (Thread * Self) {
- for (;;) {
- // 拿到持有锁的线程
- void * own = _owner ;
- // 如果有线程持有锁,告辞
- if (own != NULL) return 0 ;
- // 说明没有线程持有锁,own是null,cmpxchg指令就是底层的CAS实现。
- if (Atomic::cmpxchg_ptr (Self, &_owner, NULL) == NULL) {
- // 成功获取锁资源
- return 1 ;
- }
- // 这里其实重试操作没什么意义,直接返回-1
- if (true) return -1 ;
- }
- }
try_entry
- bool ObjectMonitor::try_enter(Thread* THREAD) {
- // 在判断_owner是不是当前线程
- if (THREAD != _owner) {
- // 判断当前持有锁的线程是否是当前线程,说明轻量级锁刚刚升级过来的情况
- if (THREAD->is_lock_owned ((address)_owner)) {
- _owner = THREAD ;
- _recursions = 1 ;
- OwnerIsThread = 1 ;
- return true;
- }
- // CAS操作,尝试获取锁资源
- if (Atomic::cmpxchg_ptr (THREAD, &_owner, NULL) != NULL) {
- // 没拿到锁资源,告辞
- return false;
- }
- // 拿到锁资源
- return true;
- } else {
- // 将_recursions + 1,代表锁重入操作。
- _recursions++;
- return true;
- }
- }
enter(想方设法拿到锁资源,如果没拿到,挂起扔到_cxq单向链表中)
- void ATTR ObjectMonitor::enter(TRAPS) {
- // 拿到当前线程
- Thread * const Self = THREAD ;
- void * cur ;
- // CAS走你,
- cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;
- if (cur == NULL) {
- // 拿锁成功
- return ;
- }
- // 锁重入操作
- if (cur == Self) {
- // TODO-FIXME: check for integer overflow! BUGID 6557169.
- _recursions ++ ;
- return ;
- }
- //轻量级锁过来的。
- if (Self->is_lock_owned ((address)cur)) {
- _recursions = 1 ;
- _owner = Self ;
- OwnerIsThread = 1 ;
- return ;
- }
-
-
- // 走到这了,没拿到锁资源,count++
- Atomic::inc_ptr(&_count);
-
-
- for (;;) {
- jt->set_suspend_equivalent();
- // 入队操作,进到cxq中
- EnterI (THREAD) ;
- if (!ExitSuspendEquivalent(jt)) break ;
- _recursions = 0 ;
- _succ = NULL ;
- exit (false, Self) ;
- jt->java_suspend_self();
- }
- }
- // count--
- Atomic::dec_ptr(&_count);
-
- }
EnterI
- for (;;) {
- // 入队
- node._next = nxt = _cxq ;
- // CAS的方式入队。
- if (Atomic::cmpxchg_ptr (&node, &_cxq, nxt) == nxt) break ;
-
- // 重新尝试获取锁资源
- if (TryLock (Self) > 0) {
- assert (_succ != Self , "invariant") ;
- assert (_owner == Self , "invariant") ;
- assert (_Responsible != Self , "invariant") ;
- return ;
- }
- }