科大讯飞 Java 线下一面：GC 排查、Linux 与海外业务场景题

《面试题目》

1. full GC 发生时如何排查？
2. 你提到了可以获取 dump 文件，具体用什么命令导出？
3. RocketMQ 作为消息队列一般有什么作用？
4. partition 是什么含义？
5. String 常用方法？
6. Linux 常用命令？
7. Linux 中如何搜索 ERROR 记录？
8. AI 编程和人手动编程有哪些区别？
9. AI 编程目前有哪些问题？
10. 场景题：1 亿个 url，第一步先找出哪些重复，第二步对 url 进行计数。不明确时间和空间限制。
11. 场景题：目前有一个海外平台的知名网红博主，如何找到 100 名和该博主最相似的博主？
12. 场景题：对接各个国家的海外博主，根据报价和实时汇率计算 CPM，报价是已经获取好的文本、需要 AI 解析，AI 接口默认提供但不保证结果正确性；汇率需要自己获取，可能出现博主自行计算结果和工具计算结果不一致的情况。描述整套项目流程与数据库表设计。

《参考解析》

full GC 排查的顺序

先确认频率与耗时，再看它是不是被动的：老年代增长过快、元空间不足、显式 System.gc()、还是大对象直达老年代。结合 GC 日志里的回收前后容量判断是「真泄漏」还是「分配速率太高」。真泄漏就导出堆转储，按占用排序找出持有链；不是泄漏就调堆结构、提高晋升阈值、或者把大对象拆掉。

导出 dump 的常用命令

jmap -dump:live,format=b,file=heap.hprof <pid> 是最直接的；生产上更常用 jcmd <pid> GC.heap_dump /path/heap.hprof。两者都会造成 STW，线上要先摘流量或至少避开高峰。容器里注意 dump 文件要写到挂载卷，否则随容器一起消失；文件可能和堆一样大，提前确认磁盘空间。

RocketMQ 与 partition

消息队列主要解决三件事：异步化（把非主链路动作移出请求路径）、削峰（把突发流量摊平给下游）、解耦（生产者不必知道消费者是谁，可多订阅方）。partition 是同一 Topic 下的并行单位，也是顺序性边界：同一分区内消息按写入顺序被单消费者顺序处理，跨分区不保证顺序。分区数决定了消费并行度的上限，也决定按业务键（如订单号）路由时能否把同一实体的消息固定到同一分区。

Linux 里搜 ERROR

grep -rn "ERROR" /var/log/app/ 定位文件与行号，-i 忽略大小写，-C 5 带上上下文。日志很大的时候用 tail -n 10000 app.log | grep ERROR 先看尾部，或者 grep -c 先统计频次再决定要不要细看。真正的高频做法是给日志加 requestId，先按 ID 把所有相关行捞出来，而不是靠关键词碰运气。

场景题一：亿级 URL 去重与计数

规模远大于内存，用哈希分片思路：先按 URL 的哈希值把数据切成 N 份，保证相同 URL 必落同一份，然后逐份处理，每份就变成内存可容纳的问题。去重可以用位图（Bloom Filter 先筛、再精确校验），计数用哈希表加外部排序归并。如果允许近似，Count-Min Sketch 能给出可控误差的频次估计。要点是主动说明容量估算：每条 URL 平均多少字节、需要多少分片、误判率换来多少内存。

场景题二：找最相似的 100 个博主

把「相似」定义清楚是第一步：内容相似还是粉丝重合，前者用内容向量，后者用共同关注集合。内容路线是把每个博主的作品聚合成向量，用 ANN 索引（HNSW、IVF）做近邻检索，先召回几百个再精排；粉丝重合路线用 MinHash 或 Jaccard 相似度，靠倒排把候选压缩到可算规模。检索之后要加业务过滤：排除同机构、排除已经合作过的，结果才可用。

场景题三：多国博主的 CPM 结算

链路可以拆成四步：报价文本进 AI 解析成结构化字段（金额、币种、口径是 CPM 还是总价），解析结果先落到原始记录并标记置信度；汇率从外部源定时抓取并按日期留存快照，结算时只认当日快照而不是实时值；结算按「报价 × 汇率 × 曝光口径」计算并落一条不可变流水。表设计上至少要区分原始报价表、汇率快照表、结算流水表和差异表——当博主自算结果与我们不一致时，差异表要能指出差在哪一步：解析口径、汇率取值时点，还是四舍五入方式。AI 解析结果永远只当作候选，金额类字段必须能人工校正并留痕。