Lock与synchronized 的区别
1、ReentrantLock 擁有Synchronized相同的并發性和內存語義，此外還多了 鎖投票，定時鎖等候和中斷鎖等候
線程A和B都要獲取對象O的鎖定，假設A獲取了對象O鎖，B將等待A釋放對O的鎖定，
如果使用 synchronized ，如果A不釋放，B將一直等下去，不能被中斷
如果 使用ReentrantLock，如果A不釋放，可以使B在等待了足夠長的時間以后，中斷等待，而干別的事情
ReentrantLock獲取鎖定與三種方式：
a) lock(), 如果獲取了鎖立即返回，如果別的線程持有鎖，當前線程則一直處于休眠狀態，直到獲取鎖
b) tryLock(), 如果獲取了鎖立即返回true，如果別的線程正持有鎖，立即返回false；
c)tryLock(long timeout,TimeUnit unit)， 如果獲取了鎖定立即返回true，如果別的線程正持有鎖，會等待參數給定的時間，在等待的過程中，如果獲取了鎖定，就返回true，如果等待超時，返回false；
d) lockInterruptibly:如果獲取了鎖定立即返回，如果沒有獲取鎖定，當前線程處于休眠狀態，直到或者鎖定，或者當前線程被別的線程中斷
2、synchronized是在JVM層面上實現的，不但可以通過一些監控工具監控synchronized的鎖定，而且在代碼執行時出現異常，JVM會自動釋放鎖定，但是使用Lock則不行，lock是通過代碼實現的，要保證鎖定一定會被釋放，就必須將unLock()放到finally{}中
3、在資源競爭不是很激烈的情況下，Synchronized的性能要優于ReetrantLock，但是在資源競爭很激烈的情況下，Synchronized的性能會下降幾十倍，但是ReetrantLock的性能能維持常態；
5.0的多線程任務包對于同步的性能方面有了很大的改進，在原有synchronized關鍵字的基礎上，又增加了ReentrantLock，以及各種Atomic類。了解其性能的優劣程度，有助與我們在特定的情形下做出正確的選擇。
總體的結論先擺出來：
synchronized：
在資源競爭不是很激烈的情況下，偶爾會有同步的情形下，synchronized是很合適的。原因在于，編譯程序通常會盡可能的進行優化synchronize，另外可讀性非常好，不管用沒用過5.0多線程包的程序員都能理解。
ReentrantLock:
ReentrantLock提供了多樣化的同步，比如有時間限制的同步，可以被Interrupt的同步（synchronized的同步是不能Interrupt的）等。在資源競爭不激烈的情形下，性能稍微比synchronized差點點。但是當同步非常激烈的時候，synchronized的性能一下子能下降好幾十倍。而ReentrantLock確還能維持常態。
Atomic:
和上面的類似，不激烈情況下，性能比synchronized略遜，而激烈的時候，也能維持常態。激烈的時候，Atomic的性能會優于ReentrantLock一倍左右。但是其有一個缺點，就是只能同步一個值，一段代碼中只能出現一個Atomic的變量，多于一個同步無效。因為他不能在多個Atomic之間同步。
所以，我們寫同步的時候，優先考慮synchronized，如果有特殊需要，再進一步優化。ReentrantLock和Atomic如果用的不好，不僅不能提高性能，還可能帶來災難。
先貼測試結果：再貼代碼（Atomic測試代碼不準確，一個同步中只能有1個Actomic，這里用了2個，但是這里的測試只看速度）
round:100000 thread:5
Sync = 35301694
Lock = 56255753
Atom = 43467535
round:200000 thread:10
Sync = 110514604
Lock = 204235455
Atom = 170535361
round:300000 thread:15
Sync = 253123791
Lock = 448577123
Atom = 362797227
round:400000 thread:20
Sync = 16562148262
Lock = 846454786
Atom = 667947183
round:500000 thread:25
Sync = 26932301731
Lock = 1273354016
Atom = 982564544
package test.thread;
import static java.lang.System.out;
import java.util.Random;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicLong;
import java.util.concurrent.locks.ReentrantLock;
public class TestSyncMethods {
public static void test(int round,int threadNum,CyclicBarrier cyclicBarrier){new SyncTest("Sync",round,threadNum,cyclicBarrier).testTime();new LockTest("Lock",round,threadNum,cyclicBarrier).testTime();new AtomicTest("Atom",round,threadNum,cyclicBarrier).testTime(); }public static void main(String args[]){for(int i=0;i<5;i++){int round=100000*(i+1);int threadNum=5*(i+1);CyclicBarrier cb=new CyclicBarrier(threadNum*2+1);out.println("==========================");out.println("round:"+round+" thread:"+threadNum);test(round,threadNum,cb);} }}
class SyncTest extends TestTemplate{
public SyncTest(String _id,int _round,int _threadNum,CyclicBarrier _cb){
super( _id, _round, _threadNum, _cb);
}
@Override
/**
* synchronized關鍵字不在方法簽名里面，所以不涉及重載問題
*/
synchronized long getValue() {
return super.countValue;
}
@Override
synchronized void sumValue() {
super.countValue+=preInit[index++%round];
}
}
class LockTest extends TestTemplate{
ReentrantLock lock=new ReentrantLock();
public LockTest(String _id,int _round,int _threadNum,CyclicBarrier _cb){
super( _id, _round, _threadNum, _cb);
}
/**
* synchronized關鍵字不在方法簽名里面，所以不涉及重載問題
*/
@Override
long getValue() {
try{
lock.lock();
return super.countValue;
}finally{
lock.unlock();
}
}
@Override
void sumValue() {
try{
lock.lock();
super.countValue+=preInit[index++%round];
}finally{
lock.unlock();
}
}
}
class AtomicTest extends TestTemplate{
public AtomicTest(String _id,int _round,int _threadNum,CyclicBarrier _cb){
super( _id, _round, _threadNum, _cb);
}
@Override
/**
* synchronized關鍵字不在方法簽名里面，所以不涉及重載問題
*/
long getValue() {
return super.countValueAtmoic.get();
}
@Override
void sumValue() {
super.countValueAtmoic.addAndGet(super.preInit[indexAtomic.get()%round]);
}
}
abstract class TestTemplate{
private String id;
protected int round;
private int threadNum;
protected long countValue;
protected AtomicLong countValueAtmoic=new AtomicLong(0);
protected int[] preInit;
protected int index;
protected AtomicInteger indexAtomic=new AtomicInteger(0);
Random r=new Random(47);
//任務柵欄，同批任務，先到達wait的任務掛起，一直等到全部任務到達制定的wait地點后，才能全部喚醒，繼續執行
private CyclicBarrier cb;
public TestTemplate(String _id,int _round,int _threadNum,CyclicBarrier _cb){
this.id=_id;
this.round=_round;
this.threadNum=_threadNum;
cb=_cb;
preInit=new int[round];
for(int i=0;i<preInit.length;i++){
preInit[i]=r.nextInt(100);
}
}
}
一、synchronize修飾不同代碼都是鎖住了什么？
大家都知道synchronize可以修飾屬性、代碼塊，方法、類，但是修飾不同的代碼鎖住的內容是不同的。
1、修飾非靜態屬性和方法時，拿到的是調用這個方法或者屬性的對象（this）的鎖。
2、synchronize（）修飾代碼塊時，拿到的是指定對象的鎖。
3、修飾類、靜態方法、靜態代碼塊時，由于沒有this指針，因此拿到的是類鎖，也就是該類的class對象。
！！！注意：一個對象只有一個鎖
二、關于synchronize
由于synchronize是由JVM實現的，因此當加鎖代碼出現異常時，對象鎖可以由JVM釋放，包含以下三種情況：
1、 占有鎖的線程執行完了代碼塊，然后釋放對鎖的占有；
2、 占有鎖的線程發生了異常，此時JVM會讓線程自動釋放鎖；
3、 占有鎖的線程調用了wait()方法，從而進入了WAITING狀態需要釋放鎖。
三、關于Lock
由于Lock是由JDK實現的，所以不像synchronize鎖的獲取和釋放都是由JVM控制的，Lock的獲取和釋放都需要手動進行，并且在發生異常時，不會自動釋放鎖。因此一般來說，使用Lock必須在try{}catch{}塊中進行，并且將釋放鎖的操作放在finally塊中進行，以保證鎖一定被被釋放，防止死鎖的發生。
1、lock() 獲取鎖與釋放鎖 ，如果鎖已被其他線程獲取，則進行等待。
復制代碼
1 Lock lock = …; lock.lock();
2 try{
3 //處理任務
4 }catch(Exception ex){
5 }finally{
6 lock.unlock(); //釋放鎖
7 }
復制代碼
2、tryLock() 獲取鎖時有返回值可以得知獲取鎖操作是否成功
復制代碼
1 Lock lock = …;
2 if(lock.tryLock()) {
3 try{
4 //處理任務
5 }catch(Exception ex){
6 }finally{
7 lock.unlock(); //釋放鎖
8 }
9 }else {
10 //如果不能獲取鎖，則直接做其他事情
11 }
復制代碼
如果獲取成功則返回True，如果鎖被其他線程占用則返回FALSE，該方法會立即返回結果，不會讓線程一直處于等待狀態。
3、tryLock(long time,TimeUnit unit) 與tryLock() 類似，但是與tryLock立即返回結果不同，該方法在拿不到鎖的情況下回等待time時間，如果在限定時間內還是拿不到鎖就返回FALSE，如果在一開始或者等待時間內拿到鎖則返回TRUE。
4、lockInterruptibly()
通過這個方法嘗試獲取鎖時，如果線程正在等待獲取鎖，則該線程可以響應Thread.interrupt()中斷。synchronize對于沒有獲得鎖處于等待狀態的線程無法響應中斷。
1 public void method() throws InterruptedException {
2 lock.lockInterruptibly();
3 try { //… }
4 finally { lock.unlock(); }
5 }
lockInterruptibly方法必須放在try塊中或者在調用lockInterruptibly的方法外聲明拋出InterruptedException，推薦使用后者。
5、readWriteLock()
該鎖提升了讀操作的效率，不過要注意的是，如果有一個線程已經占用了讀鎖，則此時其他線程如果要申請寫鎖，則申請寫鎖的線程會一直等待釋放讀鎖。如果有一個線程已經占用了寫鎖，則此時其他線程如果申請寫鎖或者讀鎖，則申請的線程也會一直等待釋放寫鎖。
四、Lock和synchronized的選擇：
1、 Lock是一個接口，屬于JDK層面的實現；而synchronized屬于Java語言的特性，其實現有JVM來控制（代碼執行完畢，出現異常，wait時JVM會主動釋放鎖）。
2、 synchronized在發生異常時，會自動釋放掉鎖，故不會發生死鎖現(此時的死鎖一般是代碼邏輯引起的)；而Lock必須在finally中主動unlock鎖，否則就會出現死鎖。
3、 Lock能夠響應中斷，讓等待狀態的線程停止等待；而synchronized不行。
4、 通過Lock可以知道線程是否成功獲得了鎖，而synchronized不行。
5、 Lock提高了多線程下對讀操作的效率。
五、擴展
1、可重入鎖：synchronized和ReentrantLock都是可重入鎖。當一個線程執行到某個synchronized方法時，比如說method1，而在method1中會調用另外一個synchronized方法method2，此時線程不必重新去申請鎖，而是可以直接執行方法method2。
2、可中斷鎖：等待獲得鎖的等待過程是否可以中斷。通過上面的例子，我們可以得知Lock是可中斷鎖，而synchronized不是。
3、公平鎖：盡量以請求的順序來獲取鎖，同是有多個線程在等待一個鎖，當這個鎖被釋放時，等待時間最久的線程（最先請求的線程）會獲得該鎖。synchronized是非公平鎖，而ReentrantLock和ReentReadWriteLock默認情況下是非公平鎖，但是可以設置成公平鎖。
ReentrantLock lock = new ReentrantLock(true);
ReentrantReadWriteLock lock = new ReentrantReadWriteLock(true);
設置為TRUE即為公平鎖，為FALSE或者無參數為非公平鎖。
4、讀寫鎖：讀寫鎖將對臨界資源的訪問分成了兩個鎖，一個讀鎖和一個寫鎖。增加讀寫靈活性。即ReadWriteLock接口及其實現ReentrantReadWriteLock。
總結
以上是生活随笔為你收集整理的Lock与synchronized 的区别的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： springboot打包不同环境配置与s
- 下一篇： 深入分析Synchronized原理(阿