恒生电子 Java开发一面凉经（10.10）

《面试题目》

1. 操作系统这门课有哪些记忆点？
2. 进程与线程的区别？
3. Transformer 架构理解 + 应用心得，AI 对于技术架构选型的实际应用经验。
4. 有本地部署过吗？本地参数调优经验。
5. Token 怎么计算？
6. 大模型幻觉是什么？怎么解决？
7. 高并发本地生活项目防超卖的整体链路。
8. 实际工作中方案决策冲突怎么和同事解决？
9. 了解恒生电子吗？
10. 反问。

《参考解析》

操作系统记忆点。这题开放，答成结构化清单最好：进程与线程、CPU 调度（时间片轮转、优先级、多级反馈队列）、内存管理（分页与分段、虚拟内存、缺页中断、页面置换 LRU/Clock）、进程间通信（管道、共享内存、信号量、消息队列、socket）、同步与死锁（四个必要条件、预防与检测）、文件系统与 IO（阻塞/非阻塞、IO 多路复用、零拷贝）。挑一两个展开比罗列更得分，比如虚拟内存：每个进程有独立地址空间，MMU 通过页表把虚拟地址翻译成物理地址，缺页时触发中断、由内核把页从磁盘调入，TLB 缓存最近翻译结果——理解这条链，写高性能程序时就知道为什么要关注局部性和大页。

进程与线程的区别。标准答法是四个维度：资源（进程是资源分配的基本单位，有独立地址空间与文件描述符表；线程是调度的基本单位，同进程内线程共享地址空间和堆，各自有栈和寄存器）、开销（创建、切换、销毁都是进程更大，线程切换不换页表所以便宜）、通信（进程间必须走 IPC，线程间直接读写共享内存但要加同步）、隔离性（一个进程崩溃通常不影响别的进程，一个线程挂掉可能拖垮整个进程）。再补两点会显得理解更深：一是协程/用户态线程把调度搬到应用层，避免内核态切换与阻塞整个线程；二是「线程真的共享一切吗」——栈、寄存器、线程局部存储（TLS）其实是私有的，共享的是堆、全局变量和文件描述符。

Transformer 与它在架构选型上的实际影响。架构上要能说清：输入先做词嵌入加位置编码（自注意力本身对顺序无感，位置信息全靠它），进入多层结构，每层是多头自注意力加前馈网络，中间有残差连接和 LayerNorm；自注意力的核心是 Q、K、V 三个投影，用 softmax(QKᵀ/√d) 得到注意力权重再加权 V，多头让模型在不同子空间里关注不同关系，/√d 是为了防止点积过大导致 softmax 梯度消失。与 RNN 相比，它的优势是训练可以并行、长距离依赖的路径更短，代价是注意力复杂度随序列长度平方增长——这也是长上下文方案（稀疏注意力、分块、KV Cache 优化）的来源。落到架构选型：推理成本主要由上下文长度和输出长度决定，所以设计上要区分「离线预处理」和「在线生成」，把能预先算好的东西（文档切分、摘要、embedding）放到离线，在线只做检索加短生成；KV Cache 让长对话显存占用随轮数增长，因此要设计上下文裁剪与摘要压缩策略。

本地部署与参数调优。答的时候先讲清选型：追求简单用 Ollama，追求吞吐和生产级特性用 vLLM 或 TGI；量化格式上 GGUF 适合 CPU 与消费级显卡，GPTQ/AWQ 适合 GPU 推理。调优的抓手是：显存估算（参数量 × 精度字节数 + KV Cache，7B 的 fp16 大约 14GB 权重，量化到 int4 约 4GB）、max_model_len 与 gpu_memory_utilization、批大小与并发（连续批处理能显著提高吞吐但会抬高首 token 延迟）、KV Cache 的分页管理（PagedAttention）、采样参数（temperature、top_p、top_k、重复惩罚）。要如实说明自己做到哪一步：是跑通了推理、还是做过压测对比过吞吐和延迟。

Token 怎么计算。Token 是模型处理文本的最小单位，不等于字也不等于词，由分词器（BPE、WordPiece 一类）按词表切分。经验值：英文大约 1 token 对应 4 个字符或 0.75 个单词；中文一个字通常 1 到 2 个 token，取决于分词器和词表；代码与专有名词往往切得更碎。精确计算必须用对应模型的分词器（如 tiktoken、HuggingFace 的 tokenizer）跑一遍，不能靠字符数估算。为什么重要：一是成本按输入输出 token 计费，二是上下文窗口是硬上限，三是产品上要给用户展示用量、做预算控制。

大模型幻觉与治理。幻觉指模型生成了流畅但不符合事实或没有依据的内容，根因是它本质在预测下一个 token 的概率分布，而不是在查证事实；训练数据的时效性、长尾知识的稀疏、以及提示里缺少约束都会放大它。治理分三层：输入层做 RAG，把答案约束在检索到的证据上，并要求输出带引用；生成层用结构化输出（JSON Schema / 工具调用）限制自由发挥，对关键字段用枚举和校验，温度调低，必要时让模型先给证据再给结论；输出层做校验与兜底——用规则或第二个模型核对，能给出处的强制给出处，检索不到就明确说「不知道」，而不是编一个。工程上还要有评测集持续量化幻觉率，别靠个案感觉。

防超卖的整体链路。核心原则是「把扣减做成原子操作，并且让重复请求无害」。常见组合：入口限流削峰；库存预热到 Redis，用 Lua 脚本原子判断并预扣（decr 前先比较，避免扣成负数）；预扣成功后再落库，数据库侧用 update stock = stock - 1 where id = ? and stock >= 1 这种带条件的乐观扣减，靠受影响行数判断成败；订单表用唯一索引（用户 + 商品 + 活动）防重复下单；异步下单走 MQ 让流量与数据库解耦，消费端必须幂等；下单失败或超时未支付要有回滚与超时释放（延迟消息或定时任务）；最后用对账任务核对 Redis 与 DB 的库存差，修正漂移。要主动说明每层的失败模式：Redis 挂了怎么办（降级到 DB 条件扣减）、消息丢了怎么办（本地消息表 + 补偿）、超卖已经发生怎么发现（对账 + 告警）。

方案决策冲突怎么处理。别答「我会说服他」，要答流程：先把分歧收敛到可验证的点——我们到底在争哪个指标（一致性还是吞吐、交付时间还是长期维护成本），再各自把方案的代价和失败模式写出来，能压测就压测、能写小 demo 就写 demo，用数据定；如果仍然僵持且时间有限，就把决策权和责任交给明确的 owner，谁负责这一块谁拍板，其他人执行不阳奉阴违，并且把决策和理由写进文档，事后复盘时可以翻；避免的是「会上不说话、会后不执行」和「为了赢而站队」。至于「了解恒生电子吗」，提前查清主营业务（金融科技，服务证券、基金、银行等金融机构）、主要产品线与技术方向，能说出和岗位相关的点即可，别背公司简介。