深入研究 Java Synchronize 和 Lock 的區別與用法

在分布式開發中，鎖是線程控制的重要途徑。Java為此也提供了2種鎖機制，synchronized和lock。做為Java愛好者，自然少不了對比一下這2種機制，也能從中學到些分布式開發需要注意的地方。
 
我們先從最簡單的入手，逐步分析這2種的區別。
 
一、synchronized和lock的用法區別
 
synchronized：在需要同步的對象中加入此控制，synchronized可以加在方法上，也可以加在特定代碼塊中，括號中表示需要鎖的對象。
 
lock：需要顯示指定起始位置和終止位置。一般使用ReentrantLock類做為鎖，多個線程中必須要使用一個ReentrantLock類做為對象才能保證鎖的生效。且在加鎖和解鎖處需要通過lock()和unlock()顯示指出。所以一般會在finally塊中寫unlock()以防死鎖。
 
用法區別比較簡單，這里不贅述了，如果不懂的可以看看Java基本語法。
 
二、synchronized和lock性能區別
 
synchronized是托管給JVM執行的，而lock是java寫的控制鎖的代碼。在Java1.5中，synchronize是性能低效的。因為這是一個重量級操作，需要調用操作接口，導致有可能加鎖消耗的系統時間比加鎖以外的操作還多。相比之下使用Java提供的Lock對象，性能更高一些。但是到了Java1.6，發生了變化。synchronize在語義上很清晰，可以進行很多優化，有適應自旋，鎖消除，鎖粗化，輕量級鎖，偏向鎖等等。導致在Java1.6上synchronize的性能並不比Lock差。官方也表示，他們也更支持synchronize，在未來的版本中還有優化余地。
 
說到這里，還是想提一下這2中機制的具體區別。據我所知，synchronized原始采用的是CPU悲觀鎖機制，即線程獲得的是獨占鎖。獨占鎖意味着其他線程只能依靠阻塞來等待線程釋放鎖。而在CPU轉換線程阻塞時會引起線程上下文切換，當有很多線程競爭鎖的時候，會引起CPU頻繁的上下文切換導致效率很低。
 
而Lock用的是樂觀鎖方式。所謂樂觀鎖就是，每次不加鎖而是假設沒有沖突而去完成某項操作，如果因為沖突失敗就重試，直到成功為止。樂觀鎖實現的機制就是CAS操作（Compare and Swap）。我們可以進一步研究ReentrantLock的源代碼，會發現其中比較重要的獲得鎖的一個方法是compareAndSetState。這里其實就是調用的CPU提供的特殊指令。
 
現代的CPU提供了指令，可以自動更新共享數據，而且能夠檢測到其他線程的干擾，而 compareAndSet() 就用這些代替了鎖定。這個算法稱作非阻塞算法，意思是一個線程的失敗或者掛起不應該影響其他線程的失敗或掛起的算法。
 
我也只是了解到這一步，具體到CPU的算法如果感興趣的讀者還可以在查閱下，如果有更好的解釋也可以給我留言，我也學習下。
 
三、synchronized和lock用途區別
 
synchronized原語和ReentrantLock在一般情況下沒有什么區別，但是在非常復雜的同步應用中，請考慮使用ReentrantLock，特別是遇到下面2種需求的時候。
 
1.某個線程在等待一個鎖的控制權的這段時間需要中斷
2.需要分開處理一些wait-notify，ReentrantLock里面的Condition應用，能夠控制notify哪個線程
3.具有公平鎖功能，每個到來的線程都將排隊等候
 
下面細細道來……
 
先說第一種情況，ReentrantLock的lock機制有2種，忽略中斷鎖和響應中斷鎖，這給我們帶來了很大的靈活性。比如：如果A、B2個線程去競爭鎖，A線程得到了鎖，B線程等待，但是A線程這個時候實在有太多事情要處理，就是一直不返回，B線程可能就會等不及了，想中斷自己，不再等待這個鎖了，轉而處理其他事情。這個時候ReentrantLock就提供了2種機制，第一，B線程中斷自己（或者別的線程中斷它），但是ReentrantLock不去響應，繼續讓B線程等待，你再怎么中斷，我全當耳邊風（synchronized原語就是如此）；第二，B線程中斷自己（或者別的線程中斷它），ReentrantLock處理了這個中斷，並且不再等待這個鎖的到來，完全放棄。（如果你沒有了解java的中斷機制，請參考下相關資料，再回頭看這篇文章，80%的人根本沒有真正理解什么是java的中斷，呵呵）
 
