图片 2

Java延时实例分析:Lock vs Synchronized

这篇文章通过实例讨论了:

前言

最近在使用BlockQueue和ConcurrentHashMap中都有个核心的东西ReentrantLock,网上有很多关于重入锁的介绍。下面自己的几个问题,然后再通过自己的实现来把问题讲清楚。

API官方解释

一个可重入的互斥锁 Lock,它具有与使用 synchronized
方法和语句所访问的隐式监视器锁相同的一些基本行为和语义,但功能更强大

ReentrantLock
将由最近成功获得锁,并且还没有释放该锁的线程所”拥有”。当锁没有被另一个线程所拥有时,调用
lock
的线程将成功获取该锁并返回。如果当前线程已经拥有该锁,此方法将立即返回。可以使用
isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。
此类的构造方法接受一个可选的公平 参数。当设置为 true
时,在多个线程的争用下,这些锁倾向于将访问权授予等待时间最长的线程。否则此锁将无法保证任何特定访问顺序。与采用默认设置(使用不公平锁)相比,使用公平锁的程序在许多线程访问时表现为很低的总体吞吐量(即速度很慢,常常极其慢),但是在获得锁和保证锁分配的均衡性时差异较小。不过要注意的是,公平锁不能保证线程调度的公平性。因此,使用公平锁的众多线程中的一员可能获得多倍的成功机会,这种情况发生在其他活动线程没有被处理并且目前并未持有锁时。还要注意的是,未定时的
tryLock
方法并没有使用公平设置。因为即使其他线程正在等待,只要该锁是可用的,此方法就可以获得成功。

– java.concurrent.Lock创建的垃圾

典型用法

class X {
   private final ReentrantLock lock = new ReentrantLock();
   // ...

   public void m() { 
     lock.lock();  // block until condition holds
     try {
       // ... method body
     } finally {
       lock.unlock()
     }
   }
 }
  • 比较Lock和synchronized
  • 如何通过编程方式计算延时
  • Lock和synchronized竞争带来的影响
  • 延迟测试中由于遗漏(co-ordinated omission)可能对结果的影响

为什么理解ReentrantLock

  1. JDK里面的ReentrantLock实现非常精巧,ConcurrentHashMap,各种Queue都是基于ReentrantLock实现的,所以,了解ReentrantLock是十分必要的。
  2. ReentrantLock使用非常灵活,synchronized是JVM实现的,用起来不那么灵活。
  3. 了解内部实现原理,可以更好的帮助我们在开发中选型,也能更加容易理解并发包下其他实现类的原理。

回到我最喜欢的一个主题:垃圾的创建与分配。可以从我以前的文章(如:性能优化的首要法则和重视性能优化首要法则:逃逸分析的效果)获取更多关于这个议题的细节。尤其弄懂在性能问题上,为什么分配是如此重要的因素。

ReentrantLock和synchronized

java中存在两种锁,一种是JDK实现的synchronized,还有一种是Lock,两者用法相似,又各有特点,了解其中的区别,才能更好的取舍。

几天前,当我诊断一些 JIT 编译期间奇怪的分配问题时,发现
java.util.concurrent.locks.ReentrantLock
的分配有问题,不过这只在竞争条件下出现。(这一点很容易证明,只要运行一个在
Lock 上建立竞争并指定 –verbosegc 参数测试程序(类似下面的程序))。

实现
  1. synchronized是基于JVM实现的,Lock是基于java
    API实现的,我们可以通过源码就能知道Lock的实现。
  2. 两者的实现思路一致,都是抽象出来一个同步队列和一个等待队列,争抢锁的线程不断在同步队列和等待队列中不断转换。
  3. synchronized基于并发程度抽象出偏向锁、轻量级锁和重量级锁,而Lock没有这样的概念。

示例是在有 Lock 竞争时 GC 的输出结果:

使用
  1. 对于使用者的直观体验上Lock是比较复杂的,需要lock和unlock,如果忘记释放锁就会产生死锁的问题,通常需要在finally中进行锁的释放。但是synchronized的使用十分简单,只需要对自己的方法或者关注的同步对象或类使用synchronized关键字即可
[GC (Allocation Failure) 16384K->1400K(62976K), 0.0016854 secs]
[GC (Allocation Failure) 17784K->1072K(62976K), 0.0011939 secs]
[GC (Allocation Failure) 17456K->1040K(62976K), 0.0008452 secs]
[GC (Allocation Failure) 17424K->1104K(62976K), 0.0008338 secs]
[GC (Allocation Failure) 17488K->1056K(61952K), 0.0008799 secs]
[GC (Allocation Failure) 17440K->1024K(61952K), 0.0010529 secs]
[GC (Allocation Failure) 17408K->1161K(61952K), 0.0012381 secs]
[GC (Allocation Failure) 17545K->1097K(61440K), 0.0004592 secs]
[GC (Allocation Failure) 16969K->1129K(61952K), 0.0004500 secs]

