同为股份秋招C++开发一面与HR面：内存、多线程与RAG项目

《面试题目》

一面

1. 请做自我介绍。
2. C 和 C++ 有什么区别？
3. static 关键字有什么作用？
4. 全局 static 变量初始化时机是在虚函数调用之前还是之后？
5. C++ 智能指针是什么概念？
6. 过往是否遇到内存泄漏，怎么解决？
7. 从 RSS/VSS 看内存使用具体是什么意思？
8. 虚拟内存和物理内存有什么区别？
9. 创建一个线程会消耗多少内存？
10. free 命令中 cache 表示什么？
11. cache 比较少是什么情况？
12. 有什么办法可以手动清 cache？
13. 为什么有时候需要线程池，而不是每次直接创建线程？
14. 多线程写同一个变量需要注意什么？
15. 互斥锁、读写锁、自旋锁有什么区别和使用场景？
16. 单核 CPU 能否使用多线程？是否有必要？
17. 多核 CPU 下线程绑核/亲和性技术的优势和隐患是什么？
18. 项目中有没有遇到 CPU 飙高，怎么处理？
19. RAG 知识库项目是用来解决什么问题？
20. 向量数据库用的是什么？本地部署还是云服务？
21. 有没有考虑过 Agent/Skill 机制？
22. 对岗位和团队有什么问题？

《参考解析》

内存与资源管理：C++ 那几题的落点都是「谁负责释放」

C 与 C++ 的区别别停在「面向过程 vs 面向对象」，更值得说的是 C++ 多出来的工程手段：RAII 让资源跟着对象生命周期走，模板提供零成本抽象，异常和命名空间改变了大程序的错误处理与符号管理方式；同时 C 的编译产物更小、更贴近硬件，所以驱动和底层库仍然用它。static 要按位置分开答——修饰全局变量/函数是限制链接可见性，修饰类的成员变量/函数是脱离对象、全类共享，修饰函数内局部变量则是静态存储期、只在首次执行到时初始化（C++11 起这一步线程安全）。初始化时机那题可以这样切入：全局和命名空间作用域的 static 属于静态存储期，动态初始化发生在 main 之前，而虚函数调用是运行期的事，一般晚于它；但跨编译单元的初始化顺序标准并不保证，构造函数里调虚函数也只会派发到当前已构造的那一层，所以工程上不依赖这个先后关系，宁可改用函数内 static 或显式 init。

智能指针按所有权分：unique_ptr 独占、不可拷贝可移动，shared_ptr 用引用计数共享（控制块本身线程安全，指向的对象不是），weak_ptr 专门用来打断循环引用。被问「遇到过内存泄漏吗」时，讲排查路径比背 API 有效：先用工具确认（Valgrind、ASan/LSan、或者按 RSS 走势判断），再按「谁 new 谁 delete、异常路径是否漏掉」逐个收口，把它改成 RAII 或智能指针持有；循环引用（父子互持、连接被定时器长期吊住）是 shared_ptr 时代最常见的泄漏，用 weak_ptr 打断即可。

内存观测：RSS/VSS、虚拟内存与 free 的 cache

VSS 是进程的地址空间总量，包含已映射但还没落物理页的部分；RSS 是真正驻留在物理内存里的部分，所以看泄漏和真实占用要看 RSS。虚拟内存给每个进程独立的地址空间加页表映射，物理内存由页框承载，访问未驻留页时触发缺页再按需装入——这套机制让进程不必关心别人占了多少内存，也让内存可以被换出、被共享。创建一个线程的内存开销要分两层说：默认栈大小通常是 8MB，那是地址空间预留，实际按首次触碰的页逐步提交，所以真实 RSS 增量通常远小于 8MB，再叠上内核栈和线程控制块；这个默认栈大小是可调的，栈开大之后线程数就成了瓶颈。

free 里的 cache（buff/cache）主要是 page cache，也就是内核为了加速文件读写把磁盘内容缓存在内存里，属于「用了但随时可回收」的部分，不是被进程吃掉的内存。cache 偏少常见于几种情况：刚做过大量需要被回收的读写、系统内存紧张导致内核回收缓存、或者业务用了直接 IO 绕开 page cache。要手动清可以 sync 之后写 /proc/sys/vm/drop_caches，但这只适合排查内存问题的场景——清完缓存，后续文件读都会落到磁盘，吞吐会明显掉一截，生产上不该常规去做。

多线程与性能：线程池、锁的选型与 CPU 飙高怎么查

线程池的价值是复用线程、避免每次创建销毁的系统开销，同时把并发数封顶，避免任务突增时把 CPU 和内存打爆，还方便挂任务队列、优先级和背压；代价是引入队列延迟和调参负担。多线程写同一个变量，要么用锁把它包进临界区，要么用原子操作，要么干脆避免共享——每个线程先写本地变量、最后再合并，通常比抢锁更快；还要留意伪共享，把高频写的变量按缓存行对齐隔开。三种锁按「等不到的时候干什么」来分：互斥锁让线程睡眠等待，适合临界区可能较长的场景；读写锁适合读多写少，但写者可能饥饿、加锁开销也比普通互斥量大；自旋锁原地忙等不睡眠，适合临界区极短且确定不会阻塞的场合，用户态长时间自旋就是白烧 CPU。

单核当然能跑多线程，并发不等于并行——IO 等待多、或者逻辑本身有重叠的时候，多线程能提高吞吐并让代码结构更清晰；但纯计算任务在单核上没有收益，反而多出切换和同步开销。绑核（CPU 亲和性）的好处是减少线程在核间迁移、改善缓存与 TLB 命中、降低延迟抖动，隐患是负载不均、某个核被占满时无处可退，还可能与别的进程互相干扰，所以一般只给延迟敏感的线程绑。CPU 飙高的处理顺序是先定位再动手：top -H 看是用户态还是内核态、哪个线程在烧，用户态用 perf top/火焰图看热点函数，怀疑死循环或锁自旋就 gdb attach 看调用栈，怀疑系统调用频繁就 strace——先分清是代码问题、锁竞争还是外部依赖变慢，再谈优化。

RAG 项目与 HR 面：选型要能讲清取舍

RAG 解决的是大模型「不知道你的私有知识、知识有截止日期、容易编」这三件事：先把资料切块做向量化存进向量库，提问时检索出最相关的片段塞进上下文，让模型基于材料回答，而不是靠参数记忆。向量库选型要看数据规模、延迟要求和团队已有的基础设施——已有 Postgres 且规模不大时 pgvector 最省事，上百万级以上、要高吞吐和多种索引策略再考虑专用向量库，本地部署买的是数据不出内网和可控成本，云服务买的是免运维和弹性，两者都说得过去，关键是能说出自己为什么这么选。Agent/Skill 机制是在 RAG 之上再加「模型可以调工具、按流程多步执行」，适合需要检索之外的动作（查库、调接口、写文件）的场景，纯问答用不上，硬上只会增加不确定性和调试成本。

这一轮技术问题密、但都是可预期的八股加项目追问，准备方式是把简历上每个关键词都往下压三层：说了内存就准备好 RSS/虚拟内存/泄漏排查，说了多线程就准备好锁的取舍和一次真实的 CPU 飙高定位过程。从原帖的时间线看，9.24 一面、9.29 HR 面，节奏很快，HR 面通常只确认到岗时间、意向与薪资区间，前面技术面答得住，这一轮基本就是走流程；原帖作者最后已经拿到 OC。