1. 线程池优化

[toc]

1.1. 一、线程池

线程池避免存在大量的Thread，重用线程池内部的线程，从而避免了线程的创建和销毁带来的性能开销，同时能有效控制线程池的最大并发数，避免大量线程因互相抢占系统资源而导致阻塞线现象发生。

1.1.1. 1.1 分类

FixedThreadPool 数量固定的线程池
CachedThreadPool 只有非核心线程，数量不定，空闲线程有超时机制，比较适合执行大量耗时较少的任务
ScheduledThreadPool 核心线程数量固定，非核心线程没有限制。主要用于执行定时任务和具有固定中周期的重复任务。
SingleThreadPool 只有一个核心线程，确保所有的任务在同一个线程顺序执行，统一外界任务到一个线程中，这使得在这些任务之间不需要处理线程同步的问题。

1.1.2. 1.2 优点

减少在创建和销毁线程上所花的时间以及系统资源的开销
不使用线程池有可能造成系统创建大量的线程而导致消耗完系统内存以及"过度切换"

1.1.3. 1.3 注意点

如果线程池中的数量未达到核心线程的数量,则直接启动一个核心线程来执行任务
如果线程池中的数量已经达到或超过核心线程的数量,则任何会被插入到任务队列中等待执行
如果2中的任务无法插入到任务队列中,由于任务队列已满,这时候如果线程数量未达到线程池规定的最大值,则会启动一个非核心线程来执行任务
如果3中的线程数量已经达到线程池最大值,则会拒绝执行此任务,ThreadPoolExecutor会调用RejectedExecutionHandler的rejectedExecution()方法通知调用者

1.2. 二、通过线程提升性能

善于在 Android 上利用线程可以帮助您提升应用的性能。本页从以下几个方面讨论线程的使用：使用界面线程（即主线程）；应用生命周期与线程优先级之间的关系；以及平台为帮助管理线程复杂性所提供的方法。对于每个方面，本页都介绍了潜在的陷阱和相应的规避策略。

1.2.1. 2.1 主线程

当用户启动您的应用时，Android 会创建新的 Linux 进程以及执行线程。这个主线程也称为界面线程，负责屏幕上发生的一切活动。了解其工作原理有助于您通过设计让应用利用主线程实现最佳性能。

2.1.1 内部原理

主线程的设计非常简单：它的唯一工作就是从线程安全工作队列获取工作块并执行，直到应用被终止。框架会从多个位置生成部分工作块。这些位置包括与生命周期信息、用户事件（例如输入）或来自其他应用和进程的事件相关的回调。此外，应用也可以不使用框架而自行对块进行明确排队。

应用执行的任何代码块几乎都与事件回调（例如输入、布局扩充或绘制）相关联。当某个操作触发事件时，发生了事件的线程会将事件从线程本身里推送到主线程的消息队列中。然后，主线程可以为事件提供服务。

当有动画或屏幕更新正在进行时，系统会每隔 16ms 左右尝试执行一个工作块（负责绘制屏幕），从而以每秒 60 帧的流畅速度进行渲染。要使系统达到此目标，界面/视图层次结构必须在主线程上更新。但是，如果主线程的消息队列中的任务太多或太长，导致主线程无法足够快地完成更新，那么应用应将此工作移至工作线程。如果主线程无法在 16ms 内执行完工作块，则用户可能会察觉到卡顿、延迟或界面对输入无响应。如果主线程阻塞大约 5 秒，系统会显示“应用无响应”(ANR) 对话框，允许用户直接关闭应用。

将大量或冗长的任务从主线程中移出，使其不影响流畅渲染和快速响应用户输入，这是您在应用中采用线程处理的最大原因。

1.2.2. 2.2 线程和界面对象引用

根据设计，Android 视图对象不是线程安全的。无论是创建、使用还是销毁界面对象，应用都应在主线程上完成。如果您尝试在主线程以外的其他线程中修改甚至引用界面对象，则可能导致异常、无提示故障、崩溃以及其他未定义的异常行为。

