Java中導(dǎo)致饑餓的原因是什么

小編給大家分享一下Java中導(dǎo)致饑餓的原因是什么，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

如果一個(gè)線程因?yàn)镃PU時(shí)間全部被其他線程搶走而得不到CPU運(yùn)行時(shí)間，這種狀態(tài)被稱之為“饑餓”。而該線程被“饑餓致死”正是因?yàn)樗貌坏紺PU運(yùn)行時(shí)間的機(jī)會(huì)。解決饑餓的方案被稱之為“公平性” – 即所有線程均能公平地獲得運(yùn)行機(jī)會(huì)。

 下面是本文討論的主題：

Java中導(dǎo)致饑餓的原因

在Java中，下面三個(gè)常見的原因會(huì)導(dǎo)致線程饑餓：

高優(yōu)先級(jí)線程吞噬所有的低優(yōu)先級(jí)線程的CPU時(shí)間。
線程被永久堵塞在一個(gè)等待進(jìn)入同步塊的狀態(tài)，因?yàn)槠渌€程總是能在它之前持續(xù)地對(duì)該同步塊進(jìn)行訪問(wèn)。
線程在等待一個(gè)本身(在其上調(diào)用wait())也處于永久等待完成的對(duì)象，因?yàn)槠渌€程總是被持續(xù)地獲得喚醒。

高優(yōu)先級(jí)線程吞噬所有的低優(yōu)先級(jí)線程的CPU時(shí)間

你能為每個(gè)線程設(shè)置獨(dú)自的線程優(yōu)先級(jí)，優(yōu)先級(jí)越高的線程獲得的CPU時(shí)間越多，線程優(yōu)先級(jí)值設(shè)置在1到10之間，而這些優(yōu)先級(jí)值所表示行為的準(zhǔn)確解釋則依賴于你的應(yīng)用運(yùn)行平臺(tái)。對(duì)大多數(shù)應(yīng)用來(lái)說(shuō)，你最好是不要改變其優(yōu)先級(jí)值。

線程被永久堵塞在一個(gè)等待進(jìn)入同步塊的狀態(tài)

Java的同步代碼區(qū)也是一個(gè)導(dǎo)致饑餓的因素。Java的同步代碼區(qū)對(duì)哪個(gè)線程允許進(jìn)入的次序沒(méi)有任何保障。這就意味著理論上存在一個(gè)試圖進(jìn)入該同步區(qū)的線程處于被永久堵塞的風(fēng)險(xiǎn)，因?yàn)槠渌€程總是能持續(xù)地先于它獲得訪問(wèn)，這即是“饑餓”問(wèn)題，而一個(gè)線程被“饑餓致死”正是因?yàn)樗貌坏紺PU運(yùn)行時(shí)間的機(jī)會(huì)。

線程在等待一個(gè)本身(在其上調(diào)用wait())也處于永久等待完成的對(duì)象

如果多個(gè)線程處在wait()方法執(zhí)行上，而對(duì)其調(diào)用notify()不會(huì)保證哪一個(gè)線程會(huì)獲得喚醒，任何線程都有可能處于繼續(xù)等待的狀態(tài)。因此存在這樣一個(gè)風(fēng)險(xiǎn)：一個(gè)等待線程從來(lái)得不到喚醒，因?yàn)槠渌却€程總是能被獲得喚醒。

下面分享一個(gè)線程饑餓死鎖的例子，代碼：

public class ThreadDeadlock {
	ExecutorService exec = Executors.newSingleThreadScheduledExecutor();
	//  ExecutorService exec = Executors.newCachedThreadPool();  //如果添加給線程池中添加足夠多的線程，就可以讓所有任務(wù)都執(zhí)行，避免饑餓死鎖。 
	/** 
   * 模擬頁(yè)面加載的例子 
   * 
   * 產(chǎn)生死鎖分析： 
   * RenderPageTask任務(wù)中有2個(gè)子任務(wù)分別是“加載頁(yè)眉”和“加載頁(yè)腳”。當(dāng)提交RenderPageTask任務(wù)時(shí)，實(shí)際上是向線程池中添加了3個(gè)任務(wù)， 
   * 但是由于線程池是單一線程池，同時(shí)只會(huì)執(zhí)行一個(gè)任務(wù)，2個(gè)子任務(wù)就會(huì)在阻塞在線程池中。而RenderPageTask任務(wù)由于得不到返回，也會(huì) 
   * 一直堵塞，不會(huì)釋放線程資源讓子線程執(zhí)行。這樣就導(dǎo)致了線程饑餓死鎖。 
   * 
   * 在一個(gè)Callable任務(wù)中，要返回2個(gè)子任務(wù) 
   * @author hadoop 
   * 
   */
	class RenderPageTask implements Callable<String>{
		@Override 
		    public String call() throws Exception {
			Future<String> header,footer;
			header = exec.submit(new Callable<String>(){
				@Override 
				        public String call() throws Exception {
					System.out.println("加載頁(yè)眉");
					Thread.sleep(2*1000);
					return "頁(yè)眉";
				}
			}
			);
			footer = exec.submit(new Callable<String>(){
				@Override 
				        public String call() throws Exception {
					System.out.println("加載頁(yè)腳");
					Thread.sleep(3*1000);
					return "頁(yè)腳";
				}
			}
			);
			System.out.println("渲染頁(yè)面主體");
			return header.get() + footer.get();
		}
	}
	public static void main(String[] args) throws InterruptedException, ExecutionException {
		ThreadDeadlock td = new ThreadDeadlock();
		Future<String> futre = td.exec.submit(td.new RenderPageTask());
		String result = futre.get();
		System.out.println("執(zhí)行結(jié)果為：" + result);
	}
}

