在早以前的版本中,synchronized一直被冠以性能消耗高,十分重的标签,而且给他取名为重量级锁,不过在jdk1.6后对synchronized进行了一波优化,使他变得并无那么重了,以致于如今咱们可使用synchronized而不用特别担忧它的性能消耗问题微信
首先咱们作一个最简单的比喻,咱们把被锁锁住的代码比喻为一个房间,房间的钥匙只有一把, 每个进入代码块的线程表示进入这个屋子的人,这个房间有一个管理员,从管理员那边要钥匙的过程,就是获取锁的过程.并发
在第一我的A进入房间之后,管理员没有把钥匙收起来,而是把钥匙放在门框上,而且告诉这我的,之后只要是你来直接开门就好,这样若是一直这个A使用这个房间,那么他就不须要每次都向管理员拿钥匙,直接去门框上取钥匙就行了,这就是偏向锁.性能
偏向锁,顾名思义是偏向某一个线程的锁,jdk的开发人员发现,虽然使用人员对这块代码加了锁,可是大部分时间仍是单独的一个线程来访问,若是此时每次还要手动获取锁,那么对性能的消耗也是极大的.优化
因此在该某个线程第一次成功锁时,会在对象头和线程的栈帧中的锁记录中存储所偏向的线程id,若是下一次仍是该线程获取锁,则不须要进行cas操做来加锁和解锁,大大减小了性能的消耗.线程
偏向锁只能在有且只有一个线程获取锁时生效,若是有第二个线程想要获取锁,那么偏向锁就会膨胀为轻量级锁cdn
咱们继续使用上面的比喻,若是此时来了一个B也要进入该房间,他发现该房间已经被开过了,那么他就去门框上找钥匙,若是找到了钥匙,那么他也不须要去找管理员,直接用钥匙开门就好,也省下了跟管理员交互的开销.对象
轻量级锁是相对于重量级锁而言,轻量级锁不须要申请互斥量,只须要将markwork中的部分字节CAS更新指向线程的id,若是更新成功则表示已经成功的获取了锁,不然说明已经有线程获取了轻量级锁,发生了锁竞争,轻量级锁开始自旋.blog
比喻继续,在B使用房间期间,A也来了想进入房间,他来了之后发现钥匙不在门框上,此时他没有直接去找管理员,而是在门口转悠了几圈,若是此时B使用完了房间,那么A则能够继续使用,若是B好半天还不出来,或者此时又来了一个C,那么A就去找管理员排队(膨胀为重量级锁)继承
自旋锁是轻量级锁在锁膨胀前作的最后一次挣扎,由于有的代码即使加了锁,可是执行效率很快,或者竞争率很低,竞争的线程没有必要阻塞掉,只须要自我循环(例如for循环)等待很短的时间,上一个线程就把锁释放了,在1.5中jdk设置自旋锁为自旋十次,在1.6中优化为自适应的自旋锁,能够根据加锁的代码来决定要自选几回. 若是自旋超过必定次数,或者此时有第三个线程来竞争该锁时,锁膨胀为重量级锁递归
synchronized的具体实现以下图
synchronized是非公平锁.当线程在进入尾部队列以前,会尝试着先自旋获取锁,若是获取失败才选择进入尾部队列.
顾名思义 公平锁即为先进队列的先获取锁,十分公平,而非公平锁则像synchronized同样颇有可能不进入队列,直接获取锁,插队进入.
乐观锁是一种乐观思想,认为读多写少,遇到并发写的可能性比较低,每次获取数据不回家所,在更新时根据版本号判断此间是否有别人更改过数据,若是有人更改了数据,则重复读--比较--写的操做
悲观锁则是悲观思想 认为写多读少 每次拿数据都会上锁,其余读的数据都会阻塞知道拿到锁
可重入锁又名递归锁,是指同一个线程在外层方法获取锁的时候,在进入该线程的内层方法会自动获取锁(前提是锁的是同一个对象或者class),不会由于以前已经获取过尚未释放锁而阻塞,Java中synchronized和ReentrantLock都是可重入锁在某些状况下能够避免死锁
那么可重入锁是怎么实现的呢,首先可重入锁和非可重入锁都继承父类AQS,AQS具体实现会单开一章来说,在其父类中维护一个同步状态status来计数冲入次数,status初始为0,当线程获取锁时则status+1
可重入锁与非可重入锁的区别在于,可重入锁在status!=0时会检测该线程是否获取过该对象的锁,若是获取过则将status再+1,释放是也是一层层的释放直到status=0
而非可重入锁不论是谁获取的锁,只要该status不等于0 那么不可重入锁就会阻塞,若是是该线程本身获取了该锁而且没有超时时间的活,则构成了死锁
独占锁是指该锁一次只能被一个线程来使用,共享锁则能够被多个线程来持有.
上面说的独占锁与共享锁是一种广义的概念,而互斥锁与读写锁则是具体的实现
在Java中互斥锁的具体实现为ReentrantLock,而读写锁的具体时间为ReadWriteLock
互斥锁任什么时候刻只有一个线程能够获取,而读写锁在读读的时候能够并发执行,而读写,写写则是互斥的
感谢阅读
有兴趣能够关注个人我的微信公众号,会按期推送关于Java的技术文章,并且目前不恰饭都是干货哈哈哈哈