多線程開發關鍵技術

時間  2019-11-07
標籤 多線程 開發 關鍵 技術 欄目 Java 简体版
原文   原文鏈接

sleep和wait到底什麼區別

其實這個問題應該這麼問——sleep和wait有什麼相同點。由於這兩個方法除了都能讓當前線程暫停執行完，幾乎沒有其它相同點。java

wait方法是Object類的方法，這意味着全部的Java類均可以調用該方法。sleep方法是Thread類的靜態方法。安全

wait是在當前線程持有wait對象鎖的狀況下，暫時放棄鎖，並讓出CPU資源，並積極等待其它線程調用同一對象的notify或者notifyAll方法。注意，即便只有一個線程在等待，而且有其它線程調用了notify或者notifyAll方法，等待的線程只是被激活，可是它必須得再次得到鎖才能繼續往下執行。換言之，即便notify被調用，但只要鎖沒有被釋放，原等待線程由於未得到鎖仍然沒法繼續執行。測試代碼以下所示bash

import java.util.Date;

public class Wait {

  public static void main(String[] args) {
    Thread thread1 = new Thread(() -> {
      synchronized (Wait.class) {
        try {
          System.out.println(new Date() + " Thread1 is running");
          Wait.class.wait();
          System.out.println(new Date() + " Thread1 ended");
        } catch (Exception ex) {
          ex.printStackTrace();
        }
      }
    });
    thread1.start();
    
    Thread thread2 = new Thread(() -> {
      synchronized (Wait.class) {
        try {
          System.out.println(new Date() + " Thread2 is running");
          Wait.class.notify();
          // Don't use sleep method to avoid confusing
          for(long i = 0; i < 200000; i++) {
            for(long j = 0; j < 100000; j++) {}
          }
          System.out.println(new Date() + " Thread2 release lock");
        } catch (Exception ex) {
          ex.printStackTrace();
        }
      }
      
      for(long i = 0; i < 200000; i++) {
        for(long j = 0; j < 100000; j++) {}
      }
      System.out.println(new Date() + " Thread2 ended");
    });
    
    // Don't use sleep method to avoid confusing
    for(long i = 0; i < 200000; i++) {
      for(long j = 0; j < 100000; j++) {}
    }
    thread2.start();
  }
}

執行結果以下多線程

Tue Jun 14 22:51:11 CST 2016 Thread1 is running
Tue Jun 14 22:51:23 CST 2016 Thread2 is running
Tue Jun 14 22:51:36 CST 2016 Thread2 release lock
Tue Jun 14 22:51:36 CST 2016 Thread1 ended
Tue Jun 14 22:51:49 CST 2016 Thread2 ended

從運行結果能夠看出併發

  • thread1執行wait後，暫停執行
  • thread2執行notify後，thread1並無繼續執行，由於此時thread2還沒有釋放鎖，thread1由於得不到鎖而不能繼續執行
  • thread2執行完synchronized語句塊後釋放鎖，thread1獲得通知並得到鎖，進而繼續執行

注意：wait方法須要釋放鎖，前提條件是它已經持有鎖。因此wait和notify（或者notifyAll）方法都必須被包裹在synchronized語句塊中，而且synchronized後鎖的對象應該與調用wait方法的對象同樣。不然拋出IllegalMonitorStateException性能

sleep方法告訴操做系統至少指定時間內不需爲線程調度器爲該線程分配執行時間片，並不釋放鎖（若是當前已經持有鎖）。實際上，調用sleep方法時並不要求持有任何鎖。測試

package com.test.thread;

import java.util.Date;

public class Sleep {

  public static void main(String[] args) {
    Thread thread1 = new Thread(() -> {
      synchronized (Sleep.class) {
        try {
          System.out.println(new Date() + " Thread1 is running");
          Thread.sleep(2000);
          System.out.println(new Date() + " Thread1 ended");
        } catch (Exception ex) {
          ex.printStackTrace();
        }
      }
    });
    thread1.start();
    
    Thread thread2 = new Thread(() -> {
      synchronized (Sleep.class) {
        try {
          System.out.println(new Date() + " Thread2 is running");
          Thread.sleep(2000);
          System.out.println(new Date() + " Thread2 ended");
        } catch (Exception ex) {
          ex.printStackTrace();
        }
      }
      
      for(long i = 0; i < 200000; i++) {
        for(long j = 0; j < 100000; j++) {}
      }
    });
    
    // Don't use sleep method to avoid confusing
    for(long i = 0; i < 200000; i++) {
      for(long j = 0; j < 100000; j++) {}
    }
    thread2.start();
  }
}

