2026 Java + AI 高频面试题 30 道（11 月 8 日整理）

数据来源：今日国内技术社区（CSDN DevPress / 掘金 / 面试鸭 / 技术公众号「大厂 Agent 面试」「AI 应用开发面试手册」系列）近一个月 Java+AI 岗位面经与文章热度聚合。

配比：Java 底座与模型接入 8 题 + 大模型工程化 7 题 + RAG 与知识 8 题 + Agent、工具与评测 7 题。

每题按「一句话 → 分条要点 → 踩坑/追问」作答，控制在 500 字内。

一、今日热度速览

1. 问法全面转向"排查与定位"。今天刷到的面经里，"虚拟线程开了没效果怎么查""账单翻倍怎么拆""完成率 70% 怎么定位"这类题占到一半，纯概念题明显退场。
2. 上下文问题成了最硬的考点。Lost in the Middle、Context Rot、多轮指代丢失三件套被反复引用，能把"上下文是递减预算不是水桶"讲清楚的人不多。
3. MCP 2026-07-28 版无状态化进面试了。还按老教程答"initialize 握手 + 会话"会被直接指出过时，这是本周最明显的新分水岭。
4. Agent 可靠性从"防死循环"升级成"外置控制层"。格式校验、副作用分级、不可逆操作人工确认、预算上限、断点续跑，五道关能一条条说全的算过关。
5. 成本与数据闭环被当成工程素养考。token 归因、Prompt 缓存命中率、badcase 反馈回路——这些问题答不上来，说明项目只停在 Demo。

与上期（11-07）对比

二、Java 底座与模型接入（Q1–Q8）

Q1. synchronized 的 pinning 问题在 JDK 25 修好了，现在能放心往虚拟线程里用吗？

• 先给结论：JEP 491 确实让 synchronized 阻塞时不再钉住载体线程，25 是第一个能放心用虚拟线程的 LTS。但"语法不是雷"不等于"设计没问题"。
• 还剩三个坑：一是锁竞争激烈时 synchronized 只能死等，ReentrantLock 能超时、能中断；二是锁里做网络 IO，虚拟线程卸载了锁还占着，别人全排队；三是老框架和老驱动没升级，照样 pin。
• 怎么确认：开 JFR 看 jdk.VirtualThreadPinned 事件，超过 20ms 的样本就是证据，不要靠猜。
• 别做的事：把虚拟线程塞进线程池。它的创建成本接近于零，池化只增加同步开销。
• 答题落点：说出"24 修 pinning、25 进 LTS"这两个版本号，再补一句"锁里不要等网络"，比背定义有效。

Q2. LazyConstant（惰性常量）是什么？比 static final 和 holder 单例强在哪？

• 是什么：JEP 526 起的预览特性。它持有不可变数据，JVM 把它当真正常量，享受常量折叠和 final 字段的优化，但初始化推迟到第一次 get()。
• 对比 static final：类加载就初始化，用不上也占内存、拖启动。AI 服务里加载模型客户端、大配置、词表，很容易白白吃掉几秒启动时间。
• 对比 holder 单例：写法绕，还得靠类加载保证线程安全；双重检查锁要 volatile，写错就是重排序坑。
• 用法：LazyConstant.of(supplier)，只能 set 一次，重复 set 抛异常，之后 get() 是纯读。
• 边界：只放不可变的东西。放可变状态等于自找麻烦，JVM 的常量假设会被你打破。
• 加分句：它解决的是"启动耗时"和"常量优化"这对矛盾，不是又一个单例写法。

Q3. AI 服务调大模型的 HTTP 客户端怎么选？连接池要注意什么？

• 选型：JDK 自带 HttpClient 零依赖、支持 HTTP/2 和异步，够用；WebFlux 栈用 WebClient 拿背压；要拦截器生态选 OkHttp。Spring AI 底层走 RestClient/WebClient，一般不用自己选。
• 和普通接口最大的差别是"连接占用时长"。大模型首 token 几秒、整段几十秒，连接被长时间占住，池子小了直接排队超时。
• 参数：连接超时 1~3 秒，读超时按模型给 30~120 秒，流式请求别设总超时、改用空闲超时；池子大小按"并发数"配，不是按 QPS。
• 踩坑：每次请求 new 一个 client，连接不复用还漏线程；对非幂等的写操作做重试，重复扣费；HTTP/2 多路复用下把慢请求和快请求混在一条连接上互相拖。
• 一句话：AI 场景的连接池要按"同时在途请求数"算，不能按传统 QPS 算。

