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 著做权归做者全部，转载请联系做者得到受权，并标注“简书做者”。