Android線程,線程池使用及原理博文參考

經過如下文章的閱讀，相信你對android的線程,線程池以及原理會有更加深入的理解

這塊的知識能夠說是一大塊,要擼清楚仍是要花點時間,線程池中關聯到的隊列不只在線程池中使用,在各類第三方網絡框架和圖片框架等等中也是經過本身調度隊列來實現異步。有關理論的東西"前人"寫的好文章太多了,因此也不必再去複製粘貼來寫一篇博文（文章結尾連接一個有關線程和線程池的面試題）

仍是先回顧下Handler消息機制的原理圖

Handler消息機制

一樣的仍是先看看一篇對《Android開發藝術探索》的總結，對線程和線程池有個大體的瞭解（建議和源碼一塊兒看）
Android開發藝術探索 第11章 線程與線程池 讀書筆記

上面的文章講的只是基本概念，仍是要看看稍微詳細的文章
線程、多線程與線程池總結

在AsyncTask源碼中有使用到Callable、Future和FutureTask，對這個概念不清楚的不妨看看這篇博客
Java併發編程：Callable、Future和FutureTask

針對書中講到的AsyncTask附上一張AsyncTask工做原理圖(結合源代碼理解)

AsyncTask工做原理

不過不建議使用AsyncTask，由於4.x系統中AsyncTask是串行的，高併發的Task讓AsyncTask一個一個串行執行，程序就會很慢。能夠看看這篇譯文講解具體緣由

譯文：Android中糟糕的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線程池這個東西究竟是怎麼運做的

戲（細）說Executor框架線程池任務執行全過程（上）

戲（細）說Executor框架線程池任務執行全過程（下）

面試題連接

JAVA多線程和併發基礎面試問答

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

 

文／miaoyongjun（簡書做者） 原文連接：http://www.jianshu.com/p/a79b8765f729 著做權歸做者全部，轉載請聯繫做者得到受權，並標註「簡書做者」。