2019獨角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

一，JAVA線程是如何實現(xiàn)的？

同步，涉及到多線程操作，那在JAVA中線程是如何實現(xiàn)的呢？

操作系統(tǒng)中講到，線程的實現(xiàn)(線程模型)主要有三種方式：

①使用內(nèi)核線程實現(xiàn)

②使用用戶線程實現(xiàn)

③使用用戶線程加輕量級線程實現(xiàn)

?

二，JAVA語言定義了哪幾種線程狀態(tài)？

JAVA語言定義了五種線程狀態(tài)：①新建(New)，當(dāng)你 new 了一個Thread，但是并沒有調(diào)用它的 start()方法時，就處于這種狀態(tài)。

②運(yùn)行（Run），這里包含了兩種狀態(tài)：一種是可運(yùn)行狀態(tài)，就是你調(diào)用了Thread的start()方法之后，但是該線程還未獲得CPU（相當(dāng)于操作系統(tǒng)中講的就緒狀態(tài)）；另一種是運(yùn)行狀態(tài)，就是該線程被調(diào)度器分配了CPU，正在執(zhí)行。

③等待（Waiting），處于這種狀態(tài)的線程不會被分配CPU執(zhí)行時間，它需要等待其他線程喚醒。等待又分成兩種：無限等待和超時等待(限期等待)。

無限等待一般是執(zhí)行等待的方法沒有指定超時參數(shù)

比如Object類的wait()方法，會使線程進(jìn)入無限等待狀態(tài)，它還有一個帶有 timeout(超時) 參數(shù) 的重載方法 Object.wait(long timeout)，使線程超時等待。

調(diào)用Thread.sleep() 、 Object.wait()、Thread.join()方法都會使線程進(jìn)入等待狀態(tài)。

④阻塞（Blocked），個人感覺阻塞是與鎖有關(guān)，而等待并不一定與鎖有關(guān)。

比如，兩個線程爭奪對象鎖(synchronized)，未獲得鎖的那個線程將進(jìn)入阻塞狀態(tài)。而線程進(jìn)入等待狀態(tài)則有可能是因為③中提到的調(diào)用了Thread.sleep()方法，或者是線程讀某個Socket端口上的數(shù)據(jù)，但是此時數(shù)據(jù)還未到達(dá)，則線程進(jìn)入等待狀態(tài)。

?⑤結(jié)束（Terminated），線程的run方法運(yùn)行完畢，進(jìn)入結(jié)束狀態(tài)。

?

三，同步(加鎖)為什么會有代價？

《深入理解JVM》中講到，在目前的JDK版本中，操作系統(tǒng)支持怎樣的線程模型，在很大程序上決定了JAVA虛擬機(jī)的線程是怎樣映射的。JAVA的線程是映射到操作系統(tǒng)的原生線程之上的，如果要阻塞或喚醒一個線程，都需要操作系統(tǒng)幫忙完成，這就需要從用戶態(tài)切換到核心態(tài)中，因此狀態(tài)轉(zhuǎn)換需要耗費很多的處理器時間。

而在JAVA里面要實現(xiàn)同步，一種是使用對象鎖，即synchronized關(guān)鍵字；另一種則是使用 java.util.ReentrantLock。獲得鎖的線程進(jìn)入臨界區(qū)執(zhí)行、未獲得鎖的線程會阻塞，然后在某種條件下被喚醒。因此，同步(使用鎖)是有代價的。

?

四，對象鎖同步(synchronized同步) 與 ReentrantLock同步的區(qū)別

它們都是可重入鎖，可用來互斥同步，但主要有三個方面的區(qū)別

①使用synchronized進(jìn)行同步的線程在阻塞等待時，是不可中斷的。而使用ReentrantLock進(jìn)行同步的線程在阻塞等待時可中斷。

如果臨界區(qū)需要執(zhí)行很長的時間，synchronized就只能一直阻塞等待了，而ReentrantLock 可以在阻塞等待一段時間之后，若還未獲得鎖，就可以被其他線程中斷，從而去干其他事情。一個很好的示例可參考：ReentrantLock鎖實現(xiàn)中斷線程阻塞

通過調(diào)用 lock.lockInterruptibly()方法來實現(xiàn)線程在阻塞等待時 可被其他線程 中斷。

?

②ReentrantLock可以實現(xiàn)公平鎖