引用方面的问题分为两类：显式引用和隐式引用。

2.2.1 显式引用

非主线程上的许多任务的最终目标是更新界面对象。但是，如果其中一个线程访问视图层次结构中的某个对象，则可能导致应用不稳定：如果工作线程更改该对象的属性，与此同时有任何其他线程正在引用该对象，则结果无法确定。

例如，假设某个应用在工作线程上直接引用了界面对象。工作线程上的该对象可能包含对 View 的引用；但在工作完成之前，View 已从视图层次结构中移除。当这两个操作同时发生时，该引用会将 View 对象保留在内存中，并对其设置属性。但是，用户从不会看到此对象，而且应用会在对象引用消失后删除该对象。

再举一个例子，假设 View 对象包含对其所属的 Activity 的引用。如果该 Activity 被销毁，但仍有直接或间接引用它的线程处理工作块，则垃圾回收器会等到该工作块执行完毕再收集该 Activity。

如果在线程处理工作的执行过程中发生某个 Activity 生命周期事件（例如屏幕旋转），这种情况可能会导致问题。在执行中的工作完成之前，系统将无法执行垃圾回收。因此，等到可以进行垃圾回收时，内存中可能有两个 Activity 对象。

在这类情况下，我们建议您不要在应用的线程处理工作任务中包含对界面对象的显式引用。避免此类引用有助于防止这些类型的内存泄漏，同时避开线程处理争用。

在任何情况下，应用都只应在主线程上更新界面对象。这意味着您应制定允许多个线程将工作传回主线程的协商政策，让最顶层的 Activity 或 Fragment 负责更新实际界面对象。

2.2.2 隐式引用

以下代码段演示了线程处理对象的常见代码设计缺陷：

KOTLIN JAVA

    public class MainActivity extends Activity {
      // ...
      public class MyAsyncTask extends AsyncTask<Void, Void, String>   {
        @Override protected String doInBackground(Void... params) {...}
        @Override protected void onPostExecute(String result) {...}
      }
    }

此代码段的缺陷在于，代码会将线程处理对象 MyAsyncTask 声明为某个 Activity 的非静态内部类（或 Kotlin 中的内部类）。此声明会创建对封装 Activity 实例的隐式引用。因此，在线程处理工作完成之前，该对象一直包含对相应 Activity 的引用，导致所引用 Activity 的销毁出现延迟。这种延迟进而会给内存带来更多压力。

此问题的直接解决方法是将过载的类实例定义为静态类，或在其自己的文件中定义，从而移除隐式引用。

另一个解决方法是将 AsyncTask 对象声明为静态嵌套类（或在 Kotlin 中移除内部限定符）。这样做可以消除隐式引用问题，因为静态嵌套类与内部类有所不同：内部类的实例要求对外部类的实例进行实例化，并且可直接访问封装实例的方法和字段。相反，静态嵌套类不需要引用封装类的实例，因此它不包含对外部类成员的引用。

KOTLIN JAVA

    public class MainActivity extends Activity {
      // ...
      static public class MyAsyncTask extends AsyncTask<Void, Void, String>   {
        @Override protected String doInBackground(Void... params) {...}
        @Override protected void onPostExecute(String result) {...}
      }
    }

1.2.3. 2.3 线程和应用 Activity 生命周期

应用生命周期会影响线程处理在应用中的工作方式。您可能需要确定线程在 Activity 销毁后应不应该保留。您还应注意线程优先级与 Activity 是在前台运行还是在后台运行之间的关系。

2.3.1 保留线程

线程会在生成这些线程的 Activity 的生命周期过后继续保留。无论是否发生 Activity 创建或销毁事件，线程都会继续不间断地执行。在某些情况下，这种持久性是可取的。

假设某个 Activity 生成了一组线程处理工作块，然后在工作线程能执行工作块之前被销毁。应用应如何处理正在执行的工作块？