Q4. SSE 流式接口在 Tomcat 上很吃线程，为什么？怎么扛住高并发？

• 先分清两件事：SseEmitter 走 Servlet 异步，容器线程会释放，但每个连接仍占内存；真正吃线程的是上游模型那段阻塞读——如果每条 SSE 派一个平台线程去读模型流，一万连接就是一万线程。
• 两条正路：WebFlux + WebClient 拿响应式流，事件循环不占工作线程；或者用虚拟线程，一连接一线程但成本极低。别在 Tomcat 上用平台线程池硬扛。
• 必须处理的清理：客户端断开要能感知，onCompletion/onError/onTimeout 三处都要关上游流，否则模型还在生成、你还在计费。
• 网关侧：Nginx 关 proxy_buffering、调大 read_timeout，否则流被攒着一次性吐出来，打字机效果没了。
• 加分：说清"连接数上限不在 Tomcat，在模型侧并发配额"，这才叫懂链路。

Q5. 向量（float[]）常驻 JVM 堆里，为什么容易 OOM？该怎么放？

• 算笔账：100 万条 × 1024 维 × 4 字节 = 4GB，还不算对象头和对齐。堆内大数组直接进老年代，GC 压力陡增，一次 Full GC 就是几百毫秒。
• 更难受的是访问模式：向量检索是顺序扫描，缓存命中率低，堆内布局还带着对象头和指针，白占带宽。
• 怎么放：优先用 MemorySegment（FFM API，JDK 22 已正式）或 DirectByteBuffer 放堆外，配合 Arena 管生命周期；规模再大就外移到 Milvus / pgvector，别自己扛。
• 坑：堆外内存不受 -Xmx 约束，泄漏了表现为容器 RSS 涨、GC 一切正常，极难查；批量检索要分片，别一次把全量向量读进来。
• 一句话：向量是数据不是业务对象，别让它常驻堆。

Q6. 线上 AI 接口 P99 偶发 3 秒毛刺，怎么用 JFR 定位？

• 先别猜，开低开销 JFR：jcmd JFR.start settings=profile，生产环境常驻也不心疼。
• 按顺序看四样：GC 暂停有没有长尾 → jdk.SocketRead 分布是不是某次模型调用特别慢 → jdk.VirtualThreadPinned 有没有 pin → jdk.JavaMonitorEnter 有没有锁等待。
• 毛刺的典型来源：模型侧排队（你的 RT 里混了别人的队）、连接池等连接、日志同步刷盘、一次性大对象分配触发 Mixed GC。
• 工具分工：JFR 看等待和事件，async-profiler 火焰图看 CPU，别拿平均值骗自己，只看 P99 和单次长尾。
• 加分：说清"把 trace_id 打进 JFR 事件"，能直接把毛刺和某次请求对上。

Q7. AI 网关按 QPS 限流，为什么还会被打爆？该按什么限？

• 根因：QPS 一样，token 能差十倍。一个 128K 上下文的请求顶几百个短问答，模型侧的瓶颈是并发和 token 吞吐，不是请求数。
• 三层限：入口 QPS 粗限（防刷）→ TPM/token 预算细限（控成本）→ 在途并发数限制（保护下游）。少一层都会漏。
• 怎么扣：Redis 令牌桶按预估 token 扣，预估用字符数粗算或直接上 tokenizer；超限排队而不是直接拒，AI 请求用户愿意等。
• 租户维度：按用户/部门配额，防止一个大客户把池子吃干。
• 踩坑：只限 QPS，长请求把并发打满，短请求全部超时，监控上还看不出是谁干的。

Q8. Spring AI 的 ChatClient 能做成单例吗？并发下要注意什么？

• 能。ChatClient 是线程安全的不可变配置封装，官方建议 build 一次全局复用，每次 call() 生成独立的内部请求。
• 但有两个共享陷阱：defaultSystem、defaultTools 是实例级共享的，按用户动态改会串数据；多租户要用 mutate() 派生新实例，别改原对象。
• 真正有状态的是 ChatMemory，必须按 conversationId 隔离，做成单例共享就是线上串话事故。
• 流式注意：返回的 Flux 是冷流，订阅才发请求，构建时不会调用模型；别忘了 onErrorResume，客户端断开会抛异常刷满日志。
• 答题落点："Client 无状态可复用，Memory 有状态要隔离"，一句话把边界划清。