執行結果以下ui

Thu Jun 16 19:46:06 CST 2016 Thread1 is running
Thu Jun 16 19:46:08 CST 2016 Thread1 ended
Thu Jun 16 19:46:13 CST 2016 Thread2 is running
Thu Jun 16 19:46:15 CST 2016 Thread2 ended

因爲thread 1和thread 2的run方法實現都在同步塊中，不管哪一個線程先拿到鎖，執行sleep時並不釋放鎖，所以其它線程沒法執行。直到前面的線程sleep結束並退出同步塊（釋放鎖），另外一個線程才獲得鎖並執行。spa

注意：sleep方法並不須要持有任何形式的鎖，也就不須要包裹在synchronized中。操作系統

synchronized幾種用法

每一個Java對象均可以用作一個實現同步的互斥鎖，這些鎖被稱爲內置鎖。線程進入同步代碼塊或方法時自動得到內置鎖，退出同步代碼塊或方法時自動釋放該內置鎖。進入同步代碼塊或者同步方法是得到內置鎖的惟一途徑。

實例同步方法

synchronized用於修飾實例方法（非靜態方法）時，執行該方法須要得到的是該類實例對象的內置鎖（同一個類的不一樣實例擁有不一樣的內置鎖）。若是多個實例方法都被synchronized修飾，則當多個線程調用同一實例的不一樣同步方法（或者同一方法）時，須要競爭鎖。但當調用的是不一樣實例的方法時，並不須要競爭鎖。

靜態同步方法

synchronized用於修飾靜態方法時，執行該方法須要得到的是該類的class對象的內置鎖（一個類只有惟一一個class對象）。調用同一個類的不一樣靜態同步方法時會產生鎖競爭。

同步代碼塊

synchronized用於修飾代碼塊時，進入同步代碼塊須要得到synchronized關鍵字後面括號內的對象（能夠是實例對象也能夠是class對象）的內置鎖。

synchronized使用總結

鎖的使用是爲了操做臨界資源的正確性，而每每一個方法中並不是全部的代碼都操做臨界資源。換句話說，方法中的代碼每每並不都須要同步。此時建議不使用同步方法，而使用同步代碼塊，只對操做臨界資源的代碼，也即須要同步的代碼加鎖。這樣作的好處是，當一個線程在執行同步代碼塊時，其它線程仍然能夠執行該方法內同步代碼塊之外的部分，充分發揮多線程併發的優點，從而相較於同步整個方法而言提高性能。

釋放Java內置鎖的惟一方式是synchronized方法或者代碼塊執行結束。若某一線程在synchronized方法或代碼塊內發生死鎖，則對應的內置鎖沒法釋放，其它線程也沒法獲取該內置鎖（即進入跟該內置鎖相關的synchronized方法或者代碼塊）。

Java中的鎖

重入鎖

Java中的重入鎖（即ReentrantLock）與Java內置鎖同樣，是一種排它鎖。使用synchronized的地方必定能夠用ReentrantLock代替。

重入鎖須要顯示請求獲取鎖，並顯示釋放鎖。爲了不得到鎖後，沒有釋放鎖，而形成其它線程沒法得到鎖而形成死鎖，通常建議將釋放鎖操做放在finally塊裏，以下所示。

try{
  renentrantLock.lock();
  // 用戶操做
} finally {
  renentrantLock.unlock();
}

若是重入鎖已經被其它線程持有，則當前線程的lock操做會被阻塞。除了lock()方法以外，重入鎖（或者說鎖接口）還提供了其它獲取鎖的方法以實現不一樣的效果。

  • lockInterruptibly() 該方法嘗試獲取鎖，若獲取成功當即返回；若獲取不成功則阻塞等待。與lock方法不一樣的是，在阻塞期間，若是當前線程被打斷（interrupt）則該方法拋出InterruptedException。該方法提供了一種解除死鎖的途徑。
  • tryLock() 該方法試圖獲取鎖，若該鎖當前可用，則該方法當即得到鎖並當即返回true；若鎖當前不可用，則當即返回false。該方法不會阻塞，並提供給用戶對於成功獲利鎖與獲取鎖失敗進行不一樣操做的可能性。
  • tryLock(long time, TimeUnit unit) 該方法試圖得到鎖，若該鎖當前可用，則當即得到鎖並當即返回true。若鎖當前不可用，則等待相應的時間（由該方法的兩個參數決定）：1）若該時間內鎖可用，則得到鎖，並返回true；2）若等待期間當前線程被打斷，則拋出InterruptedException；3）若等待時間結束仍未得到鎖，則返回false。