如果工作块将要更新不再存在的界面，则该工作不必再继续。例如，如果该工作是从数据库加载用户信息，然后更新视图，则不再需要该线程。

相比之下，工作数据包可能具有某种不完全与界面相关的优势。在这种情况下，您应该保留该线程。例如，数据包可能正在等待下载图片，将其缓存到磁盘并更新关联的 View 对象。虽然该对象已不存在，但是下载和缓存该图片可能仍然有用，以防用户返回到已销毁的 Activity。

为所有线程处理对象手动管理生命周期响应可能极其复杂。如果管理不当，应用可能会遇到内存争用和性能问题。您可以结合使用 ViewModel 和 LiveData 加载数据并在数据发生更改时收到通知，而不用关心生命周期。ViewModel 对象是此问题的一种解决方案。ViewModel 会在配置更改后保持不变，便于您保留视图数据。要详细了解 ViewModel 和 LiveData，请分别参阅 ViewModel 指南和 LiveData 指南。如果您还想详细了解应用架构，请参阅应用架构指南。

2.3.2 线程优先级

进程和应用生命周期中介绍过，应用线程的优先级一定程度上取决于应用处于生命周期的哪个阶段。在应用中创建和管理线程时，请务必设置线程的优先级，以便正确的线程适时获得正确的优先级。如果设置得过高，您的线程可能会干扰界面线程和 RenderThread，导致应用掉帧。如果设置得过低，可能会导致异步任务（例如图片加载）达不到所需的速度。

每次创建线程时，都应调用 setThreadPriority()。系统的线程调度程序会优先考虑优先级较高的线程，在这些优先级与最终将所有工作都完成的需求之间做出权衡。一般来说，前台组约占设备总执行时间的 95%，而后台组约占 5%。

系统还会使用 Process 类为每个线程分配系统自己的优先级值。

默认情况下，系统会将线程的优先级设置为与生成它的线程具有相同的优先级和组成员资格。但是，您的应用可以使用 setThreadPriority() 明确调整线程优先级。

Process 类提供了一组可供您的应用设置线程优先级的常量，以帮助简化优先级值的分配。例如，THREAD_PRIORITY_DEFAULT 代表线程的默认值。如果线程执行的工作不太紧急，应用应将线程的优先级设为 THREAD_PRIORITY_BACKGROUND。

应用可以使用 THREAD_PRIORITY_LESS_FAVORABLE 和 THREAD_PRIORITY_MORE_FAVORABLE 常量作为增量器来设置相对优先级。如需线程优先级的列表，请参阅 Process 类中的 THREAD_PRIORITY 常量。

如需详细了解如何管理线程，请参阅有关 Thread 和 Process 类的参考文档。

Android系统会根据当前运行的可见的程序和不可见的后台程序对线程进行归类，划分为forground的那部分线程会大致占用掉CPU的90%左右的时间片，background的那部分线程就总共只能分享到5%-10%左右的时间片。之所以设计成这样是因为forground的程序本身的优先级就更高，理应得到更多的执行时间。

默认情况下，新创建的线程的优先级默认和创建它的母线程保持一致。如果主UI线程创建出了几十个工作线程，这些工作线程的优先级就默认和主线程保持一致了，为了不让新创建的工作线程和主线程抢占CPU资源，需要把这些线程的优先级进行降低处理，这样才能给帮组CPU识别主次，提高主线程所能得到的系统资源。

在Android系统里面，我们可以通过android.os.Process.setThreadPriority(int)设置线程的优先级，参数范围从-20到24，数值越小优先级越高。Android系统还为我们提供了以下的一些预设值，我们可以通过给不同的工作线程设置不同数值的优先级来达到更细粒度的控制。

大多数情况下，新创建的线程优先级会被设置为默认的0，主线程设置为0的时候，新创建的线程还可以利用THREAD_PRIORITY_LESS_FAVORABLE或者THREAD_PRIORITY_MORE_FAVORABLE来控制线程的优先级。

1.2.4. 2.4 线程处理的辅助类