三、大模型工程化（Q9–Q15）

Q9. Token 账单翻倍，但流量没涨，怎么拆？

• 先拆公式：费用 = 请求数 × 每请求 token × 单价。按接口、模型、租户三个维度分开看，先定位是哪一项动了，别整锅端。
• 高频元凶：超时重试没退避导致风暴；Agent 步数变多（工具多调两轮就翻倍）；上下文没裁剪，历史越滚越长；Prompt 缓存失效；流量被路由到贵模型；日志和评测链路重复调用。
• 必须有的打点：每次调用记 prompt_tokens / completion_tokens / cached_tokens / model / trace_id，没有这些数据，成本问题永远只能靠猜。
• 硬约束：单请求 token 上限、Agent 步数上限、租户日预算告警。超限降级，别让它跑。
• 一句话：成本问题都是可归因的，归因不了就是没打点。

Q10. 模型"静默升级"后效果变差，怎么证明不是你代码的问题？

• 别争，转成可测量。先固定模型快照版本，别用 latest 别名；每次响应记录实际返回的 model 字段，这是唯一证据。
• 建 eval 集：没有就拿 50~100 条近期线上真实输入现建一套，跑新旧版本对比，按任务类型切片看。
• 关键细节：总体持平常掩盖某一类回归，一定要分 slice 看；让客户给 5~10 个具体失败例子，"感觉变差"没法修。
• 长期机制：模型版本固定 + 定时回归 + 灰度切流 + 快照回滚开关。
• 加分：说清"模型升级是外部依赖变更，必须纳入变更管理"，这是工程视角。

Q11. 结构化输出有 2% 解析失败，怎么定位和修？

• 先分桶再动手：① 被截断（看 finish_reason=length）；② JSON 合法但字段/类型不对；③ JSON 外面裹了解释文字；④ 模型直接拒答。四类修法完全不同。
• 对应修法：截断→加 max_tokens 余量；形状不对→用 schema 约束解码（JSON Schema / structured outputs），别靠提示词求它；裹文字→提示词加"只输出 JSON"并做一次修复重试；拒答→单独分支处理，别当解析失败。
• 监控：按桶打点，改一次看一次，才知道哪个改动真把 2% 压下去了。
• 兜底：解析失败不要抛给用户，降级成纯文本展示或转人工。
• 一句话：2% 不是随机噪声，是四个不同的问题混在一起。

Q12. Prompt 缓存命中率部署后掉到 0，常见原因有哪些？

• 机制：缓存按前缀精确匹配，顺序是 tools → system → messages，前面动一个字，后面全失效。
• 元凶清单：system 里塞了时间戳/用户名/随机 ID；工具列表顺序变了（HashMap 遍历不稳定）；模型或版本换了；新实例没预热；缓存 TTL 到期（默认 5 分钟），冷接口自然打不中。
• 怎么查：dump 两次请求的完整 prompt 做 diff，同时看响应里的 cached_tokens 字段是不是 0。
• 怎么设计：稳定内容（系统指令、工具定义、固定知识）放最前，动态内容（用户问题、检索片段）放最后。
• 收益：缓存读通常按 10% 计价，命中率从 0 恢复到 80%，账单直接砍一半。

Q13. 长 Prompt 中间的信息模型就是看不见，为什么？工程上怎么排？

• 有名有姓的现象：Stanford 的 Lost in the Middle 发现信息在开头结尾时效果最好，放中间明显下降；Chroma 用 18 个模型验证的 Context Rot 进一步说明——输入越长越不可靠，加窗口不解决。
• 原因：注意力是 n² 的递减预算，不是水桶。每个新 token 都在分薄注意力，塞满等于没塞。
• 工程做法：少而精，Top-K 别贪多；最相关的片段放头尾；长文档之后重述一遍问题；检索结果加编号和标题，让模型能定位引用；必要时先摘要再回答。
• 验证方法：把关键句在上下文里挪位置做 A/B，效果变化就是证据，比讲原理有说服力。

Q14. Agent 跑到十几轮，用户说"改那个方案"它反问"哪个方案"，怎么解？

