轉載地址：http://www.jianshu.com/p/a79b8765f729#
通過以下文章的閱讀，相信你對android的線程,線程池以及原理會有更加深刻的理解
這塊的知識可以說是一大塊,要擼清楚還是要花點時間,線程池中關聯到的隊列不僅在線程池中使用,在各種第三方網絡框架和圖片框架等等中也是通過自己調度隊列來實現異步。有關理論的東西"前人"寫的好文章太多了,所以也沒必要再去複製粘貼來寫一篇博文（文章結尾鏈接一個有關線程和線程池的面試題）
還是先回顧下Handler消息機制的原理圖
同樣的還是先看看一篇對《Android開發藝術探索》的總結，對線程和線程池有個大致的瞭解（建議和源碼一起看）
Android開發藝術探索 第11章 線程與線程池 讀書筆記
上面的文章講的只是基本概念，還是要看看稍微詳細的文章
線程、多線程與線程池總結
在AsyncTask源碼中有使用到Callable、Future和FutureTask，對這個概念不清楚的不妨看看這篇博客
Java併發編程：Callable、Future和FutureTask
針對書中講到的AsyncTask附上一張AsyncTask工作原理圖(結合源代碼理解)
不過不建議使用AsyncTask，因爲4.x系統中AsyncTask是串行的，高併發的Task讓AsyncTask一個一個串行執行，程序就會很慢。可以看看這篇譯文講解具體原因
但是這不是我們不看源碼的理由，雖然很多缺點但是掌握AsyncTask原理可以對消息機制以及線程池理解更加深刻。
在《Android開發藝術探索》書中有提到HandlerThread和IntentService，具體的分析，可以看看洋神寫的兩篇文章（如果對消息機制不熟悉的建議再看看消息機制的原理，這樣會更好理解這兩篇文章）
Android HandlerThread 完全解析
Android IntentService完全解析 當Service遇到Handler
上面的文章都沒有對線程池詳細的講解,所以推薦兩篇篇好文，主要是講android中自帶的5個線程池的使用以及自定義線程池的使用,例子也是根據官方的例子來講解的,非常詳細
Android性能優化之使用線程池處理異步任務
【Java併發編程】之十九併發新特性—Executor框架與線程池
文章提及到了默認的一個拒絕策略(AbortPolicy),這裏就擼一下4種策略,使用的話只要簡單傳參new ThreadPoolExecutor.DiscardPolicy()
RejectedExecutionHandler的四種拒絕策略
-
ThreadPoolExecutor.AbortPolicy(默認策略):
當線程池中的數量等於最大線程數時拋出java.util.concurrent.RejectedExecutionException異常.
涉及到該異常的任務也不會被執行. -
ThreadPoolExecutor.CallerRunsPolicy():
當線程池中的數量等於最大線程數時,重試添加當前的任務;它會自動重複調用execute()方法 -
ThreadPoolExecutor.DiscardOldestPolicy():
當線程池中的數量等於最大線程數時,拋棄線程池中工作隊列頭部的任務(即等待時間最久Oldest的任務),並執行新傳入的任務 -
ThreadPoolExecutor.DiscardPolicy():
當線程池中的數量等於最大線程數時,丟棄不能執行的新加任務
順便再擼一下線程池中的排隊策略
參考自http://blog.csdn.net/ns_code/article/details/17465497
排隊有三種通用策略：
1.直接提交。工作隊列的默認選項是 SynchronousQueue，它將任務直接提交給線程而不保持它們。在此，如果不存在可用於立即運行任務的線程，則試圖把任務加入隊列將失敗，因此會構造一個新的線程。此策略可以避免在處理可能具有內部依賴性的請求集合時出現鎖定。直接提交通常要求無界 maximumPoolSizes 以避免拒絕新提交的任務。當命令以超過隊列所能處理的平均數連續到達時，此策略允許無界線程具有增長的可能性。
2.無界隊列。使用無界隊列（例如，不具有預定義容量的 LinkedBlockingQueue）將導致在所有 corePoolSize 線程都忙的情況下將新任務加入隊列。這樣，創建的線程就不會超過 corePoolSize。（因此，maximumPoolSize 的值也就無效了。）當每個任務完全獨立於其他任務，即任務執行互不影響時，適合於使用無界隊列；例如，在 Web頁服務器中。這種排隊可用於處理瞬態突發請求，當命令以超過隊列所能處理的平均數連續到達時，此策略允許無界線程具有增長的可能性。
3.有界隊列。當使用有限的 maximumPoolSizes 時，有界隊列（如 ArrayBlockingQueue）有助於防止資源耗盡，但是可能較難調整和控制。隊列大小和最大池大小可能需要相互折衷：使用大型隊列和小型池可以最大限度地降低 CPU 使用率、操作系統資源和上下文切換開銷，但是可能導致人工降低吞吐量。如果任務頻繁阻塞（例如，如果它們是 I/O 邊界），則系統可能爲超過您許可的更多線程安排時間。使用小型隊列通常要求較大的池大小，CPU 使用率較高，但是可能遇到不可接受的調度開銷，這樣也會降低吞吐量。
針對幾篇文章中提到的隊列,這裏簡單總結下:
Queue接口與List、Set同一級別，都是繼承了Collection接口。android中大量使用的BlockingQueue繼承了Queue接口,線程池中的隊列都是實現BlockingQueue接口,看看BlockingQueue中定義的一些接口方法
| name | note | detail |
|---|---|---|
| add | 增加一個元素 | 如果隊列已滿，則拋出一個IIIegaISlabEepeplian異常 |
| remove | 移除並返回隊列頭部的元素 | 如果隊列爲空，則拋出一個NoSuchElementException異常 |
| element | 返回隊列頭部的元素 | 如果隊列爲空，則拋出一個NoSuchElementException異常 |
| offer | 添加一個元素並返回true | 如果隊列已滿，則返回false |
| poll | 移除並返問隊列頭部的元素 | 如果隊列爲空，則返回null |
| peek | 返回隊列頭部的元素 | 如果隊列爲空，則返回null |
| put | 添加一個元素 | 如果隊列滿，則阻塞 |
| take | 移除並返回隊列頭部的元素 | 如果隊列爲空，則阻塞 |
LinkedBlockingQueue默認情況下，LinkedBlockingQueue的容量是沒有上限的（說的不準確，在不指定時容量爲Integer.MAX_VALUE，不要然的話在put時怎麼會受阻呢），但是也可以選擇指定其最大容量，它是基於鏈表的隊列，此隊列按 FIFO（先進先出）排序元素。
ArrayBlockingQueue在構造時需要指定容量， 並可以選擇是否需要公平性，如果公平參數被設置true，等待時間最長的線程會優先得到處理（其實就是通過將ReentrantLock設置爲true來 達到這種公平性的：即等待時間最長的線程會先操作）。通常，公平性會使你在性能上付出代價，只有在的確非常需要的時候再使用它。它是基於數組的阻塞循環隊 列，此隊列按 FIFO（先進先出）原則對元素進行排序。
PriorityBlockingQueue是一個帶優先級的 隊列，而不是先進先出隊列。元素按優先級順序被移除，該隊列也沒有上限（看了一下源碼，PriorityBlockingQueue是對 PriorityQueue的再次包裝，是基於堆數據結構的，而PriorityQueue是沒有容量限制的，與ArrayList一樣，所以在優先阻塞 隊列上put時是不會受阻的。雖然此隊列邏輯上是無界的，但是由於資源被耗盡，所以試圖執行添加操作可能會導致 OutOfMemoryError），但是如果隊列爲空，那麼取元素的操作take就會阻塞，所以它的檢索操作take是受阻的。另外，往入該隊列中的元 素要具有比較能力。
DelayQueue（基於PriorityQueue來實現的）是一個存放Delayed 元素的無界阻塞隊列，只有在延遲期滿時才能從中提取元素。該隊列的頭部是延遲期滿後保存時間最長的 Delayed 元素。如果延遲都還沒有期滿，則隊列沒有頭部，並且poll將返回null。當一個元素的 getDelay(TimeUnit.NANOSECONDS) 方法返回一個小於或等於零的值時，則出現期滿，poll就以移除這個元素了。此隊列不允許使用 null 元素。
參考自http://blog.sina.com.cn/s/blog_9815359e0102vbet.html
關於隊列的具體解釋和具體使用,這裏分享一個國外的網站(英文比較基礎,大部分能看懂)
http://tutorials.jenkov.com/java-util-concurrent/blockingqueue.html
OK,至此你已經看完了有關線程和線程池的概念以及使用,你會發現上面的文章有很多重複的地方,沒錯,那就是重要的地方。當然這是不夠的,這裏推薦兩篇博文,去看看Executor線程池這個東西到底是怎麼運作的
面試題鏈接
Note
當時看《Androd開發藝術探索》裏分析AsyncTask原理的時候,寫了一下關於子線程不能更新UI的測試代碼
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
textView = (TextView) findViewById(R.id.text);
new Thread(new Runnable() {
@Override
public void run() {
LogUtils.d(String.valueOf(Thread.currentThread().getId()));
textView.setText("2222");
}
}).start();
}發現沒報錯，不正常！
之後聽了QQ羣裏朋友的解答去查閱了有關ViewRootImpl的原理，得出下面結論：
首先View更新的流程爲：
- View.invalidate
- View.invalidateInternal
- ViewGroup.invalidateChild
- ViewParent.invalidateChildInParent
- ViewRootImpl.invalidateChildInParent
- ViewRootImpl.checkThread
public final void invalidateChild(View child, final Rect dirty) {
ViewParent parent = this;
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
......
parent = parent.invalidateChildInParent(location, dirty);
......
}
}ViewGroup.invalidateChild方法中mAttachInfo爲不空時，纔會繼續調用ViewParent.invalidateChildInParent 。如果爲空，下面的流程就不再執行，checkThread 方法也就不會執行，也就不會報錯。
view樹的初始化會在ViewRootImpl的performTraversals開始執行，從DecorView開始遍歷繪製view，同時也在將mAttachInfo賦值，但是onCreate完成時，Activity並沒有完成初始化view樹，所以上面那個情況下mAttachInfo爲空。換句話說就是checkThread 的代碼執行的比你更新UI的代碼要晚.（上面測試代碼加個click或者sleep就會報錯了）
End
原文鏈接：http://www.jianshu.com/p/a79b8765f729#rd
著作權歸作者所有，轉載請聯繫作者獲得授權，並標註“簡書作者”。