面试准备攻略④：Java 后端（人工智能研究院） @ 中国电信股份有限公司

一、岗位速览

平台详情页需登录查看完整 JD，以下岗位画像为推断。

二、JD 拆解与岗位画像（推断）

招聘主体是中国电信人工智能研究院——这是央企里少有的“真做 AI”的建制单位（做大模型、语音、多模态、智算平台）。岗位名叫“Java”，但挂在 AI 研究院下，绝大多数情况是“大模型/智算平台的后端工程岗”：平台能力（模型管理、推理调度、API 网关、Agent 平台）都是用 Java 写的。

核心职责（预期）

1. 大模型 / 智算平台的后端服务：模型管理、推理任务调度、API 网关、计费与配额。
2. 高并发 API 层与多租户隔离（研究院内部 + 省公司/行业客户共用）。
3. 与算法团队对接：把模型服务标准化为可调用的后端能力（流式、异步、回调）。
4. 参与平台稳定性建设：监控、限流、降级、容量规划。

必备技能

• Java 基础深、JVM 调优、并发编程（线程池、锁、AQS）。
• Spring Boot / Spring Cloud 微服务、网关、注册配置中心。
• MySQL / Redis / Kafka / 分库分表 / 缓存一致性。
• 高并发场景下的限流、降级、幂等、分布式追踪。

加分项

• 了解推理服务化（vLLM / Triton）、GPU 资源调度、模型服务网关。
• 了解 SSE / WebSocket 流式输出与背压处理。
• 有 AI 应用（RAG / Agent）集成经验——这正是候选人的差异化优势。

三、六维度匹配度分析

强匹配点

• 在职项目就是 Spring Cloud 微服务架构设计与落地，直接就是岗位工作内容。
• 支付网关（支付宝/微信）集成与自动对账系统——说明能处理资金类高可靠服务。
• 高并发（游戏开服、618/双11 营销）+ 全链路日志跟踪 + IP 风控——平台稳定性经验完整。
• AI 应用集成经验，能把“模型能力”翻译成“后端服务”，在一个 Java 岗里成为稀缺项。

需补强的点

• 若面试提到 GPU 调度 / 推理服务化，提前准备一版“模型服务网关”的设计思路（路由、限流、流式、计量）。
• 准备好一个真实的高并发瓶颈排查故事（线上 OOM / 慢查询 / 连接池耗尽均可）。

四、面试知识体系（按模块）

模块 1：Java 深度

• JVM 内存模型、GC 算法（G1/ZGC）与调优实战
• 并发：AQS、CAS、线程池参数选择、ThreadLocal 内存泄漏
• 集合与锁的选型、无锁结构（LongAdder、Disruptor）

模块 2：微服务与高并发

• 服务治理：限流（令牌桶/漏桶）、熔断降级、隔离仓
• 分布式事务与幂等设计（唯一索引 + 状态机 + 去重表）
• 缓存：穿透/击穿/雪崩、缓存与 DB 一致性（延迟双删 / binlog 订阅）
• 消息队列：顺序、幂等、堆积处置与死信
• 分布式追踪与可观测

模块 3：大模型平台后端（本岗的特色）

• 模型服务网关：多模型路由、配额、计费、灰度
• 流式输出（SSE / WebSocket）与背压、超时、断连重试
• 异步任务与回调（长耗时推理后的通知机制）
• GPU 资源调度基础：显存回收、批处理、排队与优先级
• 多租户隔离：密钥管理、配额、审计日志

模块 4：稳定性工程

• 容量评估与压测方法论
• 故障演练与应急预案
• 监控指标设计（黄金四指标：延迟/流量/错误/饱和）

五、高频面试题与参考答案

Q1：线程池怎么配？核心数怎么定？ A：先分清任务类型。CPU 密集型：核心数 ≈ 核数 + 1；IO 密集型：核数 × (1 + 平均等待时间/平均计算时间)，在调用外部接口为主的场景常见是核数 × 2~4。但我们生产上不靠公式拍，而是先设一个保守值 + 绑定队列容量 + 拒绝策略（不丢请求，降级到同步或快速失败），再用监控看队列深度与任务等待时间，压测后调。关键是别用无界队列，那是拿 OOM 换稳定性的假象。

Q2：缓存与数据库一致性怎么保证？ A：先分场景。绝大多数业务能接受最终一致，用“先改 DB，再删缓存（延迟双删）+ binlog 订阅补偿”就够；强一致场景直接用分布式锁或读时互斥。更好的思路是不靠缓存保证一致性，而是把缓存定位为“可丢失的加速层”：缓存失效时回源 DB，日志上保留可回放的变更流。我在支付与对账场景就是这么做，对账任务做兵底。