• 本质：模型没有记忆，每次请求完全独立，"记忆"全在你代码里。丢只有两种：信息没进上下文（被截断或摘要丢了），或者信息在但注意力够不着。
• 解法一：维护结构化任务状态——目标、约束、已确认决策，每轮显式带上，不靠历史消息滚动。
• 解法二：分层摘要——近期保留原文、早期压成摘要、关键约束单独置顶，不参与压缩。
• 解法三：入口做指代改写，把"那个方案"结合上下文还原成完整表述再检索。
• 解法四：长任务落库，支持断点续跑，重启不丢状态。
• 别做：一味加窗口。128K 也会丢，方向错了。

Q15. AI 应用怎么建数据闭环，避免"上线即巅峰、之后一路衰减"？

• 现状很扎心：行业调研说九成 AI 项目没有闭环，用户纠错了没人记录，模型质量只会随时间下降。
• 三步起步：① 每条回答一键点赞/点踩 + 可选原因，落库带上 trace_id、Prompt 版本、检索片段；② 每周固定过 badcase 清单，归类成"检索问题/生成问题/知识缺失"；③ badcase 自动进知识库待更新队列或 eval 集。
• 看三个指标：采纳率、纠错率、转人工率。比"用户满意度"这种主观项可操作得多。
• 一句话：没有反馈数据的 AI 项目，迭代全靠拍脑袋，面试官一听就知道项目是真是假。

四、RAG 与知识供给（Q16–Q23）

Q16. 什么场景该上 GraphRAG？普通向量 RAG 哪里不够？

• 普通 RAG 的边界：擅长"某段话里说了什么"，不擅长多跳（A 的供应商的母公司是谁）和全局（我们和友商的差异点有哪些）。
• GraphRAG 做法：抽实体和关系建图，社区检测生成分层摘要，回答时按图遍历或按社区摘要汇总。
• 适合：实体关系密集、需要跨文档推理的领域——金融风控、供应链、法务、医疗。
• 代价要讲清：抽取成本高（每篇都过 LLM）、增量更新麻烦、图质量高度依赖抽取 Prompt，错了会一路错下去。
• 建议顺序：先上混合检索 + 多查询改写 + Rerank，真解决不了再上图谱。别为了时髦上重方案。

Q17. 检索回来的几段文档互相矛盾，让模型自己判断吗？

• 先判性质：是版本新旧（政策更新了）、口径不同（不同部门各自表述），还是真冲突。处理方式完全不同。
• 做法：① 元数据带生效时间、来源、权威等级，检索后按权重排序，新版本优先；② 冲突时明确要求模型列出不同说法并标注来源和时间，不许它替你选；③ 高价值场景走人工审核或规则表兜底；④ 离线跑冲突检测，扫同一实体的矛盾表述。
• 别做：靠 Prompt 说"以最新为准"——模型根本不知道哪个最新，时间信息必须在数据里。
• 一句话：模型没有裁判权，权威性要写进元数据。

Q18. 知识库里的价格、政策有时效，怎么保证答的是最新的？

• 按变更频率分流：每天变的（价格、库存、额度）别进向量库，走实时接口 + Function Calling 查；每周到每月变的定时同步；几乎不变的静态入库。
• 入库带时间：每篇文档带生效/失效时间，检索时按时间过滤，过期文档自动降权或下线。
• 增量更新：用 CDC / 消息队列监听变更，按文档 ID 做增删改，别全量重建索引。
• Prompt 兜底：明确写"以下资料截至 X 月 X 日"，让模型在超出时效时主动说明。
• 追问防线：如果答案是"我不知道最新数据"，比编一个旧数字强得多。

Q19. Embedding 必须归一化吗？余弦相似度和内积怎么选？

• 关系：余弦相似度 = 归一化之后的内积。向量都已归一化时两者等价，内积少一次除法，更快。
• 看模型：OpenAI、BGE 等多数模型的输出已归一化，直接用内积；有些模型不归一化，必须先做 L2 归一化，否则向量模长会被文本长度带偏，排序全乱。
• 致命坑：换 Embedding 模型必须重建整个索引。维度和语义空间都不兼容，混着用算出来的相似度没有任何意义。
• 工程建议：把"是否归一化"写进索引元数据，检索时按同一规则算，别在不同服务里各写一套。

Q20. 用户问"我们和友商比怎么样"，RAG 检索不到，怎么办？

