ロックとsynchronizedの性能の比較

synchronizedは文法的には十分簡単であるが,JDK 5以前にはこの実装しか利用できなかったが,独占ロックであるため,
性能は高くないため、JDK 5以降はJNIによるより高度なロック実装が開始される.JDK 5のロックはインタフェースjavaです.util.concurrent.locks.Lock.またjava.util.concurrent.locks.ReadWriteLockは、読み書きが同時に可能なロックを提供しています.今日は、Lockとsynchronizedの性能を比較してみましょう.
//LOck実現のAtomicInteger

package juc.automic;

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
/**
 * Lock  AtomicInteger
 * @author donald
 * 2017 2 28 
 *  7:52:34
 */
public class AtomicIntegerWithLock {
	private int value;
	private Lock lock = new ReentrantLock();

	public AtomicIntegerWithLock() {
		super();
	}

	public AtomicIntegerWithLock(int value) {
		this.value = value;
	}

	public final int get() {
		lock.lock();
		try {
			return value;
		} finally {
			lock.unlock();
		}
	}

	public final void set(int newValue) {
		lock.lock();
		try {
			value = newValue;
		} finally {
			lock.unlock();
		}
	}

	public final int getAndSet(int newValue) {
		lock.lock();
		try {
			int ret = value;
			value = newValue;
			return ret;
		} finally {
			lock.unlock();
		}
	}

	public final boolean compareAndSet(int expect, int update) {
		lock.lock();
		try {
			if (value == expect) {
				value = update;
				return true;
			}
			return false;
		} finally {
			lock.unlock();
		}
	}

	public final int getAndIncrement() {
		lock.lock();
		try {
			return value++;
		} finally {
			lock.unlock();
		}
	}

	public final int getAndDecrement() {
		lock.lock();
		try {
			return value--;
		} finally {
			lock.unlock();
		}
	}

	public final int incrementAndGet() {
		lock.lock();
		try {
			return ++value;
		} finally {
			lock.unlock();
		}
	}

	public final int decrementAndGet() {
		lock.lock();
		try {
			return --value;
		} finally {
			lock.unlock();
		}
	}

	public String toString() {
		return Integer.toString(get());
	}

}

//主クラスのテスト

package juc.automic;


/**
 * Lock synchronized 
 * @author donald
 * 2017 2 28 
 *  7:53:04
 */
public class LockCompareSynchronize {
	static int staticValue = 0;

	public static void main(String[] args) throws Exception {
		final int max = 10;
		final int loopCount = 100000;
		long costTime = 0;
		for (int m = 0; m < max; m++) {
			long start0 = System.nanoTime();
			final AtomicIntegerWithLock value1 = new AtomicIntegerWithLock(0);
			Thread[] ts = new Thread[max];
			for (int i = 0; i < max; i++) {
				ts[i] = new Thread() {
					public void run() {
						for (int i = 0; i < loopCount; i++) {
							value1.incrementAndGet();
						}
					}
				};
			}
			for (Thread t : ts) {
				t.start();
			}
			for (Thread t : ts) {
				t.join();
			}
			long end0 = System.nanoTime();
			costTime += (end0 - start0);
		}
		System.out.println("Lock : " + (costTime));
		System.out.println();
		costTime = 0;

		final Object lock = new Object();
		for (int m = 0; m < max; m++) {
			staticValue = 0;
			long start1 = System.nanoTime();
			Thread[] ts = new Thread[max];
			for (int i = 0; i < max; i++) {
				ts[i] = new Thread() {
					public void run() {
						for (int i = 0; i < loopCount; i++) {
							synchronized (lock) {
								++staticValue;
							}
						}
					}
				};
			}
			for (Thread t : ts) {
				t.start();
			}
			for (Thread t : ts) {
				t.join();
			}
			long end1 = System.nanoTime();
			costTime += (end1 - start1);
		}
		System.out.println("synchronized : " + (costTime));
	}

}

コンソール出力:
ロック所要時間:343165627
synchronized所要時間:436721381
上記の例は非常に正式なテスト例ではありませんが、上記の例は、ロックの性能がsynchronizedよりずっと優れていることを示しています.できればsynchronizedの代わりにロックを使うのが賢明です.
ReentrantLockを見てみましょう
//ReentrantLock