重入鎖可定義爲公平鎖或非公平鎖，默認實現爲非公平鎖。

  • 公平鎖是指多個線程獲取鎖被阻塞的狀況下，鎖變爲可用時，最新申請鎖的線程得到鎖。可經過在重入鎖（RenentrantLock）的構造方法中傳入true構建公平鎖，如Lock lock = new RenentrantLock(true)
  • 非公平鎖是指多個線程等待鎖的狀況下，鎖變爲可用狀態時，哪一個線程得到鎖是隨機的。synchonized至關於非公平鎖。可經過在重入鎖的構造方法中傳入false或者使用無參構造方法構建非公平鎖。

讀寫鎖

如上文《Java進階（二）當咱們說線程安全時，到底在說什麼》所述，鎖能夠保證原子性和可見性。而原子性更可能是針對寫操做而言。對於讀多寫少的場景，一個讀操做無須阻塞其它讀操做，只須要保證讀和寫或者寫與寫不一樣時發生便可。此時，若是使用重入鎖（即排它鎖），對性能影響較大。Java中的讀寫鎖（ReadWriteLock）就是爲這種讀多寫少的場景而創造的。

實際上，ReadWriteLock接口並不是繼承自Lock接口，ReentrantReadWriteLock也只實現了ReadWriteLock接口而未實現Lock接口。ReadLock和WriteLock，是ReentrantReadWriteLock類的靜態內部類，它們實現了Lock接口。

一個ReentrantReadWriteLock實例包含一個ReentrantReadWriteLock.ReadLock實例和一個ReentrantReadWriteLock.WriteLock實例。經過readLock()和writeLock()方法可分別得到讀鎖實例和寫鎖實例，並經過Lock接口提供的獲取鎖方法得到對應的鎖。

讀寫鎖的鎖定規則以下：

  • 得到讀鎖後，其它線程可得到讀鎖而不能獲取寫鎖
  • 得到寫鎖後，其它線程既不能得到讀鎖也不能得到寫鎖
package com.test.thread;

import java.util.Date;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

public class ReadWriteLockDemo {

  public static void main(String[] args) {
    ReadWriteLock readWriteLock = new ReentrantReadWriteLock();

    new Thread(() -> {
      readWriteLock.readLock().lock();
      try {
        System.out.println(new Date() + "\tThread 1 started with read lock");
        try {
          Thread.sleep(2000);
        } catch (Exception ex) {
        }
        System.out.println(new Date() + "\tThread 1 ended");
      } finally {
        readWriteLock.readLock().unlock();
      }
    }).start();

    new Thread(() -> {
      readWriteLock.readLock().lock();
      try {
        System.out.println(new Date() + "\tThread 2 started with read lock");
        try {
          Thread.sleep(2000);
        } catch (Exception ex) {
        }
        System.out.println(new Date() + "\tThread 2 ended");
      } finally {
        readWriteLock.readLock().unlock();
      }
    }).start();

    new Thread(() -> {
      Lock lock = readWriteLock.writeLock();
      lock.lock();
      try {
        System.out.println(new Date() + "\tThread 3 started with write lock");
        try {
          Thread.sleep(2000);
        } catch (Exception ex) {
          ex.printStackTrace();
        }
        System.out.println(new Date() + "\tThread 3 ended");
      } finally {
        lock.unlock();
      }
    }).start();
  }
}

執行結果以下

Sat Jun 18 21:33:46 CST 2016  Thread 1 started with read lock
Sat Jun 18 21:33:46 CST 2016  Thread 2 started with read lock
Sat Jun 18 21:33:48 CST 2016  Thread 2 ended
Sat Jun 18 21:33:48 CST 2016  Thread 1 ended
Sat Jun 18 21:33:48 CST 2016  Thread 3 started with write lock
Sat Jun 18 21:33:50 CST 2016  Thread 3 ended