• 先分清是"库里没有"还是"表达不匹配"。九成是后者。
• 表达不匹配的四招：多查询改写（同义扩展、拆子问题）；HyDE 先生成假设答案再拿它检索；混合检索补 BM25，专有名词靠关键词更准；先做实体识别，用元数据缩小范围再向量检索。
• 真没有就别编：明确回答"知识库暂未覆盖"，同时把问题记进知识缺口报表，反哺知识库建设。
• 加分：说清"检索失败率要单独监控"，这是把 RAG 当系统而不是当接口看。

Q21. RAG 检索到了正确文档，答案还是错的，怎么区分是哪一环的问题？

• 一个实验就能分：把正确文档手工塞进 Prompt。答对了 → 检索/排序问题；还错 → 生成/指令问题。别一上来就换模型。
• 检索侧看三点：正确文档在不在 Top-K、Rerank 之后排第几、是不是被切片切碎了导致语义不全。
• 生成侧看三点：关键句是不是落在上下文中间、Prompt 有没有"只依据资料回答"、有没有要求引用来源。
• 加引用溯源：答案必须带文档 ID 和片段编号，出错时能直接定位是哪段被误读。
• 一句话：不区分环节的优化都是瞎调参。

Q22. 知识库要不要开放用户上传？上传的脏数据怎么治理？

• 该开放，但要有准入：格式白名单、大小限制、病毒扫描、解析失败隔离，别让一个坏 PDF 卡住整条流水线。
• 治理链：解析 → 清洗（去页眉页脚、去乱码）→ 切片 → 质量打分（长度、语言、重复率、可读性）→ 入库打标签（来源、上传人、时间、租户）。
• 权限分层：个人 / 部门 / 公共三级空间，检索时按 ACL 过滤。别指望 Prompt 拦权限，那是物理隔离的事。
• 运营机制：低质文档自动降权，长期零访问的归档，定期让上传人认领维护。

Q23. 长文档问答，整篇塞进去还是切片检索？怎么定？

• 按问题类型选，不是按文档大小选。这是最容易答错的地方。
• 整篇/分层摘要：文档小于上下文四分之一、且问题需要全局理解（合同审阅、论文总结、"这份报告的主要风险"）→ 整篇或先做章节摘要树。
• 切片检索：文档大、问题点状（"第三条违约金怎么算"）→ 切片 + Rerank。
• 混合最常见：先按章节生成摘要树，问答时先定位章节，再取原文片段，兼顾成本与精度。
• 两头都要防：整篇塞会丢中间信息且贵；切片会丢跨段逻辑。两层结构才是折中。

五、Agent、工具与评测（Q24–Q30）

Q24. Agent 的工具调用循环，生产上会在哪几个地方坏掉？

• 天真循环"模型提调用 → 执行 → 结果回灌"会在五处翻车：格式错或参数幻觉、任务不终止、有副作用却没分级、重启后状态丢失、用单次调用正确率误判整体质量。
• 五道关：① JSON Schema 校验 + 最多 3 次重试；② 副作用分级——读自由重试，写要幂等键，不可逆（退款/删除/发邮件）必须人工确认；③ 状态与预算——持久化执行轨迹 + 迭代/时间/token 上限；④ 完成分流——完成返答案加轨迹，超限返部分进度和原因；⑤ 验收按任务级成功率，不看单次调用。
• 核心认知：可靠性来自外置的确定性控制层，不来自提示词里写"请小心"。

Q25. MCP 2026-07-28 版改成无状态了，为什么？影响什么？

• 改了什么：去掉 initialize 握手和 Mcp-Session-Id，每个请求自带协议版本、客户端身份、能力（放在 _meta），任何实例都能处理。
• 为什么：原来有状态，负载均衡得做粘性会话，扩缩容和故障转移都难受。改完就能像普通 HTTP 服务一样水平扩。
• 连带变化：服务端主动发起的 sampling/roots/elicitation 改成"多轮往返"——返回 input_required，客户端带答案重试；Streamable HTTP 必须带 Mcp-Method/Mcp-Name 头，方便网关路由和计费；list 结果支持 ttlMs 缓存。
• 对你的影响：自己写 Server 要改成无状态，需要跨调用保留的状态得显式返回 handle 让模型带回来。
• 答题提醒：还在答"握手 + 会话"的，会被认为看的是过期教程。

