线程池面试｜一页极简口述满分版（高级开发必背）
一、核心概念解析（口述满分）
线程池核心作用：实现线程复用，规避线程频繁创建、销毁的性能开销，同时实现并发限流、服务熔断防护、异步任务统一管控，是高并发服务必备核心组件。
核心七参数精简：核心线程数、最大线程数、空闲超时时间、时间单位、有界阻塞队列、自定义线程工厂、拒绝策略。
执行流程（四步核心）：新任务优先交由核心线程处理 → 核心线程饱和后进入队列排队 → 队列打满则创建非核心线程 → 线程、队列全部饱和，触发拒绝策略。
生产硬性规范：严禁使用Executors快捷创建线程池，必须手动构建ThreadPoolExecutor，搭配有界队列，实现资源完全可控。
二、线上真实生产故障场景
故障现象：业务使用newFixedThreadPool处理异步消息任务，日常流量正常，大促高峰期频繁Full GC，堆内存持续暴涨，最终服务OOM内存溢出宕机，无业务报错，仅任务堆积超时。
故障根因：newFixedThreadPool底层采用无界阻塞队列，无存储上限。高并发场景下海量任务持续堆积，大量任务对象常驻堆内存无法GC回收，最终触发内存溢出。
落地修复与优化：手动创建带有界队列的自定义线程池；核心与非核心业务线程池隔离，避免资源抢占；自定义降级拒绝策略；所有异步任务全局捕获异常；新增队列堆积、任务耗时、线程活跃度监控告警。
三、三层递进追问+完整满分标准答案
1. 基础认知层：生产环境为什么禁止使用Executors创建线程池？
标准答案：Executors工具类创建的线程池存在两大线上致命隐患，完全不适合生产使用。第一，Fixed、Single线程池基于无界队列，高并发任务堆积会无限占用堆内存，直接引发OOM宕机；第二，Cached、定时线程池无最大线程数限制，流量峰值会无限创建线程，耗尽操作系统线程资源，导致CPU上下文切换爆满、服务整体瘫痪。因此生产必须手动配置线程池，约束线程数和队列容量，保障并发资源可控。
2. 底层原理层：CPU密集型和IO密集型任务如何配置线程数？线程回收机制是什么？
标准答案：CPU密集型以计算逻辑为主，无IO阻塞，配置CPU核心数+1，避免线程过多引发频繁上下文切换，降低计算性能；IO密集型多为数据库、Redis、网络请求等阻塞任务，配置CPU核心数*2，利用线程阻塞空档最大化压榨CPU吞吐量。线程池默认只回收非核心线程，空闲超时后自动释放资源，核心线程常驻线程池保障响应速度；可手动开启核心线程超时回收，适配低频业务节约系统资源。
3. 生产落地层：线上线程池任务大量堆积、接口卡顿如何排查？默认拒绝策略有什么弊端？异步任务不捕获异常有什么后果？
标准答案：任务堆积排查分三步，首先看监控，核查活跃线程打满、队列持续积压、任务拒绝数飙升；其次排查堆栈，定位慢SQL、外部慢接口等长耗时IO阻塞线程，导致线程无法及时释放；最后核对参数，确认线程数、队列容量配置过小导致限流堆积。默认AbortPolicy策略直接抛异常，会丢失业务任务且无告警兜底，无法及时发现线上问题。生产需自定义策略，核心任务落库重试补偿，非核心任务日志记录后降级丢弃并告警。异步任务未捕获异常会直接销毁当前工作线程，线程池会频繁重建线程，损耗CPU性能，同时任务无声失败、数据丢失，线上问题难以排查，所以所有异步任务必须添加全局try-catch异常兜底。
四、面试万能收尾总结
线程池设计核心是资源可控、限流防护。生产禁用Executors快捷方式，手动配置有界队列，根据CPU、IO业务场景适配线程参数，做好业务线程隔离、自定义降级策略、全局异常兜底和监控告警，线上卡顿堆积优先排查慢任务阻塞与队列溢出问题。
（注：文档部分内容可能由 AI 生成）