在Java中實(shí)現(xiàn)公平性

雖Java不可能實(shí)現(xiàn)100%的公平性，我們依然可以通過(guò)同步結(jié)構(gòu)在線程間實(shí)現(xiàn)公平性的提高。

首先來(lái)學(xué)習(xí)一段簡(jiǎn)單的同步態(tài)代碼：

public class Synchronizer{
  public synchronized void doSynchronized(){
  //do a lot of work which takes a long time
  }
}

如果有一個(gè)以上的線程調(diào)用doSynchronized()方法，在第一個(gè)獲得訪問(wèn)的線程未完成前，其他線程將一直處于阻塞狀態(tài)，而且在這種多線程被阻塞的場(chǎng)景下，接下來(lái)將是哪個(gè)線程獲得訪問(wèn)是沒(méi)有保障的。

使用鎖方式替代同步塊

為了提高等待線程的公平性，我們使用鎖方式來(lái)替代同步塊。

public class Synchronizer{
  Lock lock = new Lock();
  public void doSynchronized() throws InterruptedException{
    this.lock.lock();
    //critical section, do a lot of work which takes a long time
    this.lock.unlock();
  }
}

注意到doSynchronized()不再聲明為synchronized，而是用lock.lock()和lock.unlock()來(lái)替代。

下面是用Lock類做的一個(gè)實(shí)現(xiàn)：

public class Lock{
	private Boolean isLocked   = false;
	private Thread lockingThread = null;
	public synchronized void lock() throws InterruptedException{
		while(isLocked){
			wait();
		}
		isLocked = true;
		lockingThread = Thread.currentThread();
	}
	public synchronized void unlock(){
		if(this.lockingThread != Thread.currentThread()){
			throw new IllegalMonitorStateException(
			       "Calling thread has not locked this lock");
		}
		isLocked = false;
		lockingThread = null;
		notify();
	}
}

注意到上面對(duì)Lock的實(shí)現(xiàn)，如果存在多線程并發(fā)訪問(wèn)lock()，這些線程將阻塞在對(duì)lock()方法的訪問(wèn)上。另外，如果鎖已經(jīng)鎖上（校對(duì)注：這里指的是isLocked等于true時(shí)），這些線程將阻塞在while(isLocked)循環(huán)的wait()調(diào)用里面。要記住的是，當(dāng)線程正在等待進(jìn)入lock() 時(shí)，可以調(diào)用wait()釋放其鎖實(shí)例對(duì)應(yīng)的同步鎖，使得其他多個(gè)線程可以進(jìn)入lock()方法，并調(diào)用wait()方法。

這回看下doSynchronized()，你會(huì)注意到在lock()和unlock()之間的注釋：在這兩個(gè)調(diào)用之間的代碼將運(yùn)行很長(zhǎng)一段時(shí)間。進(jìn)一步設(shè)想，這段代碼將長(zhǎng)時(shí)間運(yùn)行，和進(jìn)入lock()并調(diào)用wait()來(lái)比較的話。這意味著大部分時(shí)間用在等待進(jìn)入鎖和進(jìn)入臨界區(qū)的過(guò)程是用在wait()的等待中，而不是被阻塞在試圖進(jìn)入lock()方法中。

在早些時(shí)候提到過(guò)，同步塊不會(huì)對(duì)等待進(jìn)入的多個(gè)線程誰(shuí)能獲得訪問(wèn)做任何保障，同樣當(dāng)調(diào)用notify()時(shí)，wait()也不會(huì)做保障一定能喚醒線程（至于為什么，請(qǐng)看線程通信）。因此這個(gè)版本的Lock類和doSynchronized()那個(gè)版本就保障公平性而言，沒(méi)有任何區(qū)別。

但我們能改變這種情況。當(dāng)前的Lock類版本調(diào)用自己的wait()方法，如果每個(gè)線程在不同的對(duì)象上調(diào)用wait()，那么只有一個(gè)線程會(huì)在該對(duì)象上調(diào)用wait()，Lock類可以決定哪個(gè)對(duì)象能對(duì)其調(diào)用notify()，因此能做到有效的選擇喚醒哪個(gè)線程。

公平鎖