?公平鎖是指多個線程在等待同一個鎖時，必須按照申請鎖的時間順序來依次獲得鎖。而非公平鎖則按照搶占的方式來獲得鎖，synchronized中的鎖是不公平的，而ReentrantLock可以在構(gòu)造函數(shù)中指定創(chuàng)建的鎖是否為公平鎖。

public ReentrantLock(boolean fair) {sync = fair ? new FairSync() : new NonfairSync();}

?

③使用ReentrantLock 鎖可以同時綁定多個條件變量(Condition對象)

所謂 條件對象 就是說：線程好不容易獲得了鎖 進(jìn)入臨界區(qū)，卻發(fā)現(xiàn)需要在滿足某一條件之后，它才能執(zhí)行。因此，使用一個條件對象來管理那些已經(jīng)獲得了鎖但是卻不能做有用工作的線程。

比如說：生產(chǎn)者--消費者模型，消費者獲得了隊列的鎖，去隊列中取產(chǎn)品，但是結(jié)果發(fā)現(xiàn)隊列為空，它沒有產(chǎn)品可消費。換句話說：它需要在隊列不為空的條件下，才能消費產(chǎn)品。（沒有產(chǎn)品，肯定無法消費產(chǎn)品啊！）

比如，消費者的代碼一般是下面這樣：進(jìn)入consume(）方法需要獲得鎖，但是卻發(fā)現(xiàn)隊列為空，故只能調(diào)用wait()方法 進(jìn)入等待狀態(tài)。（不是阻塞狀態(tài)）

public synchronized void consume(){while(queue.isEmpty())wait();//沒有產(chǎn)品可消費，只能放棄鎖,并等待生產(chǎn)者線程生產(chǎn)了產(chǎn)品之后，喚醒它//consume productnotifyAll();//....}

?

那ReentrantLock呢？

Condition emptyCondition = lock.newCondition();Condition fullCondition = lock.newCondition();.......public synchronized void consume(){try{lock.lock();//ReentrantLock lockwhile(queue.isEmpty())emptyCondition.await();//consume productemptyCondition.singalAll();//....}finally{lock.unlock();}}

對于同一把ReentrantLock，它可以 new多個Condition，即同一把鎖可以關(guān)聯(lián)多個條件變量。

Condition.awit()方法的JDK源碼解釋非常值得一讀。部分摘錄如下：

Causes the current thread to wait until it is signalled or* {@linkplain Thread#interrupt interrupted}.* <p>The lock associated with this {@code Condition} is atomically* released and the current thread becomes disabled for thread scheduling* purposes and lies dormant until <em>one</em> of four things happens

調(diào)用Condition.await()方法使線程放棄鎖，并進(jìn)入等待狀態(tài)（不是阻塞狀態(tài)）,直到有下列四種情況發(fā)生 才從等待狀態(tài)退出.....

?.....

?

五，互斥同步 與 非阻塞同步 是什么？

所謂互斥同步，就是多個線程爭奪一把鎖時，未獲得鎖的那些線程將會阻塞。因此，互斥同步最主要的是進(jìn)行線程阻塞和喚醒帶來的性能問題，因此 互斥同步稱為阻塞同步。從處理問題的方式上看，它是一種悲觀的并發(fā)策略：它認(rèn)為如果不采取正確的同步措施，那執(zhí)行就可能出問題。也就是說：它總是對共享數(shù)據(jù)先進(jìn)行加鎖，然后再去訪問，盡管在訪問過程中 也許 并沒有 其他線程 訪問該共享數(shù)據(jù)。

而正如前面（三）中 提到，加鎖是有代價的，如果對共享數(shù)據(jù)加了鎖，但是在訪問共享數(shù)據(jù)過程中，并沒有其他線程來訪問該共享數(shù)據(jù)（即并沒有出現(xiàn)競爭），那這次加鎖就感覺有點浪費了。（就相當(dāng)于：花了大量的人力、物力應(yīng)對某次可能發(fā)生的地震，但是最終地震沒有發(fā)生）

于是，為了進(jìn)一步的”優(yōu)化“，就出現(xiàn)了基于沖突檢測的樂觀并發(fā)策略。

樂觀并發(fā)策略就是：先進(jìn)行操作，如果沒有其他線程爭用共享數(shù)據(jù)，那么操作就成功了。如果數(shù)據(jù)有爭用，產(chǎn)生了沖突，那再采用補(bǔ)救措施。

因此，樂觀并發(fā)策略的很多實現(xiàn)都不需要把線程掛起（因為它是 先執(zhí)行了 操作再說），因而稱為：非阻塞同步。

樂觀并發(fā)策略需要硬件指令集的支持。因為，它在操作的過程中需要檢測是否發(fā)生了沖突，需要“操作”和“沖突檢測”這兩個步驟具備原子性。原子性如何保證？如果用互斥同步保證 那就又變回 悲觀并發(fā)策略 了，因此只能靠硬件來保證原子性。

比如java.util.concurrent.atomic.AtomicInteger.java 中的自增加1方法getAndIncrement()，就是通過硬件原子指令：CAS指令(Compare and swap)來實現(xiàn)

public final int getAndIncrement() {for (;;) {int current = get();int next = current + 1;if (compareAndSet(current, next))return current;}}public final boolean compareAndSet(int expect, int update) {return unsafe.compareAndSwapInt(this, valueOffset, expect, update);}

?

六，關(guān)于鎖優(yōu)化的一些知識

1）自旋鎖 的 實現(xiàn)思想

在多核CPU下，一個線程獲得鎖進(jìn)入臨界區(qū)占用CPU執(zhí)行時，我們有理由相信這個臨界區(qū)代碼很快就會執(zhí)行完成，即： 共享數(shù)據(jù)的鎖定狀態(tài)只會持續(xù)很短的一段時間，而當(dāng)另外一個線程剛好在這段時間去搶占鎖，掛起這個搶占鎖的線程有點 不值得。（畢竟占用鎖的線程很快就會把鎖釋放了呀）

于是，就讓請求搶占鎖的那個線程“稍微等待一下”，但不放棄處理器的執(zhí)行時間（一旦放棄，就意味著需要掛起和恢復(fù)線程了），看持有鎖的線程是否很快就會釋放鎖。為了讓線程等待一下，我們只需讓線程執(zhí)行一個忙循環(huán)（自旋），這就是：自旋鎖。

?

2）自旋鎖的“改進(jìn)”---自適應(yīng)自旋

?自旋等待避免了線程切換的開銷，但是它是要占用處理器時間的。因此，如果鎖被占用的時間很短，那自旋等待的效果就會非常好；如何鎖被占用的時間很長，執(zhí)行忙循環(huán)（自旋）的線程就白白消耗處理器資源，造成性能上的浪費。默認(rèn)情況下，自旋的次數(shù)是10次，但可以通過JVM參數(shù)進(jìn)行修改。

為了應(yīng)對鎖被占用很長時間 而導(dǎo)致的長時間無效的自旋，自旋的時間必須有一定的限度。

那如何確定一個合適的限定呢？這就是自適應(yīng)自旋的目標(biāo)了。

自適應(yīng)自旋對自旋的次數(shù)沒有固定，比如說：在同一個鎖對象，自旋等待剛剛成功獲得過鎖，那么這次也很有可能成功，進(jìn)而允許自旋等待持續(xù)相對更長的時間。

再比如說，對于某個鎖，自旋很少成功獲得過鎖，那在以后獲取這個鎖時可省略自旋過程，以避免處理器資源浪費。

?

3）輕量級鎖和偏向鎖

?個人感覺輕量級鎖和偏向鎖 的功能 與 緩存 的思想有點像。直接同步互斥加鎖的代價是很大的（重量級鎖），那我們可以先來一個輕量級鎖或偏向鎖。

如果在加了 輕量級鎖或偏向鎖的過程中?沒有發(fā)生其他線程來爭搶鎖（類似于緩存命中！）這意味著整個過程“幾乎”不需要同步。

如果有其他線程爭搶鎖，那輕量級鎖將不再有效（偏向鎖的偏向模式失效），輕量級鎖要膨脹為“重量級鎖”，后面等待鎖的線程要進(jìn)入阻塞狀態(tài)。這就是類似于緩存未命中！

關(guān)于輕量級鎖和偏向鎖的具體解釋：可參考《深入理解JVM》

?

上面關(guān)于鎖的優(yōu)化是JVM的一些鎖優(yōu)化策略，在應(yīng)用層進(jìn)行鎖優(yōu)化方式有如下：

①盡量減少鎖的持有時間。只對必要的需要同步的代碼進(jìn)行同步。

synchronized{this} {methodA();// 把不需要同步的方法放到 sync 外面去mutex();//other method...// 把不需要同步的方法放到 sync 外面去 }

?

②減少鎖的粒度

ConcurrentHashMap就很好的應(yīng)用了這種思想。它將整個HashMap分成了若干個段(Segment)，每個段都有自己的鎖，每個段負(fù)責(zé)管理HashMap中的一部分HashEntry，段與段之間的HashEntry互不干擾，多線程可以并行地操作不同的Segment管理下的HashEntry。

這樣鎖的粒度就減少了。如果整個HashMap只有一把鎖管理，鎖的粒度就很大。操作HashMap不同的區(qū)域都需要互斥同步。而ConcurrentHashMap將HashMap分解成段，每個段有一把鎖，鎖的粒度就少了。但是與此同時，鎖的數(shù)量增多了。當(dāng)需要訪問ConcurrentHashMap的全局屬性時（比如ConcurrentHashMap的size()方法），需要 獲得 所有的段的鎖。

1 try { 2 for (;;) { 3 if (retries++ == RETRIES_BEFORE_LOCK) { 4 for (int j = 0; j < segments.length; ++j) 5 ensureSegment(j).lock(); // force creation

以上是size()方法的部分代碼，size()的具體實現(xiàn)肯定也有相應(yīng)的優(yōu)化。

?

③鎖分離

鎖分離與鎖分段有點相似，鎖分離就是對不同的操作使用不同的鎖。比如，java.util.concurrent.LinkedBlockingQueue 是一個線程安全的阻塞隊列，take()方法從隊列中取元素，put()方法向隊列中添加元素。

這個隊列是用鏈?zhǔn)酱鎯Y(jié)構(gòu)實現(xiàn)，它的結(jié)點類如下：

1 /**2 * Linked list node class3 */4 static class Node<E> {5 E item;6 7 /**8 * One of:9 * - the real successor Node 10 * - this Node, meaning the successor is head.next 11 * - null, meaning there is no successor (this is the last node) 12 */ 13 Node<E> next; 14 15 Node(E x) { item = x; } 16 }

它的 put 操作 和 take 操作分別作用于隊列的尾部和頭部，并沒有相互沖突。如果 take 和 put 都共享同一把鎖，那么從隊列中取走元素的同時，就不能向隊列中添加元素，盡管它們互不“干擾”。

因此，為了提高并發(fā)效率，就使用了兩把鎖：一把 put 鎖，一把 take 鎖。這就是鎖分離機(jī)制。

1 /** Lock held by take, poll, etc */2 private final ReentrantLock takeLock = new ReentrantLock();3 4 /** Wait queue for waiting takes */5 private final Condition notEmpty = takeLock.newCondition();6 7 /** Lock held by put, offer, etc */8 private final ReentrantLock putLock = new ReentrantLock();9 10 /** Wait queue for waiting puts */ 11 private final Condition notFull = putLock.newCondition();

?

take鎖對應(yīng)著 notEmtpy條件變量，putLock對應(yīng)著一個 notFull條件變量。

在大部分情況下，多線程可以同時并行地向阻塞隊列中添加元素和取出元素。比如線程A向隊列添加元素的時候，并不阻塞線程B從隊列中取出元素。

通過使用 take 鎖 和 put 鎖，將LinkedBlockingQueue的讀寫分離。優(yōu)化了并發(fā)效率。

?

④鎖粗化

這個與①中的盡量減少 鎖的時間 思想相反。但它們適用的情況是不同的。

比如，當(dāng)程序需要在 for 循環(huán)內(nèi)部加鎖時，每執(zhí)行一次 for 循環(huán)中的操作就需要加鎖一次，加鎖之后執(zhí)行臨界區(qū)代碼后又釋放鎖，這樣加鎖、釋放鎖的頻率非常大，效率反而低了。

1 public void syncMethod(){2 for(int i = 0; i < COUTN; i++)3 {4 synchronized(this){5 mutex();6 }7 //do something, do not need lock8 synchronized(this){9 mutex(); 10 } 11 //do another thing which needs no lock 12 } 13 }

?

這樣，直接用synchronized修飾方法反而要更好一點。

?

七，參考資料

《深入理解JVM》周志明

http://thrillerzw.iteye.com/blog/2055486

?

原文：http://www.cnblogs.com/hapjin/p/5765573.html

轉(zhuǎn)載于:https://my.oschina.net/u/3787897/blog/1630673

總結(jié)

以上是生活随笔為你收集整理的JAVA中关于并发的一些理解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。