這里來做個試驗，首先搞一個Buffer類，它有讀操作和寫操作，為了不讀到臟數據，寫和讀都需要加鎖，我們先用synchronized原語來加鎖，如下：

 

public class Buffer {   
    private Object lock;   
    public Buffer() {
        lock = this;
    }   
    public void write() {
        synchronized (lock) {
            long startTime = System.currentTimeMillis();
            System.out.println("開始往這個buff寫入數據…");
            for (;;)// 模擬要處理很長時間
            {
                if (System.currentTimeMillis()
                        - startTime > Integer.MAX_VALUE)
                    break;
            }
            System.out.println("終於寫完了");
        }
    }   

    public void read() {
   synchronized (lock) {
            System.out.println("從這個buff讀數據");
        }
    }
}

接着，我們來定義2個線程，一個線程去寫，一個線程去讀。

public class Writer extends Thread {   
    private Buffer buff;   
    public Writer(Buffer buff) {
        this.buff = buff;
    }   

    @Override
    public void run() {
   buff.write();
    }   
}   

public class Reader extends Thread {   
    private Buffer buff;   
    public Reader(Buffer buff) {
        this.buff = buff;
    }   

    @Override
    public void run() {   
        buff.read();//這里估計會一直阻塞   
        System.out.println("讀結束");   

    }   

}

 

好了，寫一個Main來試驗下，我們有意先去“寫”，然后讓“讀”等待，“寫”的時間是無窮的，就看“讀”能不能放棄了。

public class Test {
    public static void main(String[] args) {
        Buffer buff = new Buffer();   
        final Writer writer = new Writer(buff);
        final Reader reader = new Reader(buff);   
        writer.start();
        reader.start();   
        new Thread(new Runnable() {   
            @Override
            public void run() {
                long start = System.currentTimeMillis();
                for (;;) {
                    //等5秒鍾去中斷讀
                    if (System.currentTimeMillis()
                            - start > 5000) {
                        System.out.println("不等了，嘗試中斷");
                        reader.interrupt();
                        break;
                    }   
                }   
            }
        }).start();   

    }
}

 

我們期待“讀”這個線程能退出等待鎖，可是事與願違，一旦讀這個線程發現自己得不到鎖，就一直開始等待了，就算它等死，也得不到鎖，因為寫線程要21億秒才能完成 T_T ，即使我們中斷它，它都不來響應下，看來真的要等死了。這個時候，ReentrantLock給了一種機制讓我們來響應中斷，讓“讀”能伸能屈，勇敢放棄對這個鎖的等待。我們來改寫Buffer這個類，就叫BufferInterruptibly吧，可中斷緩存。

import java.util.concurrent.locks.ReentrantLock;   
public class BufferInterruptibly {   
    private ReentrantLock lock = new ReentrantLock();   
    public void write() {
        lock.lock();
        try {
            long startTime = System.currentTimeMillis();
            System.out.println("開始往這個buff寫入數據…");
            for (;;)// 模擬要處理很長時間
            {
                if (System.currentTimeMillis()
                        - startTime > Integer.MAX_VALUE)
                    break;
            }
            System.out.println("終於寫完了");
        } finally {
            lock.unlock();
        }
    }   

    public void read() throws InterruptedException {
        lock.lockInterruptibly();// 注意這里，可以響應中斷
        try {
            System.out.println("從這個buff讀數據");
        } finally {
            lock.unlock();
        }
    }   
}

當然，要對reader和writer做響應的修改

public class Reader extends Thread {   
    private BufferInterruptibly buff;   
    public Reader(BufferInterruptibly buff) {
        this.buff = buff;
    }   

    @Override
    public void run() {   
        try {
            buff.read();//可以收到中斷的異常，從而有效退出
        } catch (InterruptedException e) {
            System.out.println("我不讀了");
        }   
        System.out.println("讀結束");   
    }   
}   

/*** Writer倒不用怎么改動*/
public class Writer extends Thread {   
    private BufferInterruptibly buff;   
    public Writer(BufferInterruptibly buff) {
        this.buff = buff;
    }   

    @Override
    public void run() {
        buff.write();
    }   
}   