從上面的執行結果可見，thread 1和thread 2都只需得到讀鎖，所以它們能夠並行執行。而thread 3由於須要獲取寫鎖，必須等到thread 1和thread 2釋放鎖後才能得到鎖。

條件鎖

條件鎖只是一個幫助用戶理解的概念，實際上並無條件鎖這種鎖。對於每一個重入鎖，均可以經過newCondition()方法綁定若干個條件對象。

條件對象提供如下方法以實現不一樣的等待語義

  • await() 調用該方法的前提是，當前線程已經成功得到與該條件對象綁定的重入鎖，不然調用該方法時會拋出IllegalMonitorStateException。調用該方法外，當前線程會釋放當前已經得到的鎖（這一點與上文講述的Java內置鎖的wait方法一致），而且等待其它線程調用該條件對象的signal()或者signalAll()方法（這一點與Java內置鎖wait後等待notify()或notifyAll()很像）。或者在等待期間，當前線程被打斷，則wait()方法會拋出InterruptedException並清除當前線程的打斷狀態。
  • await(long time, TimeUnit unit) 適用條件和行爲與await()基本一致，惟一不一樣點在於，指定時間以內沒有收到signal()或signalALL()信號或者線程中斷時該方法會返回false;其它狀況返回true。
  • awaitNanos(long nanosTimeout) 調用該方法的前提是，當前線程已經成功得到與該條件對象綁定的重入鎖，不然調用該方法時會拋出IllegalMonitorStateException。nanosTimeout指定該方法等待信號的的最大時間（單位爲納秒）。若指定時間內收到signal()或signalALL()則返回nanosTimeout減去已經等待的時間；若指定時間內有其它線程中斷該線程，則拋出InterruptedException並清除當前線程的打斷狀態；若指定時間內未收到通知，則返回0或負數。
  • awaitUninterruptibly() 調用該方法的前提是，當前線程已經成功得到與該條件對象綁定的重入鎖，不然調用該方法時會拋出IllegalMonitorStateException。調用該方法後，結束等待的惟一方法是其它線程調用該條件對象的signal()或signalALL()方法。等待過程當中若是當前線程被中斷，該方法仍然會繼續等待，同時保留該線程的中斷狀態。
  • awaitUntil(Date deadline) 適用條件與行爲與awaitNanos(long nanosTimeout)徹底同樣，惟一不一樣點在於它不是等待指定時間，而是等待由參數指定的某一時刻。

調用條件等待的注意事項

  • 調用上述任意條件等待方法的前提都是當前線程已經得到與該條件對象對應的重入鎖。
  • 調用條件等待後，當前線程讓出CPU資源。
  • 上述等待方法結束後，方法返回的前提是它能從新得到與該條件對象對應的重入鎖。若是沒法得到鎖，仍然會繼續等待。這也是awaitNanos(long nanosTimeout)可能會返回負值的緣由。
  • 一旦條件等待方法返回，則當前線程確定已經得到了對應的重入鎖。
  • 重入鎖能夠建立若干個條件對象，signal()和signalAll()方法只能喚醒相同條件對象的等待。
  • 一個重入鎖上能夠生成多個條件變量，不一樣線程能夠等待不一樣的條件，從而實現更加細粒度的的線程間通訊。

signal()與signalAll()

  • signal() 如有一個或若干個線程在等待該條件變量，則該方法會喚醒其中的一個（具體哪個，沒法預測）。調用該方法的前提是當前線程持有該條件變量對應的鎖，不然拋出IllegalMonitorStateException。
  • signalALL() 如有一個或若干個線程在等待該條件變量，則該方法會喚醒全部等待。調用該方法的前提是當前線程持有該條件變量對應的鎖，不然拋出IllegalMonitorStateException。
package com.test.thread;

