新凯来 软件开发一面：Go 项目连环追问与 Java 并发八股

《面试题目》

1. 自我介绍
2. 实习项目：项目是做什么的？为什么用 Gin？你在项目中负责什么？Go 中有缓冲 channel 和无缓冲 channel 有什么区别？
3. 项目一：团队多大、怎么分工的？是个人项目还是实验室项目？核心工作是什么？为什么用 MQTT？模型是自己训练的吗？是端侧本地小模型吗？怎么做的？
4. 项目三：入库链路是怎样的？技术难点是什么？具体怎么解决的？校验失败之后是怎么处理的？
5. 八股（Java）：线程安全怎么实现的？
6. 同步机制和锁的区别是什么？
7. 反射机制了解吗？
8. 栈溢出怎么排查？
9. 反问

《参考解析》

1. 有缓冲与无缓冲 channel 的区别，答「同步语义」而不是只答容量：无缓冲 channel 的发送与接收必须同时就绪，发送方会阻塞到有接收方取走，因此它本身就是一种同步手段（可以用来做「等某个 goroutine 就绪」的信号）；有缓冲 channel 则是队列，缓冲未满时发送方不阻塞、缓冲为空时接收方阻塞，用作解耦与削峰。工程上的取舍是：无缓冲保证「交棒」语义、时序严格但耦合高；有缓冲吞吐更好、抗抖动，但缓冲大小要评估，过大等于把内存当队列、还会掩盖消费端过慢的问题，len(ch) 也不能当作可靠的队列长度来用。再补一句常见坑——缓冲为 0 与 nil channel 的行为完全不同（对 nil channel 读写会永久阻塞），是 Go 面试里的高频追问点。

2. 「为什么用 Gin / 为什么用 MQTT」这类选型题，要答成对比而不是偏好：Gin 的理由通常是轻量、路由基于 radix 树性能好、中间件生态成熟、上手成本低，对比标准库 net/http 需要自己写路由与中间件、对比 Beego 这类全家桶框架又太笨重。MQTT 的理由要落在场景上：它是发布订阅模型、基于 TCP 的轻量协议，报文头小、支持 QoS 分级（0 最多一次、1 至少一次、2 恰好一次）、有遗嘱消息和断线重连，适合带宽受限、连接数多、设备侧网络不稳定的物联网场景；对比 HTTP 轮询的实时性差与开销大、对比 WebSocket 需要自己定义消息语义、对比 Kafka 则在设备量级与协议开销上不匹配。讲选型时把「对比对象 + 场景约束 + 代价」三段说全，面试官就很难继续追问；如果项目实际是照着资料做的，就如实说「参考了某方案的取舍」，同时把上面这套对比讲清楚。

3. 入库链路与「校验失败之后怎么处理」，是考工程闭环：一条完整链路通常是接入（接口或消息队列，先做鉴权与限流）→ 解析与格式校验（字段必填、类型、枚举、长度、时间格式）→ 业务校验（关联对象是否存在、状态是否允许、唯一性）→ 转换与落库（事务写入，必要时分表或批量写）→ 回执与监控（写成功回执，失败进错误表并告警）。校验失败的处理要分层：可重试的瞬时错误（依赖超时、数据库死锁）进重试队列并带退避；不可重试的数据错误（字段非法、关联不存在）落错误表并通知上游，附上原始报文与失败原因，而不是静默丢弃；重复投递靠幂等键（业务唯一键或去重表）保证不重复入库。回答时补一句「失败的数据要有去向、能重放、有责任人」，这就是这道题真正的评分点。

4. Java 线程安全的实现手段，按「不共享 → 不可变 → 同步 → 无锁」排序讲：最彻底的是不共享（线程封闭，用 ThreadLocal 或局部变量），其次是共享不可变对象（final、不可变集合）；必须共享可变状态时用同步：synchronized（方法或代码块，JDK 6 后有偏向锁、轻量级锁的优化）、ReentrantLock（可中断、可超时、可公平、支持多条件队列）、volatile（只保证可见性与禁止重排序，不保证原子性）、以及各种并发容器（ConcurrentHashMap、CopyOnWriteArrayList、BlockingQueue）。无锁方案是 CAS 与原子类（AtomicInteger、LongAdder），代价是 ABA 问题与自旋开销。答题时说清「你保护的是哪份状态、为什么选这个工具」，比背清单更能体现水平。

5. 「同步机制和锁的区别」这类题，本质在考概念层次：锁是具体的实现（synchronized、ReentrantLock），同步是更广的目标与手段——凡是为了协调多个线程的执行顺序、保证共享数据一致性的机制都算同步机制，包括信号量、条件变量（wait/notify、Condition）、屏障（CyclicBarrier）、闭锁（CountDownLatch）、以及阻塞队列。也就是说「锁」是「同步」的一种，同步还包括不靠锁的协调与通信。回答时举一个具体例子：生产者消费者既可以用 synchronized + wait/notify 实现，也可以用 BlockingQueue 实现，后者内部封装了锁与条件队列，对外只暴露同步语义。至于反射，要答出「运行时获取类信息并操作成员」的能力（Class、Method、Field、Constructor，可以突破 private 访问限制），代价是性能损耗与破坏封装，Spring 的依赖注入、动态代理、注解处理都靠它。

6. 栈溢出怎么排查，按「先定位是递归还是数据量」分两条线：StackOverflowError 最常见的原因是无限递归或递归深度过大（缺终止条件、终止条件写错、循环引用），其次是单次调用栈帧过大（方法里定义了超大局部数组）或线程栈设置过小（-Xss）。排查顺序是：看异常栈顶的重复帧，找到循环调用的那个方法名，确认终止条件；用 jstack 抓线程栈看调用深度；必要时临时调大 -Xss 验证是否只是深度问题（能用就不是代码 bug 而是设计问题）。注意和 OOM 区分开：堆内存不足抛的是 OutOfMemoryError: Java heap space，栈溢出是线程私有的栈空间不够，两者的排查路径完全不同。答完可以补一句预防手段——把深递归改写成显式栈的迭代、给递归加深度上限、大数组用堆分配。