Android 面试里有一类题专门筛人，线程池七参数的原理追问就是典型：第一层问是什么，几乎人人都能背出七个参数；第二层问怎么实现，能说出执行流程的已经不多；第三层问为什么这样设计，能把核心线程数、队列容量、拒绝策略三者的相互制约讲清楚的，凤毛麟角。三层下来，背题的和理解的立刻分层。
先把结论放在前面：七个参数不是七个独立旋钮，而是一组需要一起调的约束。 corePoolSize 决定常驻线程数，maximumPoolSize 是上限，workQueue 是缓冲层，keepAliveTime 决定非核心线程的存活时长，threadFactory 决定线程怎么建、unhandledExceptionHandler 决定异常去哪，RejectedExecutionHandler 决定满了怎么办。 真正决定行为的，是前四个参数构成的那条链：核心线程 → 队列 → 非核心线程 → 拒绝。
机制拆解
讲清这条执行链，它就是这题的核心。提交任务时，线程池先看当前线程数是否小于核心数，是则新建核心线程执行；否则尝试入队，队列满了再看当前线程数是否达到上限，未达到则新建非核心线程执行；队列满且线程数到顶，才交给拒绝策略。 理解这个顺序，就能解释两个高频现象：一是为什么线程池"看起来没用满"却已经触发拒绝——因为任务全堆在队列里，非核心线程根本没被创建；二是为什么把队列设成无界会导致最大线程数形同虚设——队列始终不满，任务不会走到新建非核心线程那一步。
这些坑的正确绕法
最常见的坑是用 newFixedThreadPool 处理突发流量，无界队列堆积任务导致内存暴涨。 Executors.newFixedThreadPool 内部用的是 LinkedBlockingQueue 且容量为 Integer.MAX_VALUE，任务只会进不会出；流量高峰时任务对象连同捕获的上下文一起堆积，很快触发 OOM。 更隐蔽的是它创建的线程没有自定义名字，出问题时 trace 里全是 pool-1-thread-1 这种默认名，排查无从下手。对策是自己 new ThreadPoolExecutor 显式指定有界队列与命名规则。
其次是核心线程设得过大，上下文切换开销吃掉并行收益，CPU 利用率反而下降。 上下文切换的成本随线程数上升，任务又不够填满时，大量线程在阻塞与唤醒之间空转，吞吐量反而不如线程数适中时的配置。经验起点是：CPU 密集型给 N+1（N 为核数），IO 密集型给 2N 或更多，但这只是起点值，真实值要看压测与监控。
还有一个更隐蔽的坑：拒绝策略用了 CallerRunsPolicy，又在提交任务后立刻 shutdown 或等待结果，造成偶发卡死。 CallerRunsPolicy 让提交线程自己跑任务，若提交发生在等待该任务完成的位置，就会出现"自己等自己"的死锁；即便不死锁，提交线程被阻塞也会拖慢主流程（比如主线程被阻塞就可能卡住界面）。选策略前先想清楚任务是谁提交的、提交方能不能承受这段耗时。
围绕线程池七参数协作时最有效的一条约定，是把适用前提显式写在代码旁，让 review 有据可依。 落地成几条：不用 Executors 预设工厂而显式构造；队列必须有界且容量与业务峰值匹配；线程命名带上业务标识；submit 与 execute 按是否需要 Future 来选；shutdown 在合适时机调用、awaitTermination 带超时回收。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 线程池七参数：显式构造，拒绝策略与命名都要显式
ThreadPoolExecutor pool = new ThreadPoolExecutor(
4, 8, 60, TimeUnit.SECONDS, // 核心 4，最大 8，非核心存活 60s
new ArrayBlockingQueue<>(100), // 有界队列，必须显式给容量
r -> new Thread(r, "upload-worker"), // threadFactory：线程命名便于排查
new ThreadPoolExecutor.CallerRunsPolicy());
pool.execute(task);
pool.shutdown(); // 不再接受新任务
pool.awaitTermination(30, TimeUnit.SECONDS); // 带超时回收，避免永久等待
// 执行顺序：核心 → 队列 → 非核心 → 拒绝
这段代码值得盯两处：第一处，ArrayBlockingQueue 显式给容量，把"缓冲多少任务"变成一个可讨论的量；第二处，threadFactory 里给线程命名，线上 trace 时能一眼看出是哪个业务的池。面试讲到这一层，基本就稳了。
这题在面试里怎么问、怎么答
"请简单介绍一下线程池七参数，它在 Android 开发中起什么作用？"三段式回答：定义、场景、案例。定义是复用线程管理并发；场景是后台任务聚合、请求并发控制、隔离第三方调用；案例可以讲某个上传模块用独立线程池，避免与主业务共享队列互相拖累。回答控制在两三分钟内。
"线程池七参数的底层原理是什么？能不能详细说一下？"按动机、机制、代价三层讲。动机是复用线程、控制并发度、隔离故障；机制是 ThreadPoolExecutor 的执行链与 execute 里的分支判断，队列用的是 BlockingQueue 的阻塞语义；代价是参数之间互相制约，配错就会从"限流"变成"堆积"。 再补一句 Executors 预设工厂的已知问题（无界队列、线程数不可控、命名不友好），这题就完整了。
"在使用线程池七参数时遇到过什么问题？"用 STAR 结构答。典型案例：埋点上报共用一个全局池，某次大促流量上来后队列被打满，触发 RejectedExecutionException，上报数据整体丢失；定位到是非核心业务与核心业务共享队列；修复为按业务拆分独立池并改用丢弃策略加采样；验证是高峰期核心业务不再受影响。
"线程池七参数和相关的替代方案相比，有什么优劣？"对比 Executors 预设、协程、以及自建生产者消费者三条线。结论落在场景：常规后台任务用显式构造的 ThreadPoolExecutor；结构化并发、有大量轻量异步任务时协程更省资源；需要背压与顺序处理时生产者消费者更贴合。选型时把"核心线程设得过大反而掉吞吐"这类代价摆到台面上，再决定是否引入。
再补一个工程上值得讲清的点：怎么给线程池定容量。定队列容量前先量两件事——任务的平均耗时和峰值并发数。用 Little's 法则给出直觉估算：稳定态下队列长度约等于到达率乘平均处理时间，比如每秒进 200 个任务、每个处理 50 毫秒，那么稳态队列里约有 10 个在等待，容量给到 50 就能吸收掉明显的抖动而不至于无限堆积。 核心线程数则按 CPU 密集或 IO 密集分开取值，Android 上要额外考虑一个现实约束——设备核数差异极大，写死 4 在低端机上就是浪费，写死 32 在高端机上可能过度并发，所以更稳的做法是按 Runtime.availableProcessors() 动态推导，再配合线上监控校正。能把"公式 + 实测 + 监控"三步讲出来，这道题的分量就明显不同了。
给正在准备面试的你
把线程池的执行链画成一张流程图：提交任务 → 判断核心线程数 → 入队 → 队列满则建非核心线程 → 线程满则走拒绝策略，并在每个分支旁标出对应的参数。面试中关于线程池的问题，关键在于能够从原理、应用、踩坑三个层面给出有深度的回答。
再补工程案例与踩坑——应用落点是给项目里的线程池补齐监控（活跃线程数、队列长度、拒绝计数、完成数），并用压测把核心线程数从写死的值调成按核数推导加校正后的值，记录吞吐与耗时的对比。
复习时别孤立刷题：CountDownLatch 与 CyclicBarrier——它们常与线程池搭配做任务编排，边界提前划清楚。
划两句重点：执行顺序是核心线程→队列→非核心线程→拒绝，队列无界会让最大线程数失效；Executors 预设工厂要避开，队列必须有界、线程必须命名、拒绝策略要与提交方能承受的代价匹配。
下一篇聊 CountDownLatch 与 CyclicBarrier：等待与协作——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：volatile：可见性、有序性与禁止重排
下一篇预告：CountDownLatch-与-CyclicBarrier：等待与协作
有任何问题欢迎在评论区留言交流。
