【试验局】ReentrantLock中非公平锁与公平锁的性能测试

硬件环境：

　　CPU：AMD Phenom(tm) II X4 955 Processor

　　Memory：8G

　　SSD(128G)：/

　　HDD(1T)：/home/

软件环境：

　　OS：Ubuntu14.04.3 LTS

　　Java：JDK1.7

　　关于ReentrantLock中非公平锁和公平锁详细区别以及实现方式在这里不再叙述，有关ReentrantLock的源码解析参照。

　　首先我们用实例验证，非公平锁以及公平锁是否是其介绍的那样，非公平锁在获取锁的时候会首先进行抢锁，在获取锁失败后才会将当前线程加入同步队列队尾中，而公平锁则是符合请求的绝对顺序，也就是会按照先来后到FIFO。

package com.lock;

import org.junit.Test;

import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

/**
 * Created by yulinfeng on 5/24/17.
 */
public class FairAndUnfairTest {
    private static Lock fairLock = new ReentrantLockMine(true);
    private static Lock unfairLock = new ReentrantLockMine(false);

    @Test
    public void unfair() throws InterruptedException {
        testLock("非公平锁", unfairLock);
    }

    @Test
    public void fair() throws InterruptedException {
        testLock("公平锁", fairLock);
    }

    private void testLock(String type, Lock lock) throws InterruptedException {
        System.out.println(type);
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(new Job(lock)){
                public String toString() {
                    return getName();
                }
            };
            thread.setName("" + i);
            thread.start();
        }
        Thread.sleep(11000);
    }

    private static class Job implements Runnable{
        private Lock lock;
        public Job(Lock lock) {
            this.lock = lock;
        }

        public void run() {
            for (int i = 0; i < 2; i++) {
                lock.lock();
                try {
                    Thread.sleep(1000);
                    System.out.println("获取锁的当前线程[" + Thread.currentThread().getName() + "], 同步队列中的线程" + ((ReentrantLockMine)lock).getQueuedThreads() + "");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    lock.unlock();
                }
            }
        }
    }

    private static class ReentrantLockMine extends ReentrantLock {  //重新实现ReentrantLock类是为了重写getQueuedThreads方法，便于我们试验的观察
        public ReentrantLockMine(boolean fair) {
            super(fair);
        }

        @Override
        protected Collection<Thread> getQueuedThreads() {   //获取同步队列中的线程
            List<Thread> arrayList = new ArrayList<Thread>(super.getQueuedThreads());
            Collections.reverse(arrayList);
            return arrayList;
        }
    }
}

　　上面这段代码：创建5个线程，每个线程中有两次获取锁与释放锁的行为。运行代码观察结果：

　　

　　显然，试验结果与我们的预期相符。在以非公平锁的方式获取锁，当一个线程在获取锁又释放锁，但又立即获取锁的时候，这个时候这个线程有很大的概率会成功（只是很大概率，试验结果也有可能不连续两次获取锁）。而公平锁则不一样，哪怕是同一个线程连续两次获取锁和释放锁，在第一次获取锁释放锁过后接着准备第二次获取锁时，这个时候当前线程会被加入到同步队列的队尾。

　　那么有了上面的结果除了说明非公平锁和公平锁之间的区别还能说明什么问题呢？其实，这就是本篇的主题——性能测试。非公平锁的一个线程连续两次获取锁和释放锁的工程中，是没有做上下文切换的，也就是一共只做了5次上下文切换。而公平锁实际上做了10次上下文切换。而这个上下文切换的开销实际是很大的，我们通过测试在10个线程，每个线程获取100000次锁的情况下两者的执行速度，以及使用vmstat命令来统计系统上下文切换的次数（cs栏表示系统每秒切换的上下文次数）。

package com.lock;

import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

/**
 * 改进后的代码，利用CyclicBarrier当所有线程执行完毕时，统计执行时间。
 * Created by yulinfeng on 5/24/17.
 */
public class newFairAndUnfairLockTest {
    private static Lock lock = new ReentrantLockMine(false);    //非公平锁
    //private static Lock lock = new ReentrantLockMine(true);   //公平锁

    public static void main(String[] args) throws BrokenBarrierException, InterruptedException {
        String lockType = "非公平锁";　　//String lockType = "公平锁"
        long start = System.currentTimeMillis();
        CyclicBarrier cyclicBarrier = new CyclicBarrier(10, new Time(lockType, start));     //10个线程执行完毕时，执行Time线程统计执行时间

        for (int i = 0; i < 10; i++) {
            Thread thread = new Thread(new Job(lock, cyclicBarrier)){
                public String toString() {
                    return getName();
                }
            };
            thread.setName("" + i);
            thread.start();
        }


    }

    private static class Job implements Runnable{
        private Lock lock;
        private CyclicBarrier cyclicBarrier;
        public Job(Lock lock, CyclicBarrier cyclicBarrier) {
            this.lock = lock;
            this.cyclicBarrier = cyclicBarrier;
        }

        public void run() {
            for (int i = 0; i < 100000; i++) {
                lock.lock();
                try {
                    System.out.println(i+"获取锁的当前线程[" + Thread.currentThread().getName() + "], 同步队列中的线程" + ((ReentrantLockMine)lock).getQueuedThreads() + "");
                } finally {
                    lock.unlock();
                }
            }
            try {
                cyclicBarrier.await();  //计数器+1，直到10个线程都到达
            } catch (InterruptedException e) {
                e.printStackTrace();
            } catch (BrokenBarrierException e) {
                e.printStackTrace();
            }
        }
    }

    private static class ReentrantLockMine extends ReentrantLock {  //重新实现ReentrantLock类是为了重写getQueuedThreads方法，便于我们试验的观察
        public ReentrantLockMine(boolean fair) {
            super(fair);
        }

        @Override
        protected Collection<Thread> getQueuedThreads() {   //获取同步队列中的线程
            List<Thread> arrayList = new ArrayList<Thread>(super.getQueuedThreads());
            Collections.reverse(arrayList);
            return arrayList;
        }
    }


    private static class Time implements Runnable {     //用于统计时间
        private long start ;
        private String lockType;

        public Time(String lockType, long start) {
            this.start = start;
            this.lockType = lockType;
        }

        public void run() {
            System.out.println(lockType + "耗时:" + String.valueOf(System.currentTimeMillis() - start));
        }
    }
}

　　首先执行非公平锁，并使用"vmstat 1(每秒实时查看系统资源占用情况)"，结果如下：

　　

　　

　　再执行公平锁，并使用"vmstat 1(每秒实时查看系统资源占用情况)"，结果如下：　　

　　 

　　

　　通过上面的试验结果可以得出结论，非公平锁的性能因其系统上下文的切换较少，其性能一般要优于公平锁。