第一種場景：作業的某個任務阻塞了，長時間佔用資源不釋放，如何處理？
這種場景通常是由於軟件Bug、數據特殊性等原因導致的，會讓程序阻塞，任務運行停滯不前。在外界看來，任務（Task）好像阻塞了一樣。這種事情經常發生，由於任務長時間佔用着資源但不使用（如果不採取一定的手段，可能永遠不會被使用，造成“資源泄露”），會導致資源利用率下降，對系統不利，那麼，Hadoop MapReduce遇到這種情況如何處理呢？
在TaskTracker上，每個任務會定期向TaskTracker彙報新的進度（如果進度不變則不彙報），並由TaskTracker進一步彙報給JobTracker。當某個任務被阻塞時，它的進度將停滯不前，此時任務不會向TaskTracker彙報進度，這樣，一定達到超時時間上限，TaskTracker會將該任務殺掉，並將任務狀態（KILLED）彙報給JobTracker，進而觸發JobTracker重新調度該任務。
在實際應用場景中，有些正常的作業，其任務可能長時間沒有讀入或者輸出，比如讀取數據庫的Map Task或者需要連接其他外部系統的Task，對於這類應用，在編寫Mapper或Reducer時，應當啓動一個額外的線程通過Reporter組件定期向TaskTracker彙報心跳（只是告訴TaskTracker自己還活着，不要把我殺了）。
第二種場景：作業的Map Task全部運行完成後，在Reduce Task運行過程中，某個Map Task所在節點掛了，或者Map結果存放磁盤損壞了，該如何處理？
這種場景比較複雜，需分開討論。
如果節點掛了，JobTracker通過心跳機制知道TaskTracker死掉了，會重新調度之前正在運行的Task和正在運行的作業中已經運行完成的Map Task。
如果節點沒有掛，只是存放Map Task結果的磁盤損壞了，則分兩種情況：
（1）所有的Reduce Task已經完成shuffle階段
（2）尚有部分Reduce Task沒有完成shuffle階段，需要讀取該Map Task任務
對於第一種情況，如果所有Reduce Task一路順風地運行下去，則無需對已經運行完成的Map Task作任何處理，如果某些Reduce Task一段時間後運行失敗了，則處理方式與第二種一樣。
對於第二種情況，當Reduce Task遠程讀取那個已經運行完成的Map Task結果(但結果已經損壞)時，會嘗試讀取若干次，如果嘗試次數超過了某個上限值，則會通過RPC告訴所在的TaskTracker該Map Task結果已經損壞，而TaskTracker則進一步通過RPC告訴JobTracker，JobTracker收到該消息後，會重新調度該Map Task，進而重新計算生成結果。
需要強調的是，目前Hadoop MapReduce的實現中，Reduce Task重試讀取Map Task結果的時間間隔是指數形式遞增的，計算公式是10000*1.3^noFailedFetches，其中noFailedFetches取值範圍爲MAX{10， numMaps/30}，也就是說，如果map task數目是300，則需要嘗試10次纔會發現Map Task結果已經損壞，嘗試時間間隔分別是10s，13s，21s，28s，37s，48s，62s，81s和106s，需要非常長的時間才能發現，而且Map Task越多，發現時間越慢，這個地方通常需要調優，因爲任務數目越多的作業，越容易出現這種問題。
在MapReduce V2.0中，所有任務（Map Task和Reduce Task）直接跟MRAppMaster交互，不需要通過類似於TaskTracker這樣的中間層，整個過程與上述過程類似，在此不再贅述。