框架提供了相同的 Java 类和基元来方便线程处理，例如 Thread、Runnable 和 Executors 类。为了帮助减轻与开发适用于 Android 的线程处理应用相关的认知负荷，框架提供了一组可协助开发的辅助程序，例如 AsyncTaskLoader 和 AsyncTask。每个辅助类都有一组特定的性能细微差别，专用于解决一小部分特定的线程处理问题。将错误的类用在错误的场合可能会导致性能问题。

2.4.1 AsyncTask 类

对于需要快速将工作从主线程移动到工作线程的应用来说，AsyncTask 类是一个简单实用的基元。例如，输入事件可能会触发使用加载的位图更新界面的需求。AsyncTask 对象可以将位图加载和解码分流到备用线程；处理完成后，AsyncTask 对象可以设法回到主线程上接收工作以更新界面。

在使用 AsyncTask 时，请注意以下几个性能方面的要点。首先，默认情况下，应用会将其创建的所有 AsyncTask 对象推送到单个线程中。因此，它们按顺序执行，而且与主线程一样，特别长的工作数据包可能会阻塞队列。鉴于这个原因，我们建议您仅使用 AsyncTask 处理持续时间短于 5ms 的工作项。

对于隐式引用问题，AsyncTask 对象也是最常见的诱因。AsyncTask 对象也会带来与显式引用相关的风险，但这些风险有时更容易解决。例如，AsyncTask 可能需要引用某个界面对象，以便 AsyncTask 在主线程上执行其回调后正确更新该界面对象。在这种情况下，您可以使用 WeakReference 存储对所需界面对象的引用，并在 AsyncTask 在主线程上运行后访问该对象。注意，保留对一个对象的 WeakReference 不会使该对象变为线程安全；WeakReference 仅提供一种处理显式引用和垃圾回收问题的方法。

为UI线程与工作线程之间进行快速的切换提供一种简单便捷的机制。适用于当下立即需要启动，但是异步执行的生命周期短暂的使用场景。它提供了一种简便的异步处理机制，但是它又同时引入了一些令人厌恶的麻烦。一旦对AsyncTask使用不当，很可能对程序的性能带来负面影响，同时还可能导致内存泄露。(关于内存泄漏在上面已经讲过)

使用AsyncTask需要注意的问题?

(1).在AsyncTask中所有的任务都是被线性调度执行的，他们处在同一个任务队列当中，按顺序逐个执行。一旦有任务执行时间过长，队列中其他任务就会阻塞。

对于上面的问题，我们可以使用AsyncTask.executeOnExecutor()让AsyncTask变成并发调度。

(2).AsyncTask对正在执行的任务不具备取消的功能，所以我们要在任务代码中添加取消的逻辑（和上面Thread类似）

(3).AsyncTask使用不当会导致内存泄漏（可以参考内存泄漏一章）

2.4.2 HandlerThread 类

虽然 AsyncTask 很有用，但对您的线程处理问题来说，它可能并不一定是正确的解决方案。相反，您可能需要采用更传统的方法在更长时间运行的线程上执行工作块，并且能够手动管理该工作流。

想一想从您的 Camera 对象获取预览帧时遇到的常见问题。当您注册 Camera 预览帧时，您会在 onPreviewFrame() 回调中收到这些帧，该回调在调用了它的事件线程上被调用。如果该回调是在界面线程上调用的，则处理大型像素矩阵的任务会干扰渲染和事件处理工作。AsyncTask 也存在同样的问题，它也是按顺序执行作业，并且容易出现阻塞。

这种情况适合采用处理程序线程：处理程序线程实际上是一个长时间运行的线程，会从队列中抓取工作并对其进行操作。在此示例中，当您的应用将 Camera.open() 命令委托给处理程序线程上的工作块时，关联的 onPreviewFrame() 回调会进入处理程序线程，而不是界面或 AsyncTask 线程。因此，如果要对像素执行长时间运行的工作，这可能是更好的解决方案。

