自旋锁与自适应自旋
互斥同步的时候,挂起线程和恢复线程的操作都需要转入内核态中完成,这些操作给系统的并发带来很大压力。同步虚拟机团队发现许多应用上锁定状态的维持时间很短,为了这段时间去挂起和恢复线程并不值得。所以当一个线程请求另一个线程的锁时,我们可以让请求线程稍等一下,但不放弃处理器的执行时间,看看持有锁的线程是否很快就会释放锁,我们只需让请求线程执行一个忙循环(自旋),这就是所谓的自旋锁。
自旋等待的时间是有限度的,因为如果锁占用时间很长,那么自旋的线程只会白白消耗处理器资源,带来性能上的浪费,所以在JDK1.6引入了自适应的自旋锁,自适应的自旋锁自旋时间不再固定,而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定,如果在同一个锁上,自旋等待刚刚获得成功,并且持有锁的线程正在运行,那么虚拟机就会认为这次自旋也很有可能获得成功,进而它将允许自旋等待持续相对更长的时间,比如100个循环,对于自旋很少成功的锁,以后获取这个锁将可能省略掉自旋过程。
JDK1.6后锁自旋默认开启。
锁消除
锁消除是指虚拟机即时编译器在运行时,对一些代码上要求同步,但被检查到不可能存在共享数据竞争的锁进行消除。如果判断在一段代码中,堆上的所有数据都不会逃逸出去从而被其他线程访问到,那就可以把它们当作栈上数据对待,认为它们是线程私有的,同步加锁自然就无须进行
锁粗化
我们编写代码时,推荐将同步块的作用范围限制得尽量小——只在共享的实际作用域才进行同步,这样是为了使得需要同步的操作数量尽可能变小,如果存在锁竞争,那等待锁的线程也能尽快拿到锁。
如果一系列的连续操作都对同一个对象反复加锁和解锁,甚至加锁操作是出现在循环体中,即时没有线程竞争,频繁进行互斥同步操作也会导致不必要的性能损耗。
如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁,将会把加锁同步的范围扩展(粗化)到整个操作序列的外部。即扩展到对象第一次加锁前和最后一次加锁后。