[GC (Allocation Failure) 17001K->1129K(61952K), 0.0003857 secs]
特点
功能 synchronized ReentrantLock
锁获取超时 不支持 支持
获取锁响应中断 不支持 支持
是否要手动释放锁

我怀疑是否是在垃圾回收时必须对清理 Lock
上分配的空间,在高度竞争的环境下,将会选择一种比内建的 ‘synchronized‘
更坏的同步策略。

性能
  1. 早期的synchronized是十分低下的,在1.5之后引入了偏向锁,轻量级锁,重量级锁,同时也优化了锁的争抢流程,大大提高
    了synchronized的性能,同时在后面的版本中也还在对synchronized有优化。后面在JDK1.8中,ConcurrentHashMap取消了ReentrantLock的设计,而是直接用synchronized,因为synchronized在数据量少时性能足够优秀,而且整个流程更加简单,具体可以参考谈谈ConcurrentHashMap1.7和1.8的不同实现
  2. ReentrantLock没有像synchronized那样对锁划分成多个等级,根据并发程度的不同采取不同的策略,由于synchronized在竞争激烈的情况下会做锁的升级,性能急剧下降。所以ReentrantLock在竞争比较激烈的时候性能是很稳定的,少量竞争或者单线程的时候可能会逊色一些。

当然,这个问题比其他任何问题都更加学术。如果你确实非常关心延迟,你会发现自己从来不会(或者绝不应该)有这样一种情况会需要这么多的线程锁。不过,请继续跟我一起探究这个问题,因为这个过程和结果都非常有趣。

源码分析

  1. ReentrantLock实现Lock接口。Lock 实现提供了比使用 synchronized
    方法和语句可获得的更广泛的锁定操作,此实现允许更灵活的结构,可以具有差别很大的属性,可以支持多个相关的
    Condition 对象。
  2. ReentrantLock内部是由Sync,NonfairSync(非公平同步),FairSync(公平同步)三个内部类实现,且这三个内部类都实现继承自非常著名的AbstractQueuedSynchronizer,简写AQS,中文名叫队列同步器,了解这个队列同步器,基本上就完成对整个concurrent包下的锁完全了解了。很多人不了解为何设计成内部类,我记得有一句话讲得好,内部类就像人体的一个器官,它自己有完整的功能,也能给身体提供功能,如果不把它设计成一个内部类就会很凌乱。
  3. 默认构造成NonfairSync。源码如下

    /**
     * Creates an instance of {@code ReentrantLock}.
     * This is equivalent to using {@code ReentrantLock(false)}.
     */
    public ReentrantLock() {
        sync = new NonfairSync();
    }
  1. 调用Lock方法,我们先从默认非公平锁开始分析

  /**
    * Performs lock.  Try immediate barge, backing up to normal
    * acquire on failure.
    */
    final void lock() {
         if (compareAndSetState(0, 1))
             // 设置当前拥有独占访问的线程。
             setExclusiveOwnerThread(Thread.currentThread());
         else
             acquire(1);
    }

代码一开始就直接用compareAndSetState,这是典型的CAS操作,关于CAS操作可以参考java基础:CAS操作,然后就是设置当前拥有独占访问的线程,否则执行acquire(1)
非公平锁的acquire(1)实现

    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

tryAcquire的底层实现

        final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }

意思就是如果没有,就设置当前拥有独占访问的线程,设置完后就new一个Node节点添加到AQS队列中去等,等获得到空闲时就会设置当前拥有独自访问的线程,完事后就调用Thread.currentThread().interrupt();中断线程一直去尝试获取。

  1. 公平锁Lock实现

        final void lock() {
            acquire(1);
        }