Q26. 接了一堆 MCP Server，工具描述把上下文吃满了，怎么治？

• 问题有个绰号：Mega Context Problem。每个 Server 的 tool 名称、描述、JSON Schema 都进上下文，接十个可能几万 token，活还没干先烧钱，还会选错工具。
• 五招：① 按会话/意图动态挂载 Server，别全量常驻；② 工具描述精简，参数 Schema 别写成小作文；③ 用 Skills/提示模板按需加载，需要时才把说明拉进来；④ 分层路由——先选 Server 再选 Tool；⑤ 打开 list 缓存。
• 看一个指标：每请求里工具描述的 token 占比，超过 30% 就该动手了。

Q27. Agent 来回横跳、重复调同一个工具，怎么检测和兜底？

• 三种病要分开：重复调用（同工具同参数）、路径震荡（A→B→A→B）、停滞（调了但没新信息）。
• 检测必须外置：动作指纹（工具名 + 参数哈希）判重复；最近 3~5 步的动作序列判震荡；新结果与已有结果的相似度判停滞。max_steps 只做最后熔断。
• 兜底顺序：整理已有结果告知用户 → 转人工确认方向 → 允许换一次策略。别直接抛"执行失败"。
• 两个误判坑：只比工具名不比参数会误杀正常调用；窗口只看两步会把合理重试判成震荡。

Q28. Agent 要执行代码或 SQL，沙箱怎么选？给只读权限就够了吗？

• 选型：Docker 隔离强但启动慢，适合重任务；Wasm 毫秒级启动、资源占用低，适合轻量表达式和短脚本；Serverless 函数天然隔离，运维省心。
• 只读远远不够，至少要五道限制：网络出口默认拒绝、CPU/内存/执行时长配额、最小目录挂载、独立低权限账号、结果大小上限（防拖库）。
• SQL 场景再加四条：只读从库、语法白名单（禁 DDL/DML）、强制 LIMIT、超时自动 kill。
• 一句话：沙箱的目标不是"不让它跑"，是"跑坏了也不出事"。这是面试官想听的那句。

Q29. Agent 任务完成率只有 70%，怎么定位是模型、Prompt、RAG 还是编排的问题？

• 控制变量，逐层剥离，这是标准答法：
  1. 绕过 Agent，把最终输入直接喂模型——输出就乱，是模型能力问题；
  2. 换标准 Prompt 模板——明显提升，是原 Prompt 指令模糊、缺示例；
  3. 关掉 RAG 手工注入正确上下文——提升，是检索内容错/缺/过期；
  4. 手工注入正确工具返回值——提升，是工具参数或返回格式问题；
  5. 以上全正常还失败——编排问题：步骤拆错、顺序错、缺异常分支。
• 配套：每次失败打完整轨迹（输入、决策、工具调用、返回），按失败类型聚类，别一个个看。

Q30. Agent 长任务跑到一半服务重启，怎么断点续跑？

• 前提是状态外置：每步执行完把已完成步骤、中间结果、当前计划落 Redis/DB，带 task_id。
• 恢复流程：读状态 → 跳过已完成步骤 → 断点继续。关键是判断"上一个工具调用到底执行没执行"，靠幂等键 + 状态查询补偿，不能猜。
• 三个坑：状态只在内存，重启全丢；工具不幂等，重放重复扣款；长任务没超时清理，僵尸任务堆积。
• 推荐结构：状态机 + 事件日志，比只存快照好排查，能回放它走了哪几步。

六、今日答题模板（可直接套）

排查类问题（"X 没效果 / Y 变慢了 / 完成率上不去"）：

1. 先给判断依据 → 2. 分层剥离，每层一个可验证实验 → 3. 说清用什么指标/日志确认 → 4. 给兜底和止损 → 5. 补一句长期机制。

设计类问题（"设计一个 XX Agent"）：

1. 先澄清需求（数据范围、权限、并发、预算） → 2. 技术选型一句话 → 3. 讲主链路数据流 → 4. 讲 2~3 个难点和取舍 → 5. 讲怎么评测、怎么监控、怎么降级。

今天最容易被追问的三个数：虚拟线程 pinning 修在 JDK 24（25 进 LTS）、Prompt 缓存读约按 10% 计价、工具描述 token 占比超过 30% 需要治理。记住具体数字，比形容词有说服力。