当您的应用使用 HandlerThread 创建线程时，别忘了根据线程正在执行的工作类型设置其优先级。请记住，CPU 只能并行处理少量线程。设置优先级有助于系统了解当所有其他线程都在争取关注时调度此工作的正确方法。

为某些回调方法或者等待某些任务的执行设置一个专属的线程，并提供线程任务的调度机制。先来了解下Looper，Handler，MessageQueue Looper: 能够确保线程持续存活并且可以不断的从任务队列中获取任务并进行执行。 Handler: 能够帮助实现队列任务的管理，不仅仅能够把任务插入到队列的头部，尾部，还可以按照一定的时间延迟来确保任务从队列中能够来得及被取消掉。 MessageQueue: 使用Intent，Message，Runnable作为任务的载体在不同的线程之间进行传递。把上面三个组件打包到一起进行协作，这就是HandlerThread

我们先来看下源码：

    public class HandlerThread extends Thread {
        public HandlerThread(String name, int priority) {
            super(name);
            mPriority = priority;
        }

        @Override
        public void run() {
            mTid = Process.myTid();
            Looper.prepare();
            synchronized (this) {
                mLooper = Looper.myLooper();
                notifyAll();
            }
            Process.setThreadPriority(mPriority);
            onLooperPrepared();
            Looper.loop();
            mTid = -1;
        }

        public Looper getLooper() {
            if (!isAlive()) {
                return null;
            }
            // If the thread has been started, wait until the looper has been created.
            synchronized (this) {
                while (isAlive() && mLooper == null) {
                    try {
                        wait();
                    } catch (InterruptedException e) {
                    }
                }
            }
            return mLooper;
        }
    }

从上面的源码发现，HandlerThread其实就是在线程中维持一个消息循环队列。下面我们看下使用：

    HandlerThread mHanderThread = new HandlerThread("hanlderThreadTest", Process.THREAD_PRIORITY_BACKGROUND);
    mHanderThread.run();
    Looper mHanderThreadLooper = mHanderThread.getLooper();

    Handler mHandler = new Handler(mHanderThreadLooper){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            //子线程中执行
            ...
        }
    };
    //发送消息
    mHandler.post(new Runnable() {
        @Override
        public void run() {
            ...
        }
    });

2.4.3 ThreadPoolExecutor 类

某些类型的工作可以简化为高度并行的分布式任务。例如，为 800 万像素图片的每个 8x8 块计算滤镜就是这样的一个任务。鉴于这会创建大量的工作数据包，AsyncTask 和 HandlerThread 类并不合适。具有单线程处理特性的 AsyncTask 会将所有线程池化的工作转化为一个线性系统。另一方面，使用 HandlerThread 类需要程序员在一组线程之间手动实现负载平衡。

ThreadPoolExecutor 是一个可简化此过程的辅助类。这个类可用于管理一组线程的创建，设置其优先级，并管理工作在这些线程之间的分布情况。随着工作负载的增减，该类会创建或销毁更多线程以适应工作负载。

该类还可帮助您的应用生成最佳数量的线程。构造 ThreadPoolExecutor 对象时，应用会设置最小和最大线程数。随着 ThreadPoolExecutor 上的工作负载不断增加，该类会考虑初始化的最小和最大线程计数，并考虑待处理工作量。ThreadPoolExecutor 根据这些因素决定在任何特定时间应保留多少线程。

2.4.4 您应该创建多少线程？

尽管在软件层面上，您的代码可以创建数百个线程，但这样做会导致性能问题。您的应用与后台服务、渲染程序、音频引擎、网络等共享有限的 CPU 资源。CPU 实际上只能并行处理少量线程；一旦超限便会遇到优先级和调度问题。因此，务必要根据工作负载需求创建合适数量的线程。

实际操作起来，这一决定取决于很多变量，但是可以选择一个值（例如首先选择 4 个），并使用 Systrace 进行测试，这个策略跟任何其他策略一样可靠。您可以采用试错法得出最少要将线程数减至多少才不至于遇到问题。