我们发现公平锁直接就调用acquire(1)方法,与非公平锁不同的是缺少CAS操作。

  1. lock.unLock();实现

        protected final boolean tryRelease(int releases) {
            int c = getState() - releases;
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            if (c == 0) {
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
        }

不管是公平锁还是非公平锁,unLock实现都一样,基本上就是设置一些状态,然后把独占线程清空。

简史:锁是2004年,在Java
1.5中引入的。由于对简单并发结构的迫切需要,锁以及其他并发工具因此而诞生。在这之前,你不得不通过内建的
synchronized 和 Object 的 wait()、notify() 方法来控制并发。

什么时候选择用 ReentrantLock 代替 synchronized

在早期的版本中,synchronized性能其实非常底的,但在1.8之后,对synchronized的优化已经足够好了,甚至一些情况下,synchronized性能比ReentrantLock还要好,所以在1.8版本的ConcurrentHashMap实现取消了ReetrantLock设计,直接用synchronized。这并不代表ReetrantLock就不行了,在高并发及多线程环境下,ReetrantLock的性能依旧是最优选择。

ReentrantLock 提供许多比 synchronized 更好的功能,下面是一些例子:

总结

了解ReentrantLock其实最主要的两点,一是CAS操作,二是AQS,当然AQS是一切并发包下基础,我们只有了解其中的原理,就很容易了解这些锁的调用关系,其实都是AQS的一些应用,比如公平锁与非公平锁的区别就是是否获得锁时是否有CAS操作,有的是非公平锁,没有的是公平锁。因为ReentrantLock是对像,synchronized的一些用法都可以用ReentrantLock实现,而一些时间锁等候、可中断锁等候、无块结构锁、多个条件变量或者锁投票是synchronized不具备的,而ReentrantLock的性能在多线程环境中优势相当明显,所以理解ReentrantLock是对多线程和大并发环境的编程多了一种技术选型。

  • 变得非结构化——比如,不会受块或方法的限制,允许你跨多个方法持有锁。
  • 轮询锁
  • 等待锁超时
  • 配置失败策略

但是它们在延迟测试中有什么作用呢?

我写了一个简单的测试来比较 Lock 和 synchronized 的性能。

这段代码允许改变线程的数量(1个线程意味着不存在竞争)及竞争的数量。通过有遗漏(coordinated
omission)和没有遗漏来衡量。
采用 Lock 或者 synchronised 来运行测试。

为了记录结果,我使用了 Histogram 类。该类是 Peter Lawrey
创建的。你可以在 Chronicle-Core
的工具类中找到该类。

import org.junit.Test;

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class LockVsSync {
    private static final boolean COORDINATED_OMISSION = Boolean.getBoolean("coordinatedOmission");
    //Either run testing Lock or testing synchronized
    private static final boolean IS_LOCK = Boolean.getBoolean("isLock");
    private static final int NUM_THREADS = Integer.getInteger("numThreads");

    <a href='http://www.jobbole.com/members/madao'>@Test</a>
    public void test() throws InterruptedException {
        Lock lock = new ReentrantLock();
        for (int t = 0; t &lt; NUM_THREADS; t++) {
            if (t == 0) {
                //Set the first thread as the master which will be measured
                //设置第一个线程作为测量的线程
                //The other threads are only to cause contention
                //其他线程只是引起竞争
                Runner r = new Runner(lock, true);
                r.start();
            } else {
                Runner r = new Runner(lock, false);
                r.start();
            }
        }

        synchronized(this){
            //Hold the main thread from completing
            wait();
        }

    }

    private void testLock(Lock rlock) {
        rlock.lock();
        try {
            for (int i = 0; i &lt; 2; i++) {
                double x = 10 / 4.5 + i;
            }
        } finally {
            rlock.unlock();
        }
    }

    private synchronized void testSync() {
        for (int i = 0; i &lt; 2; i++) {
            double x = 10 / 4.5 + i;
        }
    }

    class Runner extends Thread {
        private Lock lock;
        private boolean master;

        public Runner(Lock lock, boolean master) {
            this.lock = lock;
            this.master = master;
        }

        @Override
        public void run() {
            Histogram histogram = null;
            if (master)
                histogram = new Histogram();

            long rate = 1000;//expect 1 every microsecond
            long now =0;
            for (int i = -10000; i 0){
                    if(!COORDINATED_OMISSION) {
                        now += rate;
                        while(System.nanoTime() =0 &amp;&amp; master){
                    histogram.sample(System.nanoTime() - now);
                }
            }
            if (master) {
                System.out.println(histogram.toMicrosFormat());
                System.exit(0);
            }
        }
    }
}

结果如下:

这是没有遗漏(co-ordinated omission)的结果:

  • 采用微秒来衡量。
  • 图形的顶部就是延迟的分布。
  • 这是有竞争的测试,使用四个线程执行该程序。
  • 这个测试是在8核的 MBP i7 上运行的。
  • 每次测试迭代200,000,000次,并有10,000次预热。
  • 根据吞吐率为每微妙迭代一次来调整遗漏。

图片 1

如我们所期望的一样,没有竞争时,结果是基本相同的。JIT 已经对 Lock 和
synchronized 进行了优化。在有竞争的情况下,占用百分比低的时候,使用 Lock
会稍微快一点,但是这种差别真的很小。所以,即使存在很多的年青代GC(minor
GC),它们也没有显著的降低 Lock 效率。如果都是轻量级的
Lock,总体上就比较快了。

这是调整为有遗漏情况后的结果。

图片 2

当然,在有遗漏的情况下延迟会更高。

再次可以看到,在无竞争情况下,lock 和 synchronized
的性能是相同——这就没什么很惊奇了。

在竞争条件下,百分率为99%时,我们看到 synchronized 比 lock
表现好10X。在这之后,两者的表现基本是一致的。

我猜测这是因为GC回收的效率导致 lock 比 synchronised
要慢,大概每300-1200微妙发生一次GC回收。尤其是到达99%之后,慢得就相当明显了。在这个之后,延迟率可能与硬件和操作系统(OS)相关。但是,这只是我个人的推断,没有做更深入的调查。

结论:

这篇文章更多的是怎么去测量和分析延迟。在竞争条件下,Lock的分配是一个非常有意思的话题,在真实世界里,这个问题也未必有什么实际的不同。

发表评论

电子邮件地址不会被公开。 必填项已用*标注