概述
锁的概念一直比较模糊,记录一下自己学习的过程。
- 从宏观来说,锁分为悲观锁和乐观锁
- 乐观锁,是一种乐观的思想,认为读多于写,每次拿到数据都不会加锁,但是更新数据的时候会判断一下是否被其他线程修改过,可以比较数值和版本号。乐观锁适用于大量读的应用,可以提高吞吐量,比如CAS,核心思想是 冲突检测 和 数据更新
- 悲观锁,每次拿数据都会上锁,比如行锁,表锁,synchronized也是一种悲观锁
- 从代码角度来说,锁又可以分为synchronized 和 lock
1.6中java锁有4种状态,无锁-偏向锁-轻量级锁-重量级锁,不能说哪一种锁比较好,而是要分析找到合适自己业务的锁。
Synchronized
- 线程同步最常用的关键字,用法简单,代码可维护性好
- synchronized用于static方法,或者synchronized (类.class)相当于给类加锁
- synchronized用于方法,或者代码块,锁的是当前对象
- 线程冲突严重的情况下,synchronized性能优于CAS
自旋锁
- 当一个线程在获取锁的时候,如果锁已经被其它线程获取,那么该线程将循环等待,然后不断的判断锁是否能够被成功获取,直到获取到锁才会退出循环。
- 自旋锁从1.4开始引入,可以通过-XX:+UseSpinning 开启,产生的背景:阻塞的线程,它的挂起和恢复都需要在内核中完成,有些共享数据的锁,只会持续很短一段时间,为了这一点时间挂起线程不太值得,为了减少线程的切换,让当前线程循环,让其他线程先等待。
- 自旋锁虽然解决了线程切换的问题,但是也占用了CPU处理时间,如果锁占用时间很长,自旋只会浪费了CPU,所以在1.6中引入了自适应自旋锁,相比之前智能化了一点,就是对于同一个锁对象,如果刚刚成功过,jvm认为这一次也有可能成功,允许它自旋次数多一些;如果某个锁,从来没有成功过,以后就避免在这里自旋,减少资源浪费。
- 优点:没有线程切换,速度快
- 缺点:如果锁占用时间长,浪费CPU资源;自旋锁是非公平锁,可能造成线程饥饿
AtomicReference reference = new AtomicReference();
public void lock(){
while (!reference.compareAndSet(null,1)){
//donothing
System.out.println("waitting");
}
}
轻量级锁
轻量级锁是1.6中引入的,轻量级是相对于传统的锁机制(todo)来说,并不是来替代重量级锁,其本意是在 没有多线程竞争的情况下,减少重量级锁带来的性能消耗。
通过jvm对象的内存布局来学习轻量级锁,hotspot的对象头分为两部分,一是mark word,存储对象自己运行时的数据,hashcode,GC age,锁定状态等,另一部分是指向方法区对象类型的指针。
偏向锁
也是1.6中引入,默认开启(-XX:+UseBiasedLocking),同样是一个效益权衡的优化(不一定总是对程序有利,如果线程中的大多数锁总是被多个线程访问,偏向锁便失去了意义)
- 偏向锁的偏字,意思就是 这个锁偏向于第一个获得他的线程
- 竞争激烈的情况下,手动关闭
锁粗化
如果有一系列的操作是针对同一个对象加锁、解释,锁自动扩大范围
例如StringBuffer的append,例如for循环内部的Synchronized
StringBuffer stringBuffer = new StringBuffer();
//synchronized
stringBuffer.append("1");
stringBuffer.append("2");
stringBuffer.append("3");
//unlock
锁消除
jvm在运行时,代码中写了同步,但是实际检测到 不可能存在竞争的锁,予以消除。
可以通过 -XX:+EliminateLocks 开启锁消除
逃逸分析技术
方法中定义的对象,作为参数传到其他方法,称为 方法逃逸;
赋值给类变量、或者其他线程可以访问的变量,称为 线程逃逸。
可以通过 -XX:+DoEscapeAnalysis 开启逃逸分析,如果能够确定一个对象不会逃逸(todo具体判断过程暂不分析),jvm可能进行的一些优化:
- 栈上分配,java堆中的对象对各个线程都是共享的,而在栈上的对象,随着栈帧的出栈而销毁,GC的压力也会减小
- 同步消除,如果逃逸分析确定一个对象不会逃逸出线程,那么对这个变量的同步措施也可以消除
- 标量替换,int,long,reference等都是java中最小的类型,无法进一步分解,称为标量,java对象可以分解,称为聚合量,如果逃逸分析证明了一个对象不会逃逸,那么很有可能把这个java对象拆散,直接创建若干个该对象的成员变量。
一段很low的代码,主要是验证锁消除:
public void lockEliminate() {
StringBuffer stringBuffer = new StringBuffer();
stringBuffer.append("1");
}
for(int j=0;j<5;j++) {
long time = System.nanoTime();
LockEliminationTest eliminationTest = new LockEliminationTest();
for (int i = 0; i < 10000; i++) {
eliminationTest.lockEliminate();
}
System.out.println("消耗时间 : " + (System.nanoTime() - time));
}
带上 -XX:+EliminateLocks -XX:-UseBiasedLocking (关闭偏向锁)
不带参数如下,区别还是有的
继续说锁消除,String的+号,1.5之前会自动转换为StringBuffer来append,1.5之后,转换为Stringbuilder
public String getStr(String str1,String str2){
return str1 +str2;
}
相当于
public String getStr(String str1,String str2){
StringBuffer stringBuffer = new StringBuffer();
stringBuffer.append(str1);
stringBuffer.append(str2);
return stringBuffer.toString();
}
这个对象的作用域只是这个方法,不会发生逃逸,锁可以消除掉。
AQS
AbstractQueuedSynchronizer,ReentrantLock的sync也继承自该类,具体内容单独写
abstract static class Sync extends AbstractQueuedSynchronizer {
ReentrantLock
ReentrantLock lock = new ReentrantLock(true); 公平锁,先等待的线程先得到锁,但是性能低,默认是非公平锁
- isHeldByCurrentThread() 如果当前线程持有锁,返回true
- isLock() 如果该锁被任意线程持有,返回true
源码解析
非公平锁的lock
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
//compareAndSetState 调用的其实是unsafe的compareAndSwapInt
protected final boolean compareAndSetState(int expect, int update) {
// See below for intrinsics setup to support this
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
unsafe的compareAndSwapInt,该方法的4个参数
- this 需要改变的对象 stateOffset 偏移量
- expect 期待更新的值
- update 更新后的值
锁的优化
- 避免死锁
- 减小锁的粒度
- 减小锁的持有时间
- 读写分离锁