JVM 【锁】

2018年6月7日 作者 jacky
  • 线程安全
  • 对象头Mark
  • 偏向锁
  • 轻量级锁
  • 自旋锁
  • 减少锁持有时间
  • 减少锁粒度
  • 锁分离
  • 锁粗化
  • 锁消除
  • 无锁

线程安全

对象头Mark

  • Mark Word,对象头的标记,32位
  • 描述对象的hash、锁信息,垃圾回收标记,年龄
    • 指向锁记录的指针
    • 指向monitor的指针
    • GC标记
    • 偏向锁线程ID

偏向锁

偏向锁就是偏向于当前线程来说的,对于当前线程如果再次获取这个锁将会非常快。有点不合理,但是为什么会有偏向锁的呢?因为对于大部分系统来说偏向锁就有利于提高性能的,系统都是无锁竞争的情况的,所以此时偏向锁就非常适合了

  • 大部分情况是没有竞争的,所以可以通过偏向来提高性能
  • 所谓的偏向,就是偏心,即锁会偏向于当前已经占有锁的线程
  • 将对象头Mark的标记设置为偏向,并将线程ID写入对象头Mark
  • 只要没有竞争,获得偏向锁的线程,在将来进入同步块,不需要做同步
  • 当其他线程请求相同的锁时,偏向模式结束
  • -XX:+UseBiasedLocking
    • 默认启用
  • 在竞争激烈的场合,偏向锁会增加系统负担
public static List<Integer> numberList =new Vector<Integer>();
public static void main(String[] args) throws InterruptedException {
    long begin=System.currentTimeMillis();
    int count=0;
    int startnum=0;
    while(count<10000000){
        numberList.add(startnum);
        startnum+=2;
        count++;
    }
    long end=System.currentTimeMillis();
    System.out.println(end-begin);
}

偏向锁在JDK6中是默认启动的,但是不会马上启动,对于一开始系统启动的时候,是不会启动偏向锁的,以为一开始系统做初始化操作,如果加偏向锁可能会影响性能,所以需要过一阵子才会启动
本例中,使用偏向锁,可以获得5%以上的性能提升

-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
-XX:-UseBiasedLocking

轻量级锁

为什么需要轻量级锁,因为对于系统的锁来说,底层使用的monitor性能是非常慢的,所以需要轻量级锁,轻量级锁对象BasicObjectLock

  • BasicObjectLock
    • 嵌入在线程栈中的对象

  • 普通的锁处理性能不够理想,轻量级锁是一种快速的锁定方法。
  • 如果对象没有被锁定
    • 将对象头的Mark指针保存到锁对象中
    • 将对象头设置为指向锁的指针(在线程栈空间中)
    • 因为锁对象是在线程栈中的,判断这个线程是否获取锁逻辑判断只需要判断这个对象的锁指针是否锁对象中
lock->set_displaced_header(mark);
 if (mark == (markOop) Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark)) {
      TEVENT (slow_enter: release stacklock) ;
      return ;
}

  • 如果轻量级锁失败,表示存在竞争,升级为重量级锁(常规锁)
  • 在没有锁竞争的前提下,减少传统锁使用OS互斥量产生的性能损耗
  • 在竞争激烈时,轻量级锁会多做很多额外操作(肯定会升级为重量级锁),导致性能下降

自旋锁

自旋锁是明确了系统会存在锁竞争的情况存在的。

  • 当竞争存在时,如果线程可以很快获得锁,那么可以不在OS层挂起线程,让线程做几个空指令操作(自旋)
  • JDK1.6中-XX:+UseSpinning开启
  • JDK1.7中,去掉此参数,改为内置实现
  • 如果同步块很长,自旋失败,会降低系统性能
  • 如果同步块很短,自旋成功,节省线程挂起切换时间,提升系统性能
偏向锁,轻量级锁,自旋锁总结
  • 不是Java语言层面的锁优化方法
  • 内置于JVM中的获取锁的优化方法和获取锁的步骤
    • 偏向锁可用会先尝试偏向锁
    • 轻量级锁可用会先尝试轻量级锁
    • 以上都失败,尝试自旋锁
    • 再失败,尝试普通锁,使用OS互斥量在操作系统层挂起

以上是JVM系统对锁的优化,下面是Java代码层面的优化

减少锁持有时间

减少锁的粒度

  • 将大对象,拆成小对象,大大增加并行度,降低锁竞争
  • 偏向锁,轻量级锁成功率提高
  • ConcurrentHashMap
  • HashMap的同步实现
    • Collections.synchronizedMap(Map<K,V> m)
    • 返回SynchronizedMap对象
 public V get(Object key) {
            synchronized (mutex) {return m.get(key);}
        }
public V put(K key, V value) {
            synchronized (mutex) {return m.put(key, value);}
}

  • ConcurrentHashMap
    • 若干个Segment :Segment<K,V>[] segments
    • Segment中维护HashEntry<K,V>
    • put操作时
      • 先定位到Segment,锁定一个Segment,执行put
  • 在减小锁粒度后, ConcurrentHashMap允许若干个线程同时进入

问题:减少锁粒度后,可能会带来什么负面影响呢?以ConcurrentHashMap为
例,说明分割为多个Segment后,在什么情况下,会有性能损耗?

锁分离

  • 根据功能进行锁分离
  • ReadWriteLock
  • 读多写少的情况,可以提高性能

  • 读写分离思想可以延伸,只要操作互不影响,锁就可以分离
  • LinkedBlockingQueue
    • 队列
    • 链表

锁粗化

通常情况下,为了保证多线程间的有效并发,会要求每个线程持有锁的时间尽量短,即在使用完公共资源后,应该立即释放锁。只有这样,等待在这个锁上的其他线程才能尽早的获得资源执行任务。但是,凡事都有一个度,如果对同一个锁不停的进行请求、同步和释放,其本身也会消耗系统宝贵的资源,反而不利于性能的优化


锁消除

  • 在即时编译器时,如果发现不可能被共享的对象,则可以消除这些对象的锁操作

无锁

  • 锁是悲观的操作
  • 无锁是乐观的操作
  • 无锁的一种实现方式
    • CAS(Compare And Swap)
    • 非阻塞的同步
    • CAS(V,E,N)
  • 在应用层面判断多线程的干扰,如果有干扰,则通知线程重试