Q3：下单接口怎么防重复提交？ A：三层：① 前端置灰 + 一次性 token；② 服务端幂等——业务唯一键（如订单号）建唯一索引，插入失败即重复，直接返回原结果；③ 分布式锁做前置拦截（Redis SETNX + 过期）。核心是最终靠数据库唯一约束兑底，因为锁会失效，唯一索引不会。

Q4：线上 CPU 打满怎么排查？ A：先看指标再进现场：① 监控定位是全局还是单实例；② 单实例 top -Hp 找线程，jstack 抽线程栈，看是业务循环、GC 还是锁竞争；③ 若是 GC，看 GC 日志与堆直方图（jmap -histo）找大对象；④ 若是锁，看 BLOCKED 线程的锁持有者。优先止血（扩容/降级/重启），再做根因分析。切忌一上来就重启而不保留现场。

Q5：设计一个模型服务网关（本岗可能直接问）。 A：四层：① 接入层：鉴权（API Key / OAuth）、配额与限流（按租户/模型）、审计日志；② 路由层：按模型名 / 能力标签 / 成本策略路由到不同后端（不同厂商 / 自建 vLLM）；③ 执行层：统一请求/响应格式适配（各家 API 差异封装），流式输出转发（SSE 透传 + 背压控制），超时与重试（注意流式重试需幂等）；④ 计量层：Token 计数、成本统计、调用明细落库。旁路要有健康检查与自动降级（主模型不可用切备用模型）。

Q6：Kafka 消费积压了怎么办？ A：先区分原因：① 消费能力不足（正常流量涨了）→ 增分区 + 增消费者实例（注意分区数是并行度上限）；② 单条消息卡死/缓慢 → 看消费堆栈与下游依赖，隔离异常消息到死信队列；③ 重复消费导致 重复处理 → 用业务幂等修正。长期上做消费延迟监控告警，并在业务上把“可并行”与“必须顺序”的消息分 Topic 处理。

Q7：服务雪崩怎么防？ A：三招：① 超时——所有跨服务调用必须有超时，没超时等于把风险传染给上游；② 隔离——线程池/信号量隔离，不让一个下游拖垮整个应用；③ 熔断降级——连续失败就快速失败并返回降级值（缓存/默认值）。再加 重试制去（重试只在幂等接口上做，且带指数退避）。

Q8：你怎么看 Java 在 AI 时代的价值？ A：大模型的能力层是 Python，但平台层与业务层一定是 Java 的天下——模型网关、任务调度、配额计费、多租户、高并发 API，这些是 Java 十几年积累的强项。而且企业里存量业务系统全是 Java，AI 要真正落地就必须有人把它接进来。我就属于“能把两层缝在一起”的人。

Q9：央企环境与互联网公司有什么不同？ A：不能为了技术先进性而牺牲稳定性与可维护性。央企系统的生命周期往往是十年记，所以选型要保守，文档要齐全，交接要完整。这不意味着不接受新技术，而是新技术必须证明自己能长期跑得住。

Q10：为什么 39 岁还在做技术一线？ A：因为我一直在一线写代码、做架构。带团队时也从没离开过技术决策。我认为 16 年经验的价值不在于写得更快，而是能在方案阶段就看出哪条路会坑。我希望能把这份判断力用在真正难的系统上。

六、北京人才引进资格核查

中国电信属央企体系，落户指标基本面优于民企，但需特别注意用工主体：

• 劳动合同签的是中国电信股份有限公司，还是下属子公司 / 研究院独立法人？
• 招聘发布主体是“人工智能研究院（上海）”——工作地在北京但主体在上海，这是否影响社保缴纳地与落户申报？这一条必须当场问清楚。
• 落户指标属于哪个主体的名额池？本年度是否还有？
• 对年龄、硕士学历、社保连续年限的要求？
• 是否有编制内/编制外的区分？

提醒：跨省市法人主体是央企岗位落户的常见陷阱。工作地在北京不等于能在北京落户，关键在于社保与用工主体是否在北京。

七、反向提问清单

1. 这个 Java 岗具体支撑哪个平台？模型服务还是业务中台？
2. 团队里 Java 和 Python 的分工边界是什么？
3. 服务的 QPS / 用户规模大概多少？
4. 推理资源是自建智算还是云上采购？
5. 落户与社保主体问题（见第六节）？
6. 团队的技术选型决策流程是怎样的？

声明：本文岗位画像为基于公开招聘信息的推断，不代表用人单位正式 JD。本文不含个人隐私与账号凭据。