中电信量子 Java 一面：科研评估与 JVM 基础

《面试题目》

1. 介绍你的科研工作；怎么评估效果提升是 Agent 的设计带来的？怎么评价结果？
2. Java 里 HashMap 的底层结构是什么？如何做到线程安全？
3. JVM 的内存结构是怎样的？
4. String、StringBuffer、StringBuilder 有什么区别？
5. class 文件加载的流程是什么？每一步会触发什么初始化？
6. 子类和父类的静态变量、成员变量、静态方法和成员方法的初始化顺序是怎样的？

《参考解析》

「怎么证明提升来自你的设计」是科研类面试的核心一问，答案是消融实验加可复现的基线。 回答要先立评测框架：任务是什么、指标是什么（准确率、成功率、人工评分、还是成本/延迟）、数据从哪来（自建集还是公开集）、基线是什么（不加你的模块的原系统、以及已有的强基线）。然后才是归因：把你引入的设计拆成可独立开关的几个部件（比如记忆模块、检索策略、编排流程），做逐项的消融对照——每个部件去掉后指标掉多少；如果有多个变量同时改动，就必须单独跑一遍「只改这一个」的实验，否则提升无法归因。统计上还要说明重复次数与方差（跑 3~5 次取均值加区间），避免把噪声当提升。追问通常落在「指标涨了但代价呢」——一定要主动报成本项（token 消耗、延迟、人工标注量），因为很多「效果提升」是拿几倍算力换来的，能说清性价比才是加分项。

HashMap 的底层结构与线程安全要分版本答，并且明确说清为什么它不安全。 JDK 1.8 是数组 + 链表 + 红黑树：哈希扰动后按 (n-1) & hash 定位桶，冲突时挂链表，链表长度到 8 且数组长度到 64 才转红黑树，查询从 O(n) 降到 O(log n)；扩容阈值为容量 × 负载因子（默认 0.75），容量始终是 2 的幂以便用位运算取模；1.8 扩容时通过高低位拆分（hash & oldCap）保持同桶内相对顺序，修掉了 1.7 头插法在并发扩容下形成环形链表导致 CPU 100% 的问题。但它仍然不是线程安全的：并发 put 会丢更新（两个线程同时写空桶）、size 计数不准、扩容期间可能读到未迁移的槽。要线程安全，按场景选：Collections.synchronizedMap（全局锁，简单但并发差）、ConcurrentHashMap（1.8 是 CAS 写空桶 + synchronized 锁单桶头节点，多线程协同扩容）、或 Hashtable（已过时，全表锁）。追问常考 ConcurrentHashMap 为什么不允许多个线程同时扩容同一个桶、以及 size() 为什么只能算弱一致（CounterCell 分散计数）。

JVM 内存结构按「线程私有 / 线程共享 / 直接内存」三层答最清楚。 线程私有的三块：程序计数器（记录当前字节码行号，唯一不会 OOM 的区域）、虚拟机栈（每个方法一个栈帧，含局部变量表、操作数栈、动态链接、返回地址；栈溢出由递归或超深调用触发）、本地方法栈（服务 native 方法）。线程共享的两块：堆（对象实例与数组，分新生代 Eden/Survivor 与老年代，是 GC 主战场，也是 OOM 最常发的地方）、方法区/元空间（类元信息、常量、静态变量；JDK 8 起用本地内存实现，不再受 -XX:MaxPermSize 限制，改成 Metaspace 后要防的是元空间无限增长，常见于动态生成类）。此外还有运行时常量池（字符串常量池在 JDK 7 之后移到堆里）和直接内存（NIO 的 DirectByteBuffer，不受堆大小限制但受机器内存限制，-XX:MaxDirectMemorySize 控制）。追问通常是「对象一定分配在堆上吗」——逃逸分析加标量替换可以在栈上分配、TLAB 是堆内为线程预分配的私有缓冲区，这两个点答上能显出深度。

String 家族的区别要落到「可变性、线程安全、性能、适用场景」四条线上。 String 是不可变类，内部 final 字符数组（JDK 9 起是 byte[] + coder 的紧凑表示），一旦创建不可改，所有「修改」都产生新对象；好处是可安全共享、可做哈希键（hash 缓存）、常量池可复用，代价是循环拼接会产生大量中间对象。StringBuffer 与 StringBuilder 都是可变的字符序列，区别只在同步：StringBuffer 的方法都加了 synchronized，线程安全但每次操作有锁开销；StringBuilder 无锁，单线程下更快，是循环拼接的默认选择。编译期优化要说一句：字面量拼接 "a" + "b" 在编译期就合并成一个常量，但循环内的 += 会被编译成 new StringBuilder().append().toString()，每轮都新建对象——所以循环里必须在外面创建一个 StringBuilder。另外 String 的 + 在 Java 9 之后改走 invokedynamic 的 StringConcatFactory，是针对性的优化，但循环场景的结论不变。

类加载的流程是「加载 → 验证 → 准备 → 解析 → 初始化」五步，初始化时机的触发条件是常考替代问法。 加载：通过全限定名获取二进制字节流，生成方法区里的类结构并把 Class 对象作为方法区数据的访问入口。验证：文件格式、元数据、字节码、符号引用四类检查，保证不会危害虚拟机。准备：为静态变量分配内存并设零值（static int a = 10 在这一步是 0，赋 10 要等初始化），final static 常量在此阶段直接赋字面量值。解析：把常量池里的符号引用替换为直接引用，可以在初始化之后再发生（动态绑定/反射相关）。初始化：执行 <clinit>，即静态变量赋值语句与静态代码块按源码顺序合并执行，父类的 <clinit> 先于子类。主动触发初始化的六种情况要能背：new / 读写静态字段（非 final 常量）/ 调用静态方法 / 反射 / 初始化子类时先初始化父类 / 虚拟机启动时的主类。反向的「不会触发初始化」也很爱考：通过子类引用父类的静态字段只初始化父类；定义数组不初始化元素类型；引用 static final 常量不初始化（编译期已进常量池）。

父子类初始化顺序这类题的标准解法是「分清两个维度：静态先于实例、父类先于子类」。 完整顺序是：父类静态变量与静态代码块（按源码顺序）→ 子类静态变量与静态代码块 → 父类实例变量与实例代码块 → 父类构造方法 → 子类实例变量与实例代码块 → 子类构造方法。要提醒三个陷阱：一是静态部分只在类第一次被初始化时执行一次，之后再 new 不会重复；二是静态方法不参与「初始化顺序」——方法在类加载时就存在，调用哪个方法由编译期静态绑定决定（静态方法不能重写，只能隐藏），不存在「父类静态方法被子类覆盖」这回事；三是实例代码块会在构造方法体之前、super() 调用之后执行，所以父类构造方法里如果调用了被子类重写的方法，会读到子类还没初始化的字段（值为零值/null），这是真实项目里踩过的坑。答这题最好的方式是在纸上把父类、子类的静态块、实例块、构造器的执行序列按行写出来，再说清每个环节为什么。