【試驗局】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(每秒實時查看系統資源占用情況)"，結果如下：　　

　　 

　　

　　通過上面的試驗結果可以得出結論，非公平鎖的性能因其系統上下文的切換較少，其性能一般要優於公平鎖。