public class Test {
    public static void main(String[] args) {
        BufferInterruptibly buff = new BufferInterruptibly();   
        final Writer writer = new Writer(buff);
        final Reader reader = new Reader(buff);   
        writer.start();
        reader.start();   

        new Thread(new Runnable() {   

            @Override
            public void run() {
                long start = System.currentTimeMillis();
                for (;;) {
                    if (System.currentTimeMillis()
                            - start > 5000) {
                        System.out.println("不等了，嘗試中斷");
                        reader.interrupt();
                        break;
                    }   
                }   
            }
        }).start();   
    }
}

 

這次“讀”線程接收到了lock.lockInterruptibly()中斷，並且有效處理了這個“異常”。

 

 

 

至於第二種情況，ReentrantLock可以與Condition的配合使用，Condition為ReentrantLock鎖的等待和釋放提供控制邏輯。
 
例如，使用ReentrantLock加鎖之后，可以通過它自身的Condition.await()方法釋放該鎖，線程在此等待Condition.signal()方法，然后繼續執行下去。await方法需要放在while循環中，因此，在不同線程之間實現並發控制，還需要一個volatile的變量，boolean是原子性的變量。因此，一般的並發控制的操作邏輯如下所示：

volatile boolean isProcess = false;
ReentrantLock lock  = new ReentrantLock();
Condtion processReady = lock.newCondtion();
thread: run() {
    lock.lock();
    isProcess = true;
   try {
    while(!isProcessReady) {  //isProcessReady 是另外一個線程的控制變量
      processReady.await();//釋放了lock，在此等待signal
     }catch (InterruptedException e) {
          Thread.currentThread().interrupt();
        } finally {
          lock.unlock();
          isProcess = false;
        }
      }
    }
}

 

這里只是代碼使用的一段簡化，下面我們看Hadoop的一段摘取的源碼：

private class MapOutputBuffer<K extends Object, V extends Object>
      implements MapOutputCollector<K, V>, IndexedSortable {
...
    boolean spillInProgress;
    final ReentrantLock spillLock = new ReentrantLock();
    final Condition spillDone = spillLock.newCondition();
    final Condition spillReady = spillLock.newCondition();
    volatile boolean spillThreadRunning = false;
    final SpillThread spillThread = new SpillThread();
...
    public MapOutputBuffer(TaskUmbilicalProtocol umbilical, JobConf job,
                           TaskReporter reporter
                           ) throws IOException, ClassNotFoundException {
    ...
      spillInProgress = false;
      spillThread.setDaemon(true);
      spillThread.setName("SpillThread");
      spillLock.lock();
      try {
        spillThread.start();
        while (!spillThreadRunning) {
          spillDone.await();
        }
      } catch (InterruptedException e) {
        throw new IOException("Spill thread failed to initialize", e);
      } finally {
        spillLock.unlock();
      }
    }

    protected class SpillThread extends Thread {
      @Override
      public void run() {
        spillLock.lock();
        spillThreadRunning = true;
        try {
          while (true) {
            spillDone.signal();
            while (!spillInProgress) {
              spillReady.await();
            }
            try {
              spillLock.unlock();
              sortAndSpill();
            } catch (Throwable t) {
              sortSpillException = t;
            } finally {
              spillLock.lock();
              if (bufend < bufstart) {
                bufvoid = kvbuffer.length;
              }
              kvstart = kvend;
              bufstart = bufend;
              spillInProgress = false;
            }
          }
        } catch (InterruptedException e) {
          Thread.currentThread().interrupt();
        } finally {
          spillLock.unlock();
          spillThreadRunning = false;
        }
      }
    }

代碼中spillDone 就是 spillLock的一個newCondition()。調用spillDone.await()時可以釋放spillLock鎖，線程進入阻塞狀態，而等待其他線程的 spillDone.signal()操作時，就會喚醒線程，重新持有spillLock鎖。
 
這里可以看出，利用lock可以使我們多線程交互變得方便，而使用synchronized則無法做到這點。
 
最后呢，ReentrantLock這個類還提供了2種競爭鎖的機制：公平鎖和非公平鎖。這2種機制的意思從字面上也能了解個大概：即對於多線程來說，公平鎖會依賴線程進來的順序，后進來的線程后獲得鎖。而非公平鎖的意思就是后進來的鎖也可以和前邊等待鎖的線程同時競爭鎖資源。對於效率來講，當然是非公平鎖效率更高，因為公平鎖還要判斷是不是線程隊列的第一個才會讓線程獲得鎖。

 

原文地址：http://blog.csdn.net/natian306/article/details/18504111