public class ReentrantLock implements Lock, java.io.Serializable {
    private static final long serialVersionUID = 7373984872572414699L;
    // 
    /** Synchronizer providing all implementation mechanics */
    private final Sync sync;
    abstract static class Sync extends AbstractQueuedSynchronizer {
     }
}

//ロックの作成

  public ReentrantLock() {
        sync = new NonfairSync();
    }

//非公平ロック、ReentrantLockの内部クラスNonfairSync

/**
     * Sync object for non-fair locks
     */
    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;

        /**
         * 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);
        }
	// 
        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
    }

ロックの方法を見てみましょう
//AbstractQueuedSynchronizer

public abstract class AbstractQueuedSynchronizer
    extends AbstractOwnableSynchronizer
    implements java.io.Serializable {
  protected final boolean compareAndSetState(int expect, int update) {
        // See below for intrinsics setup to support this
	// unsafe 
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
    }
}

//フェアロックの作成:

 /**
     * Creates an instance of {@code ReentrantLock} with the
     * given fairness policy.
     *
     * @param fair {@code true} if this lock should use a fair ordering policy
     */
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    } 

//フェアロック

static final class FairSync extends Sync {
        private static final long serialVersionUID = -3000897897090466540L;

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

        /**
         * Fair version of tryAcquire.  Don't grant access unless
         * recursive call or no waiters or is first.
         */
        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }

//AbstractOwnableSynchronizer

public abstract class AbstractOwnableSynchronizer
    implements java.io.Serializable {

    /** Use serial ID even though all fields transient. */
    private static final long serialVersionUID = 3737899427754241961L;

    /**
     * Empty constructor for use by subclasses.
     */
    protected AbstractOwnableSynchronizer() { }

    /**
     * The current owner of exclusive mode synchronization.
     */
    private transient Thread exclusiveOwnerThread;

    /**
     * Sets the thread that currently owns exclusive access. A
     * null argument indicates that no thread owns access.
     * This method does not otherwise impose any synchronization or
     * volatile field accesses.
     */
    protected final void setExclusiveOwnerThread(Thread t) {
        exclusiveOwnerThread = t;
    }

    /**
     * Returns the thread last set by
     * setExclusiveOwnerThread, or null if never
     * set.  This method does not otherwise impose any synchronization
     * or volatile field accesses.
     * @return the owner thread
     */
    protected final Thread getExclusiveOwnerThread() {
        return exclusiveOwnerThread;
    }
}

[color=green]公平なロックでは、スレッドは要求された順序でロックを取得しますが、非公平なロックでは「割り込み」を許可します.
1つのスレッドがフェアロックを要求すると、要求が発行されると同時にロックが使用可能になると、このスレッドはキュー内のすべての待機スレッドをスキップしてロックを取得します.
非公平なReentrantLockは割り込み行為を提唱していないが、あるスレッドが適切な時に割り込むことを防止することはできない.
公平なロックでは、別のスレッドがロックを持っているか、他のスレッドが待機キューで待機している場合、
新しいリクエストのスレッドがキューに格納されます.フェアロックではなく、ロックがスレッドによって保持されている場合にのみ、新しく要求されたスレッドがキューに格納されます.
フェアロック性能がフェアロック性能より高い理由:
保留中のスレッドを復元するのに深刻な遅延があります.
スレッドAがロックを持っており、スレッドBがこのロックを要求していると仮定する.ロックはAに保持されているので、Bは掛けられます.Aがロックを解除すると、Bが起動するので、Bは再びこのロックを取得しようとします.同時に、スレッドCがこのロックを要求する場合、Cは、Bが完全に起動される前に、このロックを取得し、使用し、解放する可能性が高い.これはウィンウィンの局面である:Bがロックを獲得する時刻は延期されず、Cがより早くロックを獲得し、スループットも向上した.ロックを保持する時間が比較的長い場合、またはロックを要求する平均時間間隔が長い場合は、フェアロックを使用する必要があります.これらの場合、割り込みによるスループットの向上(ロックが使用可能な状態にあるにもかかわらず、スレッドが起動中である)は発生しない可能性があります.[/color]