在决定创建多少个线程时，还需要考虑到线程不是免费的，它们会占用内存。每个线程至少需要占用 64k 内存。设备上安装的众多应用会使这一数字迅速累加，特别是在调用堆栈显著扩大的情况下。

许多系统进程和第三方库经常会创建自己的线程池。如果您的应用可以重复使用现有线程池，则可以减少内存和处理资源争用，从而帮助提高性能。

在程序开发的实践当中，为了让程序表现得更加流畅，我们肯定会需要使用到多线程来提升程序的并发执行性能。但是编写多线程并发的代码一直以来都是一个相对棘手的问题，所以想要获得更佳的程序性能，非常有必要掌握多线程并发编程的基础技能。

2.4.5 IntentService

适合于执行由UI触发的后台Service任务，并可以把后台任务执行的情况通过一定的机制反馈给UI。默认的Service是执行在主线程的，可是通常情况下，这很容易影响到程序的绘制性能(抢占了主线程的资源)。除了前面介绍过的AsyncTask与HandlerThread，我们还可以选择使用IntentService来实现异步操作。IntentService继承自普通Service同时又在内部创建了一个HandlerThread，在onHandlerIntent()的回调里面处理扔到IntentService的任务。所以IntentService就不仅仅具备了异步线程的特性，还同时保留了Service不受主页面生命周期影响的特点。

使用IntentService需要特别注意的点：

(1).因为IntentService内置的是HandlerThread作为异步线程，所以每一个交给IntentService的任务都将以队列的方式逐个被执行到，一旦队列中有某个任务执行时间过长，那么就会导致后续的任务都会被延迟处理。

(2).通常使用到IntentService的时候，我们会结合使用BroadcastReceiver把工作线程的任务执行结果返回给主UI线程。使用广播容易引起性能问题，我们可以使用LocalBroadcastManager来发送只在程序内部传递的广播，从而提升广播的性能。我们也可以使用runOnUiThread()快速回调到主UI线程。

(3).包含正在运行的IntentService的程序相比起纯粹的后台程序更不容易被系统杀死，该程序的优先级是介于前台程序与纯后台程序之间的。

2.4.6 Loader

对于3.0后ContentProvider中的耗时操作，推荐使用Loader异步加载数据机制。相对其他加载机制，Loader有那些优点呢？

提供异步加载数据机制
对数据源变化进行监听，实时更新数据
在Activity配置发生变化（如横竖屏切换）时不用重复加载数据
适用于任何Activity和Fragment

