关于Synchronized的小结
目录
一.特性
1.既是乐观锁又是悲观锁
2.是轻量级锁,也是重量级锁
3.不是读写锁,是互斥锁
4.是可重入锁
5.非公平锁
6.加锁之后,运行完毕自动解锁释放资源
二:Synchronized使用
第一种:定义一个额外的变量来控制加锁和解锁(类似于吉祥物)
第一种:直接给类/方法上锁
三.synchronized的优化
运行机制上的优化
编译阶段进行的优化手段
锁消除
程序员代码上进行优化
锁粗化
一.特性
1.既是乐观锁又是悲观锁
乐观锁:就是在操作数据时非常乐观，认为别的线程不会同时修改数据，所以不会上锁，但是在更新的时候会判断在此期间别的线程有没有更新过这个数据。
悲观锁:就在操作数据时比较悲观，每次去拿数据的时候认为别的线程也会同时修改数据，所以每次在拿数据的时候都会上锁，这样别的线程想拿到这个数据就会阻塞直到它拿到锁。
2.是轻量级锁,也是重量级锁
偏向锁:单线程情况下,第一个使用锁,就升级为偏向锁
轻量级锁:多线程下,第二个线程来同一个线程竞争同一个资源,这个时候偏向锁升级为轻量级锁(竞争很小)
重量级锁:超级多线程同时来竞争一个资源(竞争非常激烈),这个时候由轻量级锁升级为重量级锁
3.不是读写锁,是互斥锁
读写锁:多线程下,同一时刻只能有一个线程读取这份资源,其他线程不能读取处于阻塞
互斥锁:多线程下,同一时刻只能有一个线程使用这份资源,其他线程不能使用处于阻塞
4.是可重入锁
可重入锁:在两个带锁的线程中,当前线程1的锁没被解锁的情况下,能够去执行带有锁的线程2
不可重入锁:在两个带锁的线程中,当前线程1的锁没被解锁的情况下,不可以去执行带有锁的线程2
5.非公平锁
公平锁:多线程下,当锁被线程1释放后,线程2,3,4依据自己谁先请求资源的时间先后获取该资源,进行上锁操作
非公平锁:多线程下,当锁被线程1释放后,不管时间请求的顺序先后,线程2,3,4各凭本事抢占该资源,进行上锁操作
6.加锁之后,运行完毕自动解锁释放资源
自动释放:Synchronized的代码执行完毕之后,不用调用解锁的代码,就能自动解锁释放资源
非自动释放:与Synchronized当对应的有个叫做ReentrantLock的锁,ReentrantLock就是调用之后,必须要程序员手动输入"解锁指令"来关闭
二:Synchronized使用
第一种:定义一个额外的变量来控制加锁和解锁(类似于吉祥物)
public class demo2 {
//定义一个Object类,名字叫做lock的变量作为锁
static Object lock = new Object();
public static void main(String[] args) {
synchronized (lock){
}
}
}第一种:直接给类/方法上锁
//给类上锁
public class demo2 {
synchronized public static void main(String[] args) {
}
}
//给方法上锁
public class demo2 {
synchronized static void func(){
System.out.println("hello");
}
public static void main(String[] args) {
}
}三.synchronized的优化
运行机制上的优化
无->偏向锁->轻量级锁->重量级锁
注意:在轻量级锁这里synchronized,采用[自适应自旋锁]
自旋锁:一直不停反复查看当前锁是否被释放,一旦释放,自己就立刻占为己有,为期上锁
自适应自旋锁:重复一定次数/一定时间后,停止查看
编译阶段进行的优化手段
锁消除
锁消除：编译器+JVM会检测当前代码是否是多线程执行，是否有必要加锁，如果没有必要，在编写的时候又把锁给写上了，就会在编译过程中自动把锁去掉。
列如StringBuffer,他每次apped操作都是需要加锁和解锁,如果只有简单的append操作的话
那么编译器就直接进行一次加锁和解锁,而不是多次加锁和解锁
程序员代码上进行优化
锁粗化
锁的粒度：synchronized代码块，包含代码的多少（代码越多，粒度越大 ；代码越少，粒度越细）。
一般写代码的时候，多数情况下，是希望锁的粒度更小一点（串行执行的代码少，并发执行的代码就多）。串行代码越少越少，程序执行就越快。
举一个例子
假如说你现在需要向领导汇报三个工作
你可以选择,分三次汇报三个不同的工作
或者选择,一次汇报三个工作
显然,我们是更倾向于一次汇报三个工作的,因为他更高效