标签题目
线程池相关面试题
Java 线程池有哪些核心参数？
Java 线程池的核心参数来自 ThreadPoolExecutor：corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、RejectedExecutionHandler。真正要掌握的是它们如何共同决定线程创建、任务排队、扩容、回收和拒绝策略。
常见的cpu load过高，us过高，一般是什么问题？
CPU load 高和 CPU 使用率高不是同一个概念。load average 统计可运行队列和不可中断 I/O 任务，us 高表示用户态代码消耗大量 CPU。排查要先看 us、sy、wa、si、st 的结构，再定位到进程、线程和调用栈。
过去经历中怎么应对高并发或高性能场景的？
高并发或高性能场景不是考单点技术名词，而是考候选人能否把真实工程问题讲成闭环：先明确业务目标和容量指标，再通过压测和可观测性找到瓶颈，随后从流量、应用、缓存、队列、数据库、线程池、连接池、锁竞争、水平扩展和稳定性预案等层面治理，最后用结果指标证明方案有效。
Java 线程池的核心参数和执行流程是什么？
这道题考察的不是背出几个构造参数，而是要说明 ThreadPoolExecutor 如何用线程数、队列、线程工厂和拒绝策略共同定义资源边界。高质量回答应先点明线程池复用线程、控制并发、削峰和保护系统的目的，再按任务提交后的执行路径解释：先看核心线程，再入队，再扩容到最大线程，最后触发拒绝策略，同时补充队列选择、参数取舍、异常处理、关闭流程和线上监控。
如何在实际中判断是否会出现线程安全问题？
判断实际项目中是否会出现线程安全问题，核心不是先看有没有多线程，而是追踪共享可变状态是否被多个执行路径并发访问，以及访问是否包含读改写、检查后执行、跨字段一致性、对象发布等风险。实战判断要结合代码审查、并发入口梳理、锁边界分析、压测和线上偶发症状，而不是依赖一次本地复现。
Mq-Bus 数据量太大延迟怎么办？
消息总线数据量过大导致延迟时，不能只回答加消费者，而要按生产端、broker、消费者三段定位瓶颈，再做止血和长期治理。核心思路是看 TPS、lag、分区倾斜、消费耗时、失败重试、资源水位；再用扩分区、提升消费并行度、批量处理、限流削峰、幂等、死信和容量规划形成闭环。
怎么选取合适的线程数？
选取合适线程数的核心不是背一个固定数字，而是先判断任务是 CPU 密集、IO 密集还是混合型，再结合机器核数、阻塞比例、线程池队列、延迟目标、吞吐目标和资源上限做估算，最后通过压测观察 CPU 利用率、上下文切换、队列堆积和响应时间来迭代调优。
并发怎么控制？
并发控制的核心不是简单加锁，而是在正确性、吞吐量、延迟和资源保护之间做取舍。高质量回答应先说明控制目标，再识别共享资源和一致性边界，最后按单机内存、线程调度、数据库、分布式协调、入口限流和异步削峰等层次选择手段。
怎么排查性能问题？
排查性能问题不能从单点经验出发，而要先把问题定义清楚：慢在哪里、影响谁、从什么时候开始、哪个指标异常、是否可复现。标准思路是先量化现象，再按调用链从客户端、网关、应用、缓存、数据库、网络和机器资源逐层缩小范围，结合压测、监控、日志、链路追踪、慢查询、线程栈、GC 日志、火焰图以及 CPU、内存、IO、网络等指标定位根因，最后通过修复验证和回归压测证明问题真正解决。