去哪儿 AI 应用开发秋招：JVM 排查与异步文件处理

《面试题目》

1. 能否做一个自我介绍？
2. 排查 JVM CPU 占用过高和内存泄漏，会用哪些工具与 Linux 命令？
3. top 定位到高 CPU 的 Java 进程后，怎样继续定位到代码？
4. volatile 不保证自增原子性，哪些场景单独使用它就能满足线程安全需求？
5. volatile 的可见性在底层通过什么机制实现？
6. Redis 基础分布式锁怎样设计命令和参数？
7. 业务执行超过锁的过期时间会发生什么，怎样处理？
8. 进程与线程有什么区别和联系？
9. 同一进程的两个线程同时修改共享内存，可能发生什么？
10. 处理约 100 MB 的 Excel 导入导出，怎样设计异步流程以避免请求一直等待？
11. 用户怎样查看处理进度并拿到最终文件？
12. 前后端可以通过哪些方式同步大文件处理进度？
13. 最有技术挑战的后端项目是什么，怎样解决难点？
14. 为什么选择线程池并发调用，而非批量查询接口？
15. 线程池的核心线程数与队列长度怎样确定？
16. 近半年有哪些主动学习并实际落地的经历？
17. 评审 Agent 为什么选择 LangGraph，与 LangChain 或单 Agent 方案怎样比较？

《参考解析》

CPU 排查从进程走到线程

对平台线程，可以先用 top -H -p <pid> 找到持续占用 CPU 的线程，再把编号转成十六进制，对照线程转储中的 nid。多次采样看是否反复停在同一段代码，并结合 GC 日志判断是不是分配和回收造成压力。单次堆栈只能提供线索，不能证明根因。

volatile 适合发布状态，不负责复合更新

例如一个线程写停止标志、其他线程读取标志，没有依赖旧值计算新值的复合更新时，可以用 volatile 提供可见性及相应的顺序保证。i++ 包含读取、计算和写入，多个线程仍可能覆盖彼此结果。底层实现涉及编译器与处理器的屏障约束，需要结合目标平台说明。

大文件任务要有独立身份

请求提交后返回任务标识，后台读取文件、校验与分批处理，前端再查询进度或接收服务端推送。进度可以按已处理行数表示；无法预先知道总量时，展示当前阶段更准确。结果文件保存后提供下载入口，同时处理重复提交、失败重试与结果过期。

先说工作流需求，再说框架

评审任务如果包含多轮状态、分支、暂停和恢复，可以从这些需求解释选型。LangGraph 提供有状态编排、持久化、流式输出和人工介入等基础能力；LangChain 还提供模型、工具和更高层 Agent 抽象。两者并非互斥，节点内也可以使用同一个 Agent。参见 LangGraph 官方概述。