快手 AI 应用开发秋招一面：线程池、OOM 与项目深挖
面经与参考答法
快手 AI 应用开发秋招一面：线程池、OOM 与项目深挖
作者记述这是一轮约 50 分钟的 AI 应用开发秋招一面，面试日期未披露；采集元数据中的 2026 年 8 月是发帖时间。本文选录项目介绍、线程池、OOM、Java 内存模型和区间算法；不收录自我介绍、实习情况及关于面试表现和校招生能力的两项反问。原文提到的项目追问没有逐条展开，区间题也没有完整条件；下文保留这些信息边界，回答均为教学整理。
（1）怎样选择最熟悉的项目介绍？
关联知识点待核实。
选择自己真正负责且能回答失败细节的项目，而不是名字最“AI”的项目。用业务目标、用户流程、本人职责、核心架构、难点取舍和量化结果组织；说明为什么需要该功能，传统方案哪里不足，以及模型决策在哪些节点被确定性代码约束。
（2）项目难点应该怎样展开？
关联知识点待核实。
把“难”具体化为一致性、延迟、成本、准确性、权限或可恢复性。选一个问题说明约束和基线，比较两到三个方案，解释最终选择及代价，再给出上线或实验指标。若没有量化结果，也应给出可复现测试、失败样本和下一步验证计划。
（3）Java 线程池核心参数如何共同工作？
关联知识点待核实。
重点包括核心线程数、最大线程数、存活时间、工作队列、线程工厂和拒绝策略。提交任务时通常先创建核心线程，再进入队列；队列满后才扩到最大线程数，仍无法接收时触发拒绝。必须结合任务的 CPU/IO 特性、外部依赖容量和延迟目标设置，不能照抄固定公式。
（4）使用线程池有哪些常见风险？
关联知识点待核实。
无界队列可能积压到 OOM；线程过多会增加上下文切换和内存；阻塞任务占满工作线程会拖垮整个池；异常若被吞掉会造成静默失败。生产中应设置有界队列、明确拒绝策略、超时与取消、任务隔离、线程命名，并监控活跃数、队列深度、等待时长和拒绝数。
（5）为什么不直接使用现成线程池，自定义时参考过哪些实现？
关联知识点待核实。
先回答“能复用就复用”，再说明实际参考过的执行器实现、保留的机制和修改理由；原文没有披露候选人的参考清单。只有任务优先级、隔离、调度、公平性、可观测或取消语义确实特殊时才封装或自定义。自定义实现要证明生命周期、并发安全、任务丢失、异常传播、关闭和背压都正确；否则成熟执行器通常比手写更可靠。
（6）什么情况会导致 OOM？Java 内存模型又解决什么？
关联知识点待核实。
OOM 可能来自堆对象泄漏、缓存或队列无界、元空间类加载、直接内存、线程栈和本地内存。定位时结合 GC 日志、Heap Dump、线程数、Native Memory 和分配速率。Java 内存模型描述线程间读写的可见性、原子性与有序性，happens-before、volatile、锁和线程启动/结束规则用于建立正确同步关系；它不是 JVM 内存区域划分。
（7）原记录的“不重叠区间个数”题，应先澄清什么？
关联知识点待核实。
原文只写“计算多个区间中不重叠区间的个数”，没有给出是否求最大值、是否要求删除、区间端点、输入规模等条件。应先澄清目标和约束，不能直接认定为最大区间调度题。
教学分支：若目标是选择最多个两两不重叠区间，则按结束时间升序排序，选择最早结束的区间，此后每次选择起点不早于上一个结束点的区间。交换论证可说明：最早结束的选择为后续留下最大空间，因此不会比最优解差。排序复杂度为 O(n log n)，扫描为 O(n)；闭区间还是半开区间会影响边界条件。