下面我们来看下Loader的具体使用：我们以获得手机中所有的图片为例：

    getLoaderManager().initLoader(LOADER_TYPE, null, mLoaderCallback);
    LoaderManager.LoaderCallbacks<Cursor> mLoaderCallback = new LoaderManager.LoaderCallbacks<Cursor>() {
        private final String[] IMAGE_COLUMNS={
                MediaStore.Images.Media.DATA,//图片路径
                MediaStore.Images.Media.DISPLAY_NAME,//显示的名字
                MediaStore.Images.Media.DATE_ADDED,//添加时间
                MediaStore.Images.Media.MIME_TYPE,//图片扩展类型
                MediaStore.Images.Media.SIZE,//图片大小
                MediaStore.Images.Media._ID,//图片id
        };

        @Override
        public Loader<Cursor> onCreateLoader(int id, Bundle args) {
            toggleShowLoading(true,getString(R.string.common_loading));

            CursorLoader cursorLoader = new CursorLoader(ImageSelectActivity.this,                 MediaStore.Images.Media.EXTERNAL_CONTENT_URI,IMAGE_COLUMNS,
                    IMAGE_COLUMNS[4] + " > 0 AND "+IMAGE_COLUMNS[3] + " =? OR " +IMAGE_COLUMNS[3] + " =? ",
                    new String[]{"image/jpeg","image/png"},IMAGE_COLUMNS[2] + " DESC");
            return cursorLoader;
        }

        @Override
        public void onLoadFinished(Loader<Cursor> loader, Cursor data) {
            if(data != null && data.getCount() > 0){
                ArrayList<String> imageList = new ArrayList<>();

                if(mShowCamera){
                    imageList.add("");
                }
                while (data.moveToNext()){
                    String path = data.getString(data.getColumnIndexOrThrow(IMAGE_COLUMNS[0]));
                    imageList.add(path);
                    Log.e("ImageSelect", "IIIIIIIIIIIIIIIIIIII=====>"+path);
                }
                //显示数据
                showListData(imageList);
                toggleShowLoading(false,getString(R.string.common_loading));
            }
        }

        @Override
        public void onLoaderReset(Loader<Cursor> loader) {  
        }

onCreateLoader() 实例化并返回一个新创建给定ID的Loader对象 onLoadFinished() 当创建好的Loader完成了数据的load之后回调此方法 onLoaderReset() 当创建好的Loader被reset时调用此方法，这样保证它的数据无效 LoaderManager会对查询的操作进行缓存，只要对应Cursor上的数据源没有发生变化，在配置信息发生改变的时候(例如屏幕的旋转)，Loader可以直接把缓存的数据回调到onLoadFinished()，从而避免重新查询数据。另外系统会在Loader不再需要使用到的时候(例如使用Back按钮退出当前页面)回调onLoaderReset()方法，我们可以在这里做数据的清除等等操作。

2.4.7 ThreadPool

把任务分解成不同的单元，分发到各个不同的线程上，进行同时并发处理。线程池适合用在把任务进行分解，并发进行执行的场景。系统提供ThreadPoolExecutor帮助类来帮助我们简化实现线程池。

使用线程池需要特别注意同时并发线程数量的控制，理论上来说，我们可以设置任意你想要的并发数量，但是这样做非常的不好。因为CPU只能同时执行固定数量的线程数，一旦同时并发的线程数量超过CPU能够同时执行的阈值，CPU就需要花费精力来判断到底哪些线程的优先级比较高，需要在不同的线程之间进行调度切换。一旦同时并发的线程数量达到一定的量级，这个时候CPU在不同线程之间进行调度的时间就可能过长，反而导致性能严重下降。另外需要关注的一点是，每开一个新的线程，都会耗费至少64K+的内存。为了能够方便的对线程数量进行控制，ThreadPoolExecutor为我们提供了初始化的并发线程数量，以及最大的并发数量进行设置。

    /**
     * 核心线程数
     * 最大线程数
     * 保活时间
     * 时间单位
     * 任务队列
     * 线程工厂
     */
    threadPoolExecutor = new ThreadPoolExecutor(
            CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE_SECONDS, TimeUnit.SECONDS,
            linkedBlockingQueue, sThreadFactory);
    threadPoolExecutor.execute(runnable);

我们知道系统还提供了Executors类中几种线程池，下面我们来看下这些线程池的缺点：

newFixedThreadPool 和 newSingleThreadExecutor:主要问题是堆积的请求处理队列可能会耗费非常大的内存，甚至 OOM。 newCachedThreadPool 和 newScheduledThreadPool:主要问题是线程数最大数是 Integer.MAX_VALUE，可能会创建数量非常多的线程，甚至 OOM

我们看到这些线程池但是有缺点的，所以具体使用那种方式实现要根据我们的需求来选择。

如果想要避开上面的问题，可以参考OKHttp中线程池的实现，OKHttp中队线程调度又封装了一层，使用安全且方便，有兴趣的可以去看看源码。

1.3. 三、 Thread 使用

Thread使用需要注意的点：

1.3.1. 3.1 Thread 中断

常用的有两种方式：

(1).通过抛出InterruptedException来中断线程

    public  static  class  MyThread extends Thread{
        private  int count=0;
        @Override
        public void run() {
            super.run();
            try{
                while(true){
                        count++;
                        System.out.println("count value:"+count);
                        if (this.interrupted() || this.isInterrupted()){
                            System.out.println("check interrupted show!");
                            throw new InterruptedException();
                        }
                }
            }catch ( InterruptedException e) {
                System.out.println("thread is stop!");
                e.printStackTrace();
            }
        }

    }

(2).通过变量来中断（常用）

    public  static  class  CustomThread extends Thread{
        private  int count=0;
        private boolean isCancel = false;
        @Override
        public void run() {
            super.run();
            while(!isCancel){
                    count++;
                    System.out.println("count value:"+count);
            }
        }

        public synchronized void cancel(){
            isCancel = true;
        }
    }

1.3.2. 3.2 同步

分变量同步和代码块同步两个方面来讲解

(1).变量同步

使用volatile关键字

    /**
     * 主内存和线程内存缓存进行同步
     */
    volatile int val = 5;
    public int getVal() {
        return val;
    }
    public void setVal(int val) {
        this.val = val;
    }

使用synchronized关键字

    int val2 = 5;
    /**
     * 使用一个motinor来监听（实现资源由一个线程进行操作）
     * 主内存和线程内存缓存进行同步
     * @return
     */
    public synchronized int getVal2() {
        return val2;
    }
    public synchronized int setVal2(int val) {
        this.val2 = val;
    }

使用关键字AtomicXXXXX

    AtomicInteger mAtomicValue = new  AtomicInteger(0);
    public void setAtomicValue(int value){
        mAtomicValue.getAndSet(value);
    }
    public int getAtomicValue(){
        return mAtomicValue.get();
    }

(2).代码块同步

代码块同步分乐观锁和悲观锁来讲解

使用悲观锁时，其他线程等待，进入睡眠，频繁切换任务，消耗cpu资源

    synchronized (this) {
        .....   
    }

使用乐观锁时，失败重试，避免任务重复切换，减少cpu消耗

    ReentrantLock lock = new  ReentrantLock();
    lock.lock();
    ......
    lock.unlock();

14.线程优化

1. 线程池优化

1.1. 一、线程池

1.1.1. 1.1 分类

1.1.2. 1.2 优点

1.1.3. 1.3 注意点

1.2. 二、通过线程提升性能

1.2.1. 2.1 主线程

2.1.1 内部原理

1.2.2. 2.2 线程和界面对象引用

2.2.1 显式引用

2.2.2 隐式引用

1.2.3. 2.3 线程和应用 Activity 生命周期

2.3.1 保留线程

2.3.2 线程优先级

1.2.4. 2.4 线程处理的辅助类

2.4.1 AsyncTask 类

2.4.2 HandlerThread 类

2.4.3 ThreadPoolExecutor 类

2.4.4 您应该创建多少线程？

2.4.5 IntentService

2.4.6 Loader

2.4.7 ThreadPool

1.3. 三、 Thread 使用

1.3.1. 3.1 Thread 中断

1.3.2. 3.2 同步

1.4. 参考

results matching ""

No results matching ""

1. 线程池优化

1.1. 一、 线程池

1.1.1. 1.1 分类

1.1.2. 1.2 优点

1.1.3. 1.3 注意点

1.2. 二、 通过线程提升性能

1.2.1. 2.1 主线程

2.1.1 内部原理

1.2.2. 2.2 线程和界面对象引用

2.2.1 显式引用

2.2.2 隐式引用

1.2.3. 2.3 线程和应用 Activity 生命周期

2.3.1 保留线程

2.3.2 线程优先级

1.2.4. 2.4 线程处理的辅助类

2.4.1 AsyncTask 类

2.4.2 HandlerThread 类

2.4.3 ThreadPoolExecutor 类

2.4.4 您应该创建多少线程？

2.4.5 IntentService

2.4.6 Loader

2.4.7 ThreadPool

1.3. 三、 Thread 使用

1.3.1. 3.1 Thread 中断

1.3.2. 3.2 同步

1.4. 参考

results matching ""

No results matching ""

1.1. 一、线程池

1.2. 二、通过线程提升性能