java对象头
Monitor
HotSpot虚拟机中对象在内存中的布局
- 对象头
(1)Mark Word
- 实例数据
- 对齐填充
ObjectMonitor() {
_header = NULL;
_count = 0;
_waiters = 0,
_recursions = 0;
_object = NULL;
_owner = NULL;
_WaitSet = NULL;//等待池
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; //锁池
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
_previous_owner_tid = 0;
}
synchronized可重入
为什么会对synchronized嗤之以鼻
早期版本中,synchronized属于重量级锁,依赖于Mutex Lock实现
线程之间的需要从用户太转换到核心态,开销较大
自旋锁
许多情况下,共享数据的锁定状态持续时间较短,切换线程不值得
通过让线程执行忙循环等待锁的释放,不让出CPU。类似while(true),又不像sleep会让出cpu
1.4出现默认关闭,1.6默认开启
缺点:若锁被其他线程长时间占用,会带来许多性能上的开销
自适应自旋锁
自旋的次数不再固定
由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定
锁消除
JIT编译时, 对运行上下文进行扫描,去除不可能存在竞争的锁
锁粗化
int i = 0;
StringBuffer sb = new StringBuffer();
while(i<100){
sb.append(target);
}
return sb.toString();
jvm会对append优化,将append中的synchronized扩大锁的范围,进行避免反复的加锁解锁
synchronized的四种状态
无锁, 偏向锁,轻量锁,重量锁
锁膨胀(升级)方向:无锁> 偏向锁>轻量锁>重量锁
偏向锁:减少同一线程获取锁的代价
大多数情况下锁不存在多线程竞争,总是由同一个线程多次获得
核心思想:
如果一个线程获得了锁,那么锁就进入偏向模式,此时Mark word的结构也变为偏向锁结构,当该线程再次请求锁时,无需要再做任何同步操作,即获取锁的过程只需要检查Mark word的锁标记位为偏向锁以及当前线程ID等于Mark word的threadId即可,这样就省去了大量有关锁的申请的操作(CAS)。
缺点:不适用锁竞争比较激烈的多线程场合,偏向锁,失败后不会立即膨胀成重量锁,会先膨胀成轻量级锁
轻量级锁
轻量级锁是由偏向锁升级来的,偏向锁运行在一个线程进入同步块的情况下,当第二个线程加入锁争用的时候,偏向锁就会升级为轻量级锁
适应的场景:线程交替执行同步块
若存在同一时间访问同一锁的情况,就会导致轻量级锁膨胀为重量级锁,
等待的线程会采用自旋的方式
重量级锁
线程竞争不使用自旋,不会消耗cpu
ReentrantLock(再入锁)
位于java.util.concurrent.locks包
和CountDownLatch、FutureTask、Semaphore一样基于AQS实现
能够实现比synchronized更细粒度的控制,如控制fairnes(公平)
调用lock()之后,必须调用unlock()释放锁
ReentrantLock将锁对象化
判断是否有线程,或者某个特定线程,在排队等待获取锁
带超时的获取锁的尝试
感知有没有成功获取锁
总结
synchronized是关键字,ReentrantLock是类
ReentrantLock可以进行等待时间,避免死锁
ReentrantLock可以获取各种锁的信息
ReentrantLock可以灵活地实现多路通知
机制:sync操作Mark Word, lock调用Unsafe类的park()方法