About ExecutorService（1），Future&FutureTask
About ExecutorService（2），自定义线程池
About ExecutorService（3），我所认识的AsyncTask
About ExecutorService（4），AsyncTask番外篇
这些小知识点作为AT的番外篇再适合不过了。
直接切入正题，我们都知道AT在3.X将默认的线程池由并行改为串行，真的是众所周知的3.0（HONEYCOMB）开始的嘛？答案是否定的。确切的说是从3.2（HONEYCOMB_MR1）起。
我们拿Android-22举个例子，根据路径打开，
// If the app is Honeycomb MR1 or earlier, switch its AsyncTask
// implementation to use the pool executor. Normally, we use the
// serialized executor as the default. This has to happen in the
// main thread so the main looper is set right .
if (data.appInfo.targetSdkVersion <= android.os.Build.VERSION_CODES.HONEYCOMB_MR1) {
/*设置默认线程池*/
AsyncTask.setDefaultExecutor(AsyncTask.THREAD_POOL_EXECUTOR);
}
接下来我们只需要对照android.os.Build.VERSION_CODES，找到HONEYCOMB_MR1代表哪个版本就OK了。
由此便可得出结论，3.2及其之后，AT的线程池使用串行代替并行。
但是......
前两天做消息推送的时候需要使用一些Android的Compat（兼容）包或类。于是今天好奇的想看看AT有没有兼容包或者类，于是就发现了这个AsyncTaskCompat类，这个类的主要功能就是提供一个并行线程池的AT（Parallel：并行）。位于
代码很简短，如下：
/**
* Helper for accessing features in {@link android.os.AsyncTask}
* introduced after API level 4 in a backwards compatible fashion.
*/
public class AsyncTaskCompat {
/**
* Executes the task with the specified parameters, allowing multiple tasks to run in parallel
* on a pool of threads managed by {@link android.os.AsyncTask}.
*
* @param task The {@link android.os.AsyncTask} to execute.
* @param params The parameters of the task.
* @return the instance of AsyncTask.
*/
public static AsyncTask executeParallel(
AsyncTask task,
Params... params) {
if (task == null) {
throw new IllegalArgumentException("task can not be null");
}
if (Build.VERSION.SDK_INT >= 11) {
// From API 11 onwards, we need to manually select the THREAD_POOL_EXECUTOR
AsyncTaskCompatHoneycomb.executeParallel(task, params);
} else {
// Before API 11, all tasks were run in parallel
task.execute(params);
}
return task;
}
}
接下来：
这段代码的注释与ActivityThread中代码的注释有冲突，之前明确指出只有13及其之后才会使用串行线程池代替并行。个人观点更倾向于这样，显得规范一些：
if (Build.VERSION.SDK_INT >= 13) {
// From API 13 onwards, we need to manually select the THREAD_POOL_EXECUTOR
AsyncTaskCompatHoneycomb.executeParallel(task, params);
} else {
// Before API 13, all tasks were run in parallel
task.execute(params);
}
虽然之前的写法并没有错，但很容易给开发者带来困惑。
既然这里又提到了并发，就不得不提一下有关“锁”的优化，确切的说是AT中“锁”的优化。
多核时代的来临，使用多线程可以显著提高系统的性能，但是，单线程真的“一无是处”了吗，答案依然是否定的，对于那些单线程或者单任务的程序来说，主要资源都消耗在任务本身，既不需要维护并行数据结构间的一致性状态，也不需要为线程的切换和调度花费不必要的时间，而且，对于多线程而言，系统除了处理任务外，还需要维护多线程环境的特有信息，比如：线程本身的数据元，线程调度，甚至是线程上下文的切换等。
事实上，在单核CPU（然而单核mobile并没有什么卵用）上，采用并行算法的效率一般要低于原始的串行算法。因此，并行计算之所以能够提高系统的性能，并不是因为线程偷懒，少干活，而是因为并行计算可以更合理的进行任务调度。所以，合理的并发，才能将多核CPU（真·八核？！）的性能发挥效果。
然而，在多核，多线程，多任务时代，为了保证数据的同步，“锁”扮演着不可或缺的角色。优雅的异步，并行，并发等算法结构，都离不开“锁”，然而，激烈的锁竞争又会导致程序性能的下降。
因此，在使用“锁”的时候，我们也应该尽量考虑以下几点：
-
减少锁持有时间
只在必要时进行同步，这样就能明显减少线程持有锁的时间，提高系统的吞吐量
-
减小锁粒度
缩小锁定对象的范围，从而减少锁冲突的可能性，进而提高系统的并发能力，例如ConcurrentHashMap的桶锁机制。
-
重用锁（
ReentrantLock）代替内部锁（synchronized）
重用锁提供了很多内部锁不具备的强大功能，比如锁等待时间（ boolean tryLock(long timeout, TimeUnit unit)）、支持中断锁（void lockInterruptibly( )）等，这些API有助于避免死锁，提高系统稳定性，使用ReentrantLock一定要注意在finally中释放。
-
粗化锁
这个解释起来比较笼统，与减少锁持有时间在含义上是相反的。因为锁的竞争与释放，也是需要消耗资源的，因此当我们需要在循环内请求锁时，
需要写成这样：
synchronized (this) {
for (int i = 0; i < count; i++) {
/*do something*/
}
}
而不是这样：
for (int i = 0; i < count; i++) {
synchronized (this) {
/*do something*/
}
}
接下来看一段AT中的源码：
使用线程安全的双端队列LinkedBlockingDeque代替ArrayDeque，从而可以减少锁持有时间，使用重用锁（ReentrantLock）代替内部锁（synchronized）进行双重校验，避免高并发状态下scheduleNext方法不必要的锁等待。
private static class SerialExecutor implements Executor {
final LinkedBlockingDeque mTasks = new LinkedBlockingDeque<>();
Runnable mActive;
final ReentrantLock reentrantLock = new ReentrantLock();
public void execute(final Runnable r) {
mTasks.offer(new Runnable() {
public void run() {
try {
r.run();
} finally {
SerialExecutor.this.scheduleNext();
}
}
});
if (mActive == null) {
reentrantLock.lock();
try {
if (mActive == null) {
SerialExecutor.this.scheduleNext();
}
} finally {
reentrantLock.unlock();
}
}
}
protected synchronized void scheduleNext() {
if ((mActive = mTasks.poll()) != null) {
THREAD_POOL_EXECUTOR.execute(mActive);
}
}
}
差不多这就是这样了，如果有理解不当，或逻辑错误，还望指出。
片尾TIP：
一张图足够说明了。