import java.util.Date;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class ConditionTest {

  public static void main(String[] args) throws InterruptedException {
    Lock lock = new ReentrantLock();
    Condition condition = lock.newCondition();
    new Thread(() -> {
      lock.lock();
      try {
        System.out.println(new Date() + "\tThread 1 is waiting");
        try {
          long waitTime = condition.awaitNanos(TimeUnit.SECONDS.toNanos(2));
          System.out.println(new Date() + "\tThread 1 remaining time " + waitTime);
        } catch (Exception ex) {
          ex.printStackTrace();
        }
        System.out.println(new Date() + "\tThread 1 is waken up");
      } finally {
        lock.unlock();
      }
    }).start();
    
    new Thread(() -> {
      lock.lock();
      try{
        System.out.println(new Date() + "\tThread 2 is running");
        try {
          Thread.sleep(4000);
        } catch (Exception ex) {
          ex.printStackTrace();
        }
        condition.signal();
        System.out.println(new Date() + "\tThread 2 ended");
      } finally {
        lock.unlock();
      }
    }).start();
  }
}

執行結果以下

Sun Jun 19 15:59:09 CST 2016  Thread 1 is waiting
Sun Jun 19 15:59:09 CST 2016  Thread 2 is running
Sun Jun 19 15:59:13 CST 2016  Thread 2 ended
Sun Jun 19 15:59:13 CST 2016  Thread 1 remaining time -2003467560
Sun Jun 19 15:59:13 CST 2016  Thread 1 is waken up

從執行結果能夠看出，雖然thread 2一開始就調用了signal()方法去喚醒thread 1，可是由於thread 2在4秒鐘後才釋放鎖，也即thread 1在4秒後纔得到鎖，因此thread 1的await方法在4秒鐘後才返回，而且返回負值。

信號量Semaphore

信號量維護一個許可集，可經過acquire()獲取許可（若無可用許可則阻塞），經過release()釋放許可，從而可能喚醒一個阻塞等待許可的線程。

與互斥鎖相似，信號量限制了同一時間訪問臨界資源的線程的個數，而且信號量也分公平信號量與非公平信號量。而不一樣的是，互斥鎖保證同一時間只會有一個線程訪問臨界資源，而信號量能夠容許同一時間多個線程訪問特定資源。因此信號量並不能保證原子性。

信號量的一個典型使用場景是限制系統訪問量。每一個請求進來後，處理以前都經過acquire獲取許可，若獲取許可成功則處理該請求，若獲取失敗則等待處理或者直接不處理該請求。

信號量的使用方法

  • acquire(int permits) 申請permits（必須爲非負數）個許可，若獲取成功，則該方法返回而且當前可用許可數減permits；若當前可用許可數少於permits指定的個數，則繼續等待可用許可數大於等於permits；若等待過程當中當前線程被中斷，則拋出InterruptedException。
  • acquire() 等價於acquire(1)。
  • acquireUninterruptibly(int permits) 申請permits（必須爲非負數）個許可，若獲取成功，則該方法返回而且當前可用許可數減permits；若當前許可數少於permits，則繼續等待可用許可數大於等於permits；若等待過程當中當前線程被中斷，繼續等待可用許可數大於等於permits，而且獲取成功後設置線程中斷狀態。
  • acquireUninterruptibly() 等價於acquireUninterruptibly(1)。
  • drainPermits() 獲取全部可用許可，並返回獲取到的許可個數，該方法不阻塞。
  • tryAcquire(int permits) 嘗試獲取permits個可用許可，若是當前許可個數大於等於permits，則返回true而且可用許可數減permits；不然返回false而且可用許可數不變。
  • tryAcquire() 等價於tryAcquire(1)。
  • tryAcquire(int permits, long timeout, TimeUnit unit) 嘗試獲取permits（必須爲非負數）個許可，若在指定時間內獲取成功則返回true而且可用許可數減permits；若指定時間內當前線程被中斷，則拋出InterruptedException；若指定時間內可用許可數均小於permits，則返回false。
  • tryAcquire(long timeout, TimeUnit unit) 等價於tryAcquire(1, long timeout, TimeUnit unit)*
  • release(int permits) 釋放permits個許可，該方法不阻塞而且某線程調用release方法前並不須要先調用acquire方法。
  • release() 等價於release(1)。

注意：與wait/notify和await/signal不一樣，acquire/release徹底與鎖無關，所以acquire等待過程當中，可用許可知足要求時acquire可當即返回，而不用像鎖的wait和條件變量的await那樣從新獲取鎖才能返回。或者能夠理解成，只要可用許可知足需求，就已經得到了鎖。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程