面灵AI

广联达 AI面 面经(Java后端)

轮次
AI面试
时间
2026-09
来源
牛客网

《面试题目》

  1. 自我介绍
  2. Java 的类加载机制是怎么实现的?
  3. 双亲委派是什么?
  4. 自定义了一个 String 类,最终是否会加载?
  5. 如果就是想加载自定义的 String 类,有哪些办法?
  6. JVM 的内存区域是怎么划分的?
  7. OOM 怎么排查?
  8. 说一下你实习期间主要做的工作?
  9. 说一下 RAG 的执行链路?
  10. 为什么需要查询重写和精排?
  11. 为什么需要同时使用向量检索和关键字检索?
  12. 说一下你实习的收获是什么?

《参考解析》

  1. 类加载机制:一个类从磁盘到可用,要经过加载、验证、准备、解析、初始化五步。加载阶段由类加载器读取字节流、生成方法区中的运行时数据结构并在堆里创建对应的 Class 对象;验证保证字节码不会危害虚拟机;准备给静态变量分配内存并置零值(final 常量此时直接赋真值);解析把符号引用替换成直接引用;初始化才真正执行 <clinit>,也就是静态变量赋值和静态代码块。类加载器分三层:Bootstrap(java.base 等核心库,C++ 实现)、Platform/Extension、Application(classpath),另外还可以自定义。

  2. 双亲委派:类加载器收到加载请求时,先委托父加载器去加载,父加载器加载不了才自己动手。它带来两个好处:一是核心类库不会被应用自己写的同名类替换掉(java.lang.String 永远由 Bootstrap 加载),二是同一个类不会被不同层级的加载器重复加载,保证 Class 对象的唯一性。打破双亲委派也是常见需求,典型场景是 Tomcat 的 Web 应用隔离、OSGi、以及 JDBC 这类需要由父加载器接口去调用子加载器实现的场景(线程上下文类加载器)。

  3. 自定义 String 类会不会被加载:不会。写一个 java.lang.String 放在自己的 classpath 里,AppClassLoader 会先委托给 Bootstrap,而核心库里的 java.lang.String 已经存在,直接返回父加载器加载好的那个类,自定义的版本永远轮不到。想强行加载自己的版本,正常途径基本走不通——ClassLoader.defineClass 明确禁止定义 java.* 开头的类(抛 SecurityException),所以就算重写 loadClass 打破委托,到定义那一步还是会被拦。工程上能做的是换包名做同类能力的替换,或者用 Java agent + Instrumentation.retransformClasses 去改已有类的字节码。

  4. JVM 内存区域:线程私有的有程序计数器、虚拟机栈、本地方法栈;线程共享的有堆和方法区(Java 8 之后是元空间 MetaSpace,用本地内存)。堆又分新生代(Eden + 两个 Survivor)和老年代。JDK 7 起字符串常量池搬到了堆里,JDK 8 起永久代被元空间取代。

  5. OOM 排查:先分清是哪一类 OOM——堆内存、元空间、直接内存还是 GC overhead limit exceeded,堆栈里的报错信息通常会点明。线上先开 -XX:+HeapDumpOnOutOfMemoryError 拿到 dump,用 MAT 看支配树和最大的几个对象,判断是内存泄漏(对象被意外强引用住,比如静态集合、ThreadLocal 没 remove、连接没关)还是单纯内存不够。配合 jstat -gc 看 GC 频率与老年代增长、jcmd 看堆直方图,必要时 jmap -histo:live。常见根因是本地缓存没设上限、批量查询一次拉太多、大文件流全读进内存。

  6. RAG 执行链路:离线侧做文档解析、清洗、分块、向量化后写入向量库并保存元数据;在线侧接收问题后先做查询理解——改写、扩展、指代消解,然后并行跑向量检索和关键字检索,把两路结果归一化融合、去重,再用精排模型对候选做重排序,截断到 Top-K 组装上下文,最后交给大模型生成答案并回填引用来源。

  7. 为什么需要查询重写和精排:用户的问法往往很口语、很短,还带指代和省略,和文档里的书面表述之间存在语义鸿沟,直接拿原问题去检索召回率会很低,所以要用 LLM 或规则把问题改写成更贴近文档语言的多个查询,扩大召回面。精排解决的是另一头的问题:向量检索这类粗排为了速度牺牲了精度,一次召回几十上百条,靠 cross-encoder 逐条对「问题—文档」做交互式打分,才能把真正相关的那几条排到最前面,直接影响最终答案质量。

  8. 为什么向量检索和关键字检索要一起用:两者互补。向量检索擅长语义相似,用户问「怎么避免消息重复消费」能召回讲幂等设计的文档;但它对专有名词、缩写、错误码、版本号这类低频精确 token 不敏感,甚至会把语义相近但实体不同的内容召回进来。关键字检索(BM25/倒排)恰好相反,字面命中精确、可解释,但换个说法就召不回来。工程上通常做成混合检索,用 RRF 之类的方式把两路排名融合,再统一送精排。