首发于公众号: DSGtalk1989
好久不见，值此年终之际，跟大家探讨一下，一个诡异的内存溢出。
羁绊与猜想
话不多说，先上崩溃
java.lang.OutOfMemoryError
pthread_create (1040KB stack) failed: Out of memory
解析原始
1 java.lang.Thread.nativeCreate(Native Method)
2 java.lang.Thread.start(Thread.java:1078)
很显然，创建了一个线程，1040kb，内存溢出。
正好我们比对一下一般的内存溢出的情况是怎样的。
java.lang.OutOfMemoryError
Failed to allocate a 1056012 byte allocation with 801854 free bytes and 783KB until OOM
当再次分配内存的时候出现了内存溢出。
那么我会猜测以上两种情况是否都是内存不够用了，或者说上面的是否和下面的一样是因为内存不够用了引起的。
为什么恰好的创建线程的时候崩溃了，创建线程需要的内存通常不会很大，就真的那么巧，这一根稻草压垮了骆驼？
一笔带过的结论
在此直接吐结论，因为探索pthread_create的内存溢出原因，不是本文的主旨，本文主要探讨是如何斗争。
大家应该都知道，线程创建的越多，资源就消耗的越大，android本身并没有为我们限制应用承受的最大线程数，将控制权交由应用设计者自己。
那么很明显国内的厂商，并不相信国内的开发，或者说国内的厂商由于自己的定制导致你即使遵循了应用的开发之道，却依然难以避免产生大量的冗余线程。
因此华为带头出击，魅族随后，分别将自己的大量机型可控线程数调至500和3000。
如果你深表怀疑或者依然存有困惑，送你如下传送门
仗怎么打
首先我们需要将应用中可能出现的所有与线程相关的地方找到，或者说找出应用中可能会出现线程池的地方。
此处只举个例，不做穷举。
网络请求肯定是首当其冲，如果你使用的市面流行的第三方框架，
Retrofit+Okhttp肯定有默认的线程池问题，如果你在外面还包了一层Rxjava，那么在这一层面还有一个线程池问题。
当然，如果牛逼到自己封装了自己的一套网络请求，那么想必会考虑到多线程的问题，应该如何挑选最合适的线程池来让自己的效率最优。项目是否使用了事件总线，同上，如果你使用了
EventBus，那么这玩意儿帮我们使用了默认的线程池，如果你同样自定义了一套完整的事件总线，那么你也同样需要关注多线程的问题。如果项目较大，很有可能还会有自定义的
Executor，全局搜索一下，看下是如何定义的线程池。
再看Executor
啥都不说，我们从构造方法开始
public ThreadPoolExecutor (int corePoolSize, int maximumPoolSize,
long keepAliveTime, TimeUnit unit,BlockingQueue<Runnable> workQueue)
-
corePoolSize
the number of threads to keep in the pool, even if they are idle, unless {@code allowCoreThreadTimeOut} is set线程池中所保存的核心线程数，包括空闲线程。除非设置了
allowCoreThreadTimeOut属性我们可以直接理解成，当缓冲队列中为空时，线程池中最大允许的线程数量，而且此时，只要有一个任务过来就会新建一个线程，直到达到核心线程数。
-
maximumPoolSize
the maximum number of threads to allow in the pool线程池中允许的最大线程数
你可以理解成线程池中允许的最大同时执行线程数 -
keepAliveTime
when the number of threads is greater than the core, this is the maximum time that excess idle threads will wait for new tasks before terminating.当线程池中的线程数比核心线程数来的多时，空闲线程所能持续的最长时间。
这个讲的比较明确了。 -
unit
the time unit for the {@code keepAliveTime} argument时间单位
-
workQueue
the queue to use for holding tasks before they are executed. This queue will hold only the {@code Runnable} tasks submitted by the {@code execute} method.任务执行前保存任务的队列，仅保存由 execute 方法提交的 Runnable 任务。
-
handler
the handler to use when execution is blocked because the thread bounds and queue capacities are reached当线程越界，且队列阻塞了之后的处理类。
捋顺Executor
当来了一个新的任务
- 我们会首先去看线程池中是否有空闲的线程
- 如果线程池中当前没有线程，创建一个线程执行任务
- 如果当前线程池中线程小于核心线程数，创建一个线程执行任务
- 如果当前线程池中线程数等于核心线程数，将任务放入缓存队列，等待线程执行完毕，就将任务抛到执行完任务的线程执行。
- 如果当前线程池中线程数等于核心线程数，且缓存队列已满，且当前线程池内的线程数量小于最大线程数，那么就创建一个线程出来执行任务
- 如果当前线程池线程数等于最大线程数，那么会触发handler，询问该如何处理超过的线程数，一旦没有创建handler，handler不作处理，则直接抛出未处理异常。
总结来说就是 核心 > 队列 > 非核心 > handler
拿Retrofit开刀
OK，当我们真的搞清楚了，到底Executor是怎么一回事了之后，我们来拿Retrofit1的RestAdapter看一下。
进到RestAdapter的内部类Builder类。
public static class Builder {
...
private void ensureSaneDefaults() {
...
if(this.httpExecutor == null) {
this.httpExecutor = Platform.get().defaultHttpExecutor();
}
}
}
如果你不去专门设置httpExecutor，那么Retrofit就会帮你设置一个默认的，具体是怎样的线程池，我们继续看。
private static class Android extends Platform {
...
Executor defaultHttpExecutor() {
return Executors.newCachedThreadPool(new ThreadFactory() {
public Thread newThread(final Runnable r) {
return new Thread(new Runnable() {
public void run() {
Process.setThreadPriority(10);
r.run();
}
}, "Retrofit-Idle");
}
});
}
...
}
直接去Platform的实现类Android，来找到底defaultHttpExecutor是个啥，一看newCachedThreadPool基本就明了了，使用了系统封装好的缓存线程池，可以再细看一下：
public static ExecutorService newCachedThreadPool(ThreadFactory threadFactory) {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>(),
threadFactory);
}
按照我们上面分析的，核心线程为0个，使用同步队列，SynchronousQueue是没有容量的，此处不做详解，按照目前的逻辑，只要是需要执行的task，一旦put了会立马被take，此处对同步队列不做详解，各位可以自行钻研。可以认为一旦有任务进来，会立马创建新的线程，如果线程空闲60秒就会被干掉。
因此，理论上来说，这个线程池在极端情况下可以产生Integer.MAX_VALUE个线程，那么当这个数字直线上升的时候，就可以看到华为，魅族，相距的崩掉（出于本身ANR的保护，你可能很难看到3000的魅族崩，甚至其他的上万限制的手机崩掉）
因此为了避免此类情况的发生，我们需要给出自定义的线程池方案，你可以选择有限的最大线程数配合SynchronousQueue队列，或者选择有限的最大线程数配合有限容量的BlockingQueue其他实现类。
比如
builder.setExecutors(new ThreadPoolExecutor(2, 20, 20L,
TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(64),
new ThreadPoolExecutor.DiscardOldestPolicy()), null);
各位可以自己摸索钻研到一套最适合自己应用场景的线程池配置。
记住，一旦出现了有上限的线程池，必须要设置溢出策略，上面采用了new ThreadPoolExecutor.DiscardOldestPolicy()方式，该策略会当线程池溢出时，抛掉缓存队列中最先进去的那个，插入新来的。
后记
优化线程数，远远不止于此。
再比如不同的api域名，通常我们需要创建不同的Retrofit对象，而不同的Retrofit对象，都需要进行初始化，传入不同的OkhttpClient和相同的OkhttpClient也会有很大的线程数差距。
重要的还是在平时的编码过程中，善于观察，善于测试，善于从崩溃日志中过滤无用信息，定位到线程崩溃点。
最后，为无法理解华为的线程限制抓耳挠腮10分钟。