下面來(lái)講述將上面Lock類轉(zhuǎn)變?yōu)楣芥iFairLock。你會(huì)注意到新的實(shí)現(xiàn)和之前的Lock類中的同步和wait()/notify()稍有不同。
準(zhǔn)確地說(shuō)如何從之前的Lock類做到公平鎖的設(shè)計(jì)是一個(gè)漸進(jìn)設(shè)計(jì)的過(guò)程，每一步都是在解決上一步的問(wèn)題而前進(jìn)的：Nested Monitor Lockout, Slipped Conditions和Missed Signals。這些本身的討論雖已超出本文的范圍，但其中每一步的內(nèi)容都將會(huì)專題進(jìn)行討論。重要的是，每一個(gè)調(diào)用lock()的線程都會(huì)進(jìn)入一個(gè)隊(duì)列，當(dāng)解鎖后，只有隊(duì)列里的第一個(gè)線程被允許鎖住Farlock實(shí)例，所有其它的線程都將處于等待狀態(tài)，直到他們處于隊(duì)列頭部。

public class FairLock {
	private Boolean      isLocked    = false;
	private Thread      lockingThread = null;
	private List<QueueObject> waitingThreads =
	      new ArrayList<QueueObject>();
	public void lock() throws InterruptedException{
		QueueObject queueObject      = new QueueObject();
		Boolean   isLockedForThisThread = true;
		synchronized(this){
			waitingThreads.add(queueObject);
		}
		while(isLockedForThisThread){
			synchronized(this){
				isLockedForThisThread =
				      isLocked || waitingThreads.get(0) != queueObject;
				if(!isLockedForThisThread){
					isLocked = true;
					waitingThreads.remove(queueObject);
					lockingThread = Thread.currentThread();
					return;
				}
			}
			try{
				queueObject.doWait();
			}
			catch(InterruptedException e){
				synchronized(this) {
					waitingThreads.remove(queueObject);
				}
				throw e;
			}
		}
	}
	public synchronized void unlock(){
		if(this.lockingThread != Thread.currentThread()){
			throw new IllegalMonitorStateException(
			    "Calling thread has not locked this lock");
		}
		isLocked   = false;
		lockingThread = null;
		if(waitingThreads.size() > 0){
			waitingThreads.get(0).doNotify();
		}
	}
}

public class QueueObject {
	private Boolean isNotified = false;
	public synchronized void doWait() throws InterruptedException {
		while(!isNotified){
			this.wait();
		}
		this.isNotified = false;
	}
	public synchronized void doNotify() {
		this.isNotified = true;
		this.notify();
	}
	public Boolean equals(Object o) {
		return this == o;
	}
}

首先注意到lock()方法不在聲明為synchronized，取而代之的是對(duì)必需同步的代碼，在synchronized中進(jìn)行嵌套。

FairLock新創(chuàng)建了一個(gè)QueueObject的實(shí)例，并對(duì)每個(gè)調(diào)用lock()的線程進(jìn)行入隊(duì)列。調(diào)用unlock()的線程將從隊(duì)列頭部獲取QueueObject，并對(duì)其調(diào)用doNotify()，以喚醒在該對(duì)象上等待的線程。通過(guò)這種方式，在同一時(shí)間僅有一個(gè)等待線程獲得喚醒，而不是所有的等待線程。這也是實(shí)現(xiàn)FairLock公平性的核心所在。

請(qǐng)注意，在同一個(gè)同步塊中，鎖狀態(tài)依然被檢查和設(shè)置，以避免出現(xiàn)滑漏條件。

還需注意到，QueueObject實(shí)際是一個(gè)semaphore。doWait()和doNotify()方法在QueueObject中保存著信號(hào)。這樣做以避免一個(gè)線程在調(diào)用queueObject.doWait()之前被另一個(gè)調(diào)用unlock()并隨之調(diào)用queueObject.doNotify()的線程重入，從而導(dǎo)致信號(hào)丟失。queueObject.doWait()調(diào)用放置在synchronized(this)塊之外，以避免被monitor嵌套鎖死，所以另外的線程可以解鎖，只要當(dāng)沒(méi)有線程在lock方法的synchronized(this)塊中執(zhí)行即可。

最后，注意到queueObject.doWait()在try – catch塊中是怎樣調(diào)用的。在InterruptedException拋出的情況下，線程得以離開lock()，并需讓它從隊(duì)列中移除。

性能考慮

如果比較Lock和FairLock類，你會(huì)注意到在FairLock類中l(wèi)ock()和unlock()還有更多需要深入的地方。這些額外的代碼會(huì)導(dǎo)致FairLock的同步機(jī)制實(shí)現(xiàn)比Lock要稍微慢些。究竟存在多少影響，還依賴于應(yīng)用在FairLock臨界區(qū)執(zhí)行的時(shí)長(zhǎng)。執(zhí)行時(shí)長(zhǎng)越大，F(xiàn)airLock帶來(lái)的負(fù)擔(dān)影響就越小，當(dāng)然這也和代碼執(zhí)行的頻繁度相關(guān)。

以上是“Java中導(dǎo)致饑餓的原因是什么”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！