vault backup: 2026-06-07 23:10:51
This commit is contained in:
+100
-100
@@ -13,7 +13,7 @@ create time: 2026-06-07 14:30
|
||||
|
||||
### 一、Go 语言核心(第 1-13 题)
|
||||
|
||||
- [ ] **Q1. Go 中 goroutine 与操作系统的线程有什么区别?**
|
||||
- [x] **Q1. Go 中 goroutine 与操作系统的线程有什么区别?**
|
||||
A) goroutine 是用户态线程,由 Go runtime 调度
|
||||
B) goroutine 是内核线程,由操作系统调度
|
||||
C) goroutine 和线程完全等价
|
||||
@@ -22,7 +22,7 @@ D) goroutine 只能在 main 函数中运行
|
||||
> [!summary]- Q1 答案与解析
|
||||
> **答案:A** — goroutine 是 Go runtime 管理的用户态轻量级协程,初始栈仅 2KB,可动态伸缩。
|
||||
|
||||
- [ ] **Q2. Go 的 channel 在关闭后发送数据会发生什么?**
|
||||
- [x] **Q2. Go 的 channel 在关闭后发送数据会发生什么?**
|
||||
A) 静默丢弃
|
||||
B) panic: send on closed channel
|
||||
C) 返回 nil
|
||||
@@ -31,7 +31,7 @@ D) 阻塞等待
|
||||
> [!summary]- Q2 答案与解析
|
||||
> **答案:B** — 向已关闭的 channel 发送数据会触发 panic。
|
||||
|
||||
- [ ] **Q3. sync.WaitGroup 的 Add、Done、Wait 方法调用顺序正确的是?**
|
||||
- [x] **Q3. sync.WaitGroup 的 Add、Done、Wait 方法调用顺序正确的是?**
|
||||
A) Wait() → Add() → Done()
|
||||
B) Add() → 启动 goroutine 调用 Done() → Wait()
|
||||
C) Done() → Add() → Wait()
|
||||
@@ -40,7 +40,7 @@ D) 任意顺序均可
|
||||
> [!summary]- Q3 答案与解析
|
||||
> **答案:B** — Add() 必须在 Wait() 之前调用,且 Add(n) 中的 n 应大于 0。
|
||||
|
||||
- [ ] **Q4. Go Context 的主要用途是什么?**
|
||||
- [x] **Q4. Go Context 的主要用途是什么?**
|
||||
A) 管理内存分配
|
||||
B) 传递取消信号、截止时间与请求作用域值
|
||||
C) 实现 HTTP 路由
|
||||
@@ -49,7 +49,7 @@ D) 替代 struct field
|
||||
> [!summary]- Q4 答案与解析
|
||||
> **答案:B** — Context 用于控制 goroutine 生命周期(取消/超时)和传递跨 API 边界的请求级数据。
|
||||
|
||||
- [ ] **Q5. Go 的 GC(垃圾回收)使用的是什么算法?**
|
||||
- [x] **Q5. Go 的 GC(垃圾回收)使用的是什么算法?**
|
||||
A) 引用计数
|
||||
B) Mark-Sweep
|
||||
C) Mark-Compact
|
||||
@@ -58,7 +58,7 @@ D) 三色标记 + 混合写屏障(Concurrent Mark & Sweep)
|
||||
> [!summary]- Q5 答案与解析
|
||||
> **答案:D** — Go 采用并发三色标记清除算法,配合混洗写屏障保证性能。
|
||||
|
||||
- [ ] **Q6. 在 Go 中,make([]int, 0, 10) 创建的切片其 len 和 cap 分别为?**
|
||||
- [x] **Q6. 在 Go 中,make([]int, 0, 10) 创建的切片其 len 和 cap 分别为?**
|
||||
A) len=0, cap=10
|
||||
B) len=10, cap=10
|
||||
C) len=0, cap=0
|
||||
@@ -67,7 +67,7 @@ D) len=10, cap=0
|
||||
> [!summary]- Q6 答案与解析
|
||||
> **答案:A** — make 第三个参数为容量,长度默认为第一个参数。
|
||||
|
||||
- [ ] **Q7. Go 的 select 语句在没有 case 可选时会怎样?**
|
||||
- [x] **Q7. Go 的 select 语句在没有 case 可选时会怎样?**
|
||||
A) 返回 nil
|
||||
B) 编译报错
|
||||
C) 永久阻塞
|
||||
@@ -76,7 +76,7 @@ D) panic
|
||||
> [!summary]- Q7 答案与解析
|
||||
> **答案:C** — 没有 default case 的 select 在所有 channel 不可操作时永久阻塞。
|
||||
|
||||
- [ ] **Q8. go 的 defer 语句执行时机是什么?**
|
||||
- [x] **Q8. go 的 defer 语句执行时机是什么?**
|
||||
A) 函数结束时按声明顺序执行
|
||||
B) 函数结束时逆序(LIFO)执行
|
||||
C) goroutine 退出时执行
|
||||
@@ -85,7 +85,7 @@ D) return 之后立即执行
|
||||
> [!summary]- Q8 答案与解析
|
||||
> **答案:B** — defer 压入栈,函数返回时以 LIFO 顺序弹出执行。
|
||||
|
||||
- [ ] **Q9. Go 接口类型的底层结构包括几个部分?**
|
||||
- [x] **Q9. Go 接口类型的底层结构包括几个部分?**
|
||||
A) 1 个:指向数据的指针
|
||||
B) 2 个:类型信息和数据指针
|
||||
C) 3 个:类型、数据、虚表
|
||||
@@ -94,7 +94,7 @@ D) 4 个
|
||||
> [!summary]- Q9 答案与解析
|
||||
> **答案:B** — 接口由 iface 组成:type(类型信息)和 data(数据指针)。
|
||||
|
||||
- [ ] **Q10. Go 的 reflect.TypeOf 返回的是什么?**
|
||||
- [x] **Q10. Go 的 reflect.TypeOf 返回的是什么?**
|
||||
A) 变量的运行时值
|
||||
B) 变量编译时的静态类型
|
||||
C) 变量的动态类型信息(interface{} 的具体类型)
|
||||
@@ -103,7 +103,7 @@ D) 变量的内存地址
|
||||
> [!summary]- Q10 答案与解析
|
||||
> **答案:C** — TypeOf 在运行时获取 interface{} 所持有值的实际类型。
|
||||
|
||||
- [ ] **Q11. Go 的 race detector 通过什么实现?**
|
||||
- [x] **Q11. Go 的 race detector 通过什么实现?**
|
||||
A) 静态分析编译器标志
|
||||
B) -race 编译标志,在源码级别插入探测代码
|
||||
C) 运行时 GC 监控
|
||||
@@ -112,7 +112,7 @@ D) pprof profile
|
||||
> [!summary]- Q11 答案与解析
|
||||
> **答案:B** — go build -race 会在源码级别插入读写探测代码来检测数据竞争。
|
||||
|
||||
- [ ] **Q12. Go 的 map 在并发读写时会怎样?**
|
||||
- [x] **Q12. Go 的 map 在并发读写时会怎样?**
|
||||
A) 自动加锁
|
||||
B) panic: concurrent map reads and writes
|
||||
C) 只读安全,只写不安全
|
||||
@@ -121,7 +121,7 @@ D) 取决于 Go 版本
|
||||
> [!summary]- Q12 答案与解析
|
||||
> **答案:B** — 原生 map 不是并发安全的,需用 sync.Map 或加 mutex。
|
||||
|
||||
- [ ] **Q13. Go 标准库中 net/http 默认是否有连接池?**
|
||||
- [x] **Q13. Go 标准库中 net/http 默认是否有连接池?**
|
||||
A) 没有,每次请求新建 TCP 连接
|
||||
B) 有,Transport 内置 Keep-Alive 连接复用
|
||||
C) 需要手动配置才能启用
|
||||
@@ -132,7 +132,7 @@ D) 仅在 HTTP/2 下才有
|
||||
|
||||
### 二、Go Web 开发 & 项目实战(第 14-23 题)
|
||||
|
||||
- [ ] **Q14. 【Gen2D】Eino Agent Graph 编排四阶段管线(Prompt优化→素材生成→质量校验→格式适配),本质上属于什么结构?**
|
||||
- [x] **Q14. 【Gen2D】Eino Agent Graph 编排四阶段管线(Prompt优化→素材生成→质量校验→格式适配),本质上属于什么结构?**
|
||||
A) 简单的 for-loop 串行执行
|
||||
B) DAG 有向无环图,节点间定义依赖关系后按拓扑序执行
|
||||
C) 并行随机组合,哪个先完成哪个先输出
|
||||
@@ -141,7 +141,7 @@ D) 基于消息队列的异步回调链
|
||||
> [!summary]- Q14 答案与解析
|
||||
> **答案:B** — DAG 确保依赖关系正确:质量校验节点只有在前一个"素材生成"节点完成后才可触发,形成确定的执行拓扑。
|
||||
|
||||
- [ ] **Q15. 【Gen2D】Reflect 自省机制在 AI Agent 管线中的作用是?**
|
||||
- [x] **Q15. 【Gen2D】Reflect 自省机制在 AI Agent 管线中的作用是?**
|
||||
A) 让 Agent 自我评估输出质量,不达标时将拒绝理由回注提示词修正
|
||||
B) 加密生成结果中的数据隐私字段
|
||||
C) 加速 LLM 推理过程
|
||||
@@ -150,7 +150,7 @@ D) 替代向量数据库做语义检索
|
||||
> [!summary]- Q15 答案与解析
|
||||
> **答案:A** — Self-reflection 使 Agent 形成闭环:生成→评判→修正→再生成,逐步提升输出质量;同时支持注入用户反馈进行定向引导。
|
||||
|
||||
- [ ] **Q16. 【Gen2D】针对 LLM 请求耗时长特性,项目中设计了 IO 密集型协程池 + RabbitMQ,以下哪种方案最能解释为什么不用 errgroup.SetLimit 代替?
|
||||
- [x] **Q16. 【Gen2D】针对 LLM 请求耗时长特性,项目中设计了 IO 密集型协程池 + RabbitMQ,以下哪种方案最能解释为什么不用 errgroup.SetLimit 代替?
|
||||
A) errgroup 不能限制并发数
|
||||
B) errgroup 要求所有任务在程序启动时就全部提交,无法处理持续流入的请求
|
||||
C) errgroup 不支持错误传播
|
||||
@@ -159,7 +159,7 @@ D) 两者功能完全一样,只是个人偏好
|
||||
> [!summary]- Q16 答案与解析
|
||||
> **答案:B** — errgroup 适用于一次性有限任务集,而 LLM 请求是持续流入的流式场景,需要协程池常驻 Worker 从消息队列拉取并处理新任务。
|
||||
|
||||
- [ ] **Q17. 【Gen2D】令牌桶限流 vs 漏桶限流的选择对比中,正确的描述是?**
|
||||
- [x] **Q17. 【Gen2D】令牌桶限流 vs 漏桶限流的选择对比中,正确的描述是?**
|
||||
A) 令牌桶允许突发流量,漏桶是匀速输出;选择令牌桶是为了容忍用户的批量生成请求
|
||||
B) 令牌桶更简单,漏桶实现复杂
|
||||
C) 漏桶不允许任何峰值,所以不适合任何业务场景
|
||||
@@ -168,7 +168,7 @@ D) 两者完全一样,只是叫法不同
|
||||
> [!summary]- Q17 答案与解析
|
||||
> **答案:A** — 令牌桶积累令牌允许短时间内突发消费,适合 Gen2D 中用户可能批量提交的场景;漏桶以固定速率出水,严格平滑但不够灵活。
|
||||
|
||||
- [ ] **Q18. 在 Go 的 Gin 框架中使用 c.ShouldBindJSON() 失败时会怎样?**
|
||||
- [x] **Q18. 在 Go 的 Gin 框架中使用 c.ShouldBindJSON() 失败时会怎样?**
|
||||
A) 返回 nil
|
||||
B) 自动调用 c.AbortWithError() 返回 400,并终止后续 handler 执行
|
||||
C) 忽略错误继续执行
|
||||
@@ -177,7 +177,7 @@ D) panic
|
||||
> [!summary]- Q18 答案与解析
|
||||
> **答案:B** — ShouldBindJSON 绑定失败会自动返回 400 Bad Request 并终止后续 handler 执行,防止无效数据进入业务逻辑。
|
||||
|
||||
- [ ] **Q19. Gin 框架中 Middleware 的执行顺序是怎样的?**
|
||||
- [x] **Q19. Gin 框架中 Middleware 的执行顺序是怎样的?**
|
||||
A) 随机
|
||||
B) 注册顺序,先注册先执行、后返回(类似洋葱模型)
|
||||
C) 先注册的后执行
|
||||
@@ -186,7 +186,7 @@ D) 只在出错时执行
|
||||
> [!summary]- Q19 答案与解析
|
||||
> **答案:B** — Gin 中间件按注册顺序依次执行,每个中间件可选择是否放行(调用 c.Next()),形如洋葱模型。
|
||||
|
||||
- [ ] **Q20. GORM 中 Preload 和 Joins 的区别是?**
|
||||
- [x] **Q20. GORM 中 Preload 和 Joins 的区别是?**
|
||||
A) 无区别,都是 N+1 查询
|
||||
B) Preload 用额外 SELECT 加载关联,Joins 用 SQL JOIN 合并查询
|
||||
C) Preload 只能用于一对多关系
|
||||
@@ -195,7 +195,7 @@ D) Joins 总是比 Preload 快
|
||||
> [!summary]- Q20 答案与解析
|
||||
> **答案:B** — Preload 执行两次查询(主表 + 关联表),Joins 合并为一次 LEFT JOIN;Preload 能避免 Joins 带来的行膨胀问题。
|
||||
|
||||
- [ ] **Q21. GORM AutoMigrate 的功能是什么?**
|
||||
- [x] **Q21. GORM AutoMigrate 的功能是什么?**
|
||||
A) 迁移数据库版本号
|
||||
B) 自动创建/alter 表结构以匹配 struct tag
|
||||
C) 备份数据库数据
|
||||
@@ -204,7 +204,7 @@ D) 加密字段
|
||||
> [!summary]- Q21 答案与解析
|
||||
> **答案:B** — AutoMigrate 根据 struct 定义自动建表或调整列(不删列),适合开发期快速迭代。
|
||||
|
||||
- [ ] **Q22. Gin Router 的 LoadHTMLGlob() 和 LoadHTMLFiles() 有何区别?**
|
||||
- [x] **Q22. Gin Router 的 LoadHTMLGlob() 和 LoadHTMLFiles() 有何区别?**
|
||||
A) Glob 接受路径模式(如 "templates/*")加载目录所有模板,Files 需逐个指定文件名
|
||||
B) Glob 只能加载 HTML,Files 可以加载任何文件
|
||||
C) 无实质区别
|
||||
@@ -213,7 +213,7 @@ D) Files 支持通配符
|
||||
> [!summary]- Q22 答案与解析
|
||||
> **答案:A** — Glob 接受路径模式,Files 需逐个指定文件名。实际项目中模板渲染较少使用,更多直接 JSON 响应。
|
||||
|
||||
- [ ] **Q23. Gin 中 c.Bind() 和 c.ShouldBind() 的差异是?**
|
||||
- [x] **Q23. Gin 中 c.Bind() 和 c.ShouldBind() 的差异是?**
|
||||
A) c.Bind() 出错时 panic(被 recover 捕获后返回 400),c.ShouldBind() 显式返回 error
|
||||
B) c.ShouldBind() 出错时 panic
|
||||
C) 两者相同
|
||||
@@ -224,7 +224,7 @@ D) c.Bind() 更快
|
||||
|
||||
### 三、Go 高级特性 & RabbitMQ(第 24-30 题)
|
||||
|
||||
- [ ] **Q24. Go 的 pool(协程池)主要解决的问题是?**
|
||||
- [x] **Q24. Go 的 pool(协程池)主要解决的问题是?**
|
||||
A) 减少 goroutine 频繁创建销毁开销,控制最大并发
|
||||
B) 避免死锁
|
||||
C) 代替 channel
|
||||
@@ -233,7 +233,7 @@ D) 提升 GC 速度
|
||||
> [!summary]- Q24 答案与解析
|
||||
> **答案:A** — 协程池复用 goroutine 避免大量短命协程的创建/销毁成本,尤其对 IO 密集型任务有价值,同时限制并发数防止后端服务被打满。
|
||||
|
||||
- [ ] **Q25. RabbitMQ 中 Exchange 的类型不包括?**
|
||||
- [x] **Q25. RabbitMQ 中 Exchange 的类型不包括?**
|
||||
A) direct
|
||||
B) topic
|
||||
C) random
|
||||
@@ -242,7 +242,7 @@ D) headers
|
||||
> [!summary]- Q25 答案与解析
|
||||
> **答案:C** — RabbitMQ 四种 Exchange:direct、topic、headers、fanout。没有 random 类型。
|
||||
|
||||
- [ ] **Q26. RabbitMQ 消息持久化需要哪三个步骤协同配合?**
|
||||
- [x] **Q26. RabbitMQ 消息持久化需要哪三个步骤协同配合?**
|
||||
A) Queue durable=true + Message delivery_mode=2 + Publisher Confirm
|
||||
B) Queue auto-delete=true + Message transient
|
||||
C) 仅需 Queue durable
|
||||
@@ -251,7 +251,7 @@ D) 只需 Message delivery_mode=2
|
||||
> [!summary]- Q26 答案与解析
|
||||
> **答案:A** — 三者缺一不可:队列表征明确、消息标记持久化到磁盘、Publisher Confirm 确保 Broker 已接收。缺少任一环节都可能在异常时丢消息。
|
||||
|
||||
- [ ] **Q27. Go 中 context.WithTimeout 和 context.WithDeadline 的区别是?**
|
||||
- [x] **Q27. Go 中 context.WithTimeout 和 context.WithDeadline 的区别是?**
|
||||
A) 无区别,完全等价
|
||||
B) WithTimeout = Now + duration(相对时长),WithDeadline = 绝对时间戳
|
||||
C) WithDeadline 只能用于 HTTP
|
||||
@@ -260,7 +260,7 @@ D) WithTimeout 不支持 cancel
|
||||
> [!summary]- Q27 答案与解析
|
||||
> **答案:B** — 一个是相对时长(如 30s),一个是绝对 Time(如 time.Now().Add(30s)),内部实现相同。
|
||||
|
||||
- [ ] **Q28. RabbitMQ 中 Consumer Ack 的目的是?**
|
||||
- [x] **Q28. RabbitMQ 中 Consumer Ack 的目的是?**
|
||||
A) 告诉 Broker 消息已处理成功,可从队列移除
|
||||
B) 增加消息延迟
|
||||
C) 触发重试
|
||||
@@ -269,7 +269,7 @@ D) 改变消息优先级
|
||||
> [!summary]- Q28 答案与解析
|
||||
> **答案:A** — Ack 确认消费成功;Nack 可重新入队或丢弃。Auto Ack 虽然方便但在消费失败时会直接丢消息,生产环境应手动 Ack。
|
||||
|
||||
- [ ] **Q29. Go 泛型中 type constraint 使用 interface 而不是 class,原因是?**
|
||||
- [x] **Q29. Go 泛型中 type constraint 使用 interface 而不是 class,原因是?**
|
||||
A) Go 没有 class
|
||||
B) Go 的 interface 支持结构化子类型(隐式满足 / duck-typing)
|
||||
C) class 太复杂
|
||||
@@ -278,7 +278,7 @@ D) 语法限制
|
||||
> [!summary]- Q29 答案与解析
|
||||
> **答案:B** — Go interface 是 duck-typing,任何实现了对应方法的类型自动满足约束,无需显式 implements 声明。
|
||||
|
||||
- [ ] **Q30. Go 的 unsafe.Pointer 能做什么?**
|
||||
- [x] **Q30. Go 的 unsafe.Pointer 能做什么?**
|
||||
A) 绕过类型安全进行内存操作
|
||||
B) 替代 malloc
|
||||
C) 创建新 thread
|
||||
@@ -289,7 +289,7 @@ D) 优化 GC
|
||||
|
||||
### 四、Java 语言核心(第 31-42 题)
|
||||
|
||||
- [ ] **Q31. Java 中 HashMap 的默认负载因子和初始容量是?**
|
||||
- [x] **Q31. Java 中 HashMap 的默认负载因子和初始容量是?**
|
||||
A) 0.5, 8
|
||||
B) 0.75, 16
|
||||
C) 0.75, 8
|
||||
@@ -298,7 +298,7 @@ D) 0.8, 16
|
||||
> [!summary]- Q31 答案与解析
|
||||
> **答案:B** — load factor 0.75,initial capacity 16。0.75 是在空间利用率和冲突概率之间的折中。
|
||||
|
||||
- [ ] **Q32. Java ConcurrentHashMap 在 JDK 8+ 使用什么结构?**
|
||||
- [x] **Q32. Java ConcurrentHashMap 在 JDK 8+ 使用什么结构?**
|
||||
A) 单纯链表
|
||||
B) Array + LinkedList
|
||||
C) Array + LinkedList + Red-Black Tree(树化阈值 8)
|
||||
@@ -307,7 +307,7 @@ D) Hash Table
|
||||
> [!summary]- Q32 答案与解析
|
||||
> **答案:C** — 桶内链表节点数 ≥8 且数组长度 ≥64 时转为红黑树,将最坏查找复杂度从 O(n) 降到 O(log n)。
|
||||
|
||||
- [ ] **Q33. Java synchronized 和 ReentrantLock 的核心区别是?**
|
||||
- [x] **Q33. Java synchronized 和 ReentrantLock 的核心区别是?**
|
||||
A) synchronized 是 JVM 层面(字节码指令),ReentrantLock 是 API 层面的显式锁
|
||||
B) 两者完全等价
|
||||
C) ReentrantLock 不能中断等待
|
||||
@@ -316,7 +316,7 @@ D) synchronized 支持 condition
|
||||
> [!summary]- Q33 答案与解析
|
||||
> **答案:A** — synchronized 由 JVM 内置实现,依托 monitorenter/monitorexit 指令;ReentrantLock 提供 tryLock、lockInterruptibly 等更灵活的 API。
|
||||
|
||||
- [ ] **Q34. Java Callable 和 Runnable 的区别是?**
|
||||
- [x] **Q34. Java Callable 和 Runnable 的区别是?**
|
||||
A) Callable 可返回值并能抛出 checked exception
|
||||
B) Runnable 更快
|
||||
C) Callable 不能异步执行
|
||||
@@ -325,7 +325,7 @@ D) Runnable 是 Java 8 引入
|
||||
> [!summary]- Q34 答案与解析
|
||||
> **答案:A** — Callable<V>.call() 返回 V 并可 throw Exception,Runnable.run() 无返回值也不能抛受检异常。
|
||||
|
||||
- [ ] **Q35. Java Spring Bean 的作用域不包括?**
|
||||
- [x] **Q35. Java Spring Bean 的作用域不包括?**
|
||||
A) singleton
|
||||
B) prototype
|
||||
C) request
|
||||
@@ -334,7 +334,7 @@ D) coroutine
|
||||
> [!summary]- Q35 答案与解析
|
||||
> **答案:D** — Spring 五大作用域:singleton、prototype、request、session、application。coroutine 不属于 Spring 范畴。
|
||||
|
||||
- [ ] **Q36. Spring 中 @Autowired 默认是按什么注入?**
|
||||
- [x] **Q36. Spring 中 @Autowired 默认是按什么注入?**
|
||||
A) 按 name
|
||||
B) 按 type(byType)
|
||||
C) 按 constructor
|
||||
@@ -343,7 +343,7 @@ D) 按 index
|
||||
> [!summary]- Q36 答案与解析
|
||||
> **答案:B** — 默认按 byType 匹配;当容器中存在同名多个 bean 时才 fallback 到 byName。
|
||||
|
||||
- [ ] **Q37. MyBatis 中 #{ } 和 ${ } 的区别是?**
|
||||
- [x] **Q37. MyBatis 中 #{ } 和 ${ } 的区别是?**
|
||||
A) #{} 是预编译占位符防 SQL 注入,${} 是直接字符串拼接
|
||||
B) 两者完全一样
|
||||
C) ${} 更安全
|
||||
@@ -352,7 +352,7 @@ D) #{} 只用于字符串
|
||||
> [!summary]- Q37 答案与解析
|
||||
> **答案:A** — #{ } 使用 PreparedStatement 的参数绑定(PreparedStatement.setXXX),${ } 是原始文本替换。优先使用 #{ }。
|
||||
|
||||
- [ ] **Q38. Java 中 volatile 关键字保证哪些属性?**
|
||||
- [x] **Q38. Java 中 volatile 关键字保证哪些属性?**
|
||||
A) 可见性 + 原子性
|
||||
B) 可见性 + 有序性,不保证原子性
|
||||
C) 只有原子性
|
||||
@@ -361,7 +361,7 @@ D) 没有保证
|
||||
> [!summary]- Q38 答案与解析
|
||||
> **答案:B** — volatile 保证可见性(MESI 缓存一致性协议)和禁止指令重排,但不保证复合操作(如 i++)的原子性。
|
||||
|
||||
- [ ] **Q39. Java 线程池中 corePoolSize 和 maximumPoolSize 的关系是?**
|
||||
- [x] **Q39. Java 线程池中 corePoolSize 和 maximumPoolSize 的关系是?**
|
||||
A) corePoolSize ≤ maximumPoolSize
|
||||
B) 可以任意大小
|
||||
C) 必须相等
|
||||
@@ -370,7 +370,7 @@ D) core > max
|
||||
> [!summary]- Q39 答案与解析
|
||||
> **答案:A** — 核心线程数不能超过最大线程数。当核心线程全部繁忙时才会创建超额线程,直到达到 maximumPoolSize。
|
||||
|
||||
- [ ] **Q40. Java 8 Stream 中 flatMap() 和 map() 的区别是?**
|
||||
- [x] **Q40. Java 8 Stream 中 flatMap() 和 map() 的区别是?**
|
||||
A) flatMap 将嵌套集合展平为一层,map 是一对一转换
|
||||
B) 两者完全一样
|
||||
C) flatMap 更慢
|
||||
@@ -379,7 +379,7 @@ D) map 可以展平
|
||||
> [!summary]- Q40 答案与解析
|
||||
> **答案:A** — map(Stream<T>) 得到 Stream<Stream<T>>,flatMap 直接将所有内部 Stream 的元素展平为一个 Stream<T>。
|
||||
|
||||
- [ ] **Q41. Java Optional.ofNullable(null) 的行为是?**
|
||||
- [x] **Q41. Java Optional.ofNullable(null) 的行为是?**
|
||||
A) 返回 Optional.empty()
|
||||
B) 返回 null
|
||||
C) panic
|
||||
@@ -388,7 +388,7 @@ D) NullPointerException
|
||||
> [!summary]- Q41 答案与解析
|
||||
> **答案:A** — ofNullable 允许 null 值,null 时返回 empty();Optional.of(null) 才会抛 NPE。
|
||||
|
||||
- [ ] **Q42. Java Spring 中 @Controller 和 @RestController 的区别是?**
|
||||
- [x] **Q42. Java Spring 中 @Controller 和 @RestController 的区别是?**
|
||||
A) @RestController = @Controller + @ResponseBody
|
||||
B) 完全一样
|
||||
C) @Controller 不能返回 JSON
|
||||
@@ -399,7 +399,7 @@ D) @RestController 不能做视图渲染
|
||||
|
||||
### 五、Spring Boot & MyBatis-Plus(第 43-49 题)
|
||||
|
||||
- [ ] **Q43. Spring Boot Starter 的作用是?**
|
||||
- [x] **Q43. Spring Boot Starter 的作用是?**
|
||||
A) 自动化配置依赖组合,按需装配相关组件
|
||||
B) 编译加速
|
||||
C) 单元测试框架
|
||||
@@ -408,7 +408,7 @@ D) 部署工具
|
||||
> [!summary]- Q43 答案与解析
|
||||
> **答案:A** — Starter 通过 spring.factories 或 AutoConfiguration 自动装配相关配置类,如 spring-boot-starter-web 自动配置 Tomcat + Spring MVC。
|
||||
|
||||
- [ ] **Q44. MyBatis-Plus 中 IService 和 BaseMapper 的区别是?**
|
||||
- [x] **Q44. MyBatis-Plus 中 IService 和 BaseMapper 的区别是?**
|
||||
A) IService 提供 CRUD 通用方法,BaseMapper 只做单表 Mapper 操作
|
||||
B) 无区别
|
||||
C) BaseService 包含 BaseMapper
|
||||
@@ -417,7 +417,7 @@ D) BaseMapper 是 MyBatis 原生的
|
||||
> [!summary]- Q44 答案与解析
|
||||
> **答案:A** — IService<T> 封装了常用的增删改查、分页等方法(如 getById、list、saveBatch),BaseMapper<T> 是对应实体表的 Mapper 接口。
|
||||
|
||||
- [ ] **Q45. Spring Boot 的自动装配原理核心注解是?**
|
||||
- [x] **Q45. Spring Boot 的自动装配原理核心注解是?**
|
||||
A) @EnableAutoConfiguration
|
||||
B) @ComponentScan
|
||||
C) @Configuration
|
||||
@@ -426,7 +426,7 @@ D) @Import
|
||||
> [!summary]- Q45 答案与解析
|
||||
> **答案:A** — @EnableAutoConfiguration 通过 @Import(AutoConfigurationImportSelector.class) 加载 META-INF/spring.factories 中配置的自动装配类。
|
||||
|
||||
- [ ] **Q46. MyBatis-Plus 的 @TableId(type = IdType.AUTO) 含义是?**
|
||||
- [x] **Q46. MyBatis-Plus 的 @TableId(type = IdType.AUTO) 含义是?**
|
||||
A) 主键由数据库自增
|
||||
B) 使用雪花算法
|
||||
C) UUID
|
||||
@@ -435,7 +435,7 @@ D) 雪花+本地 Snowflake
|
||||
> [!summary]- Q46 答案与解析
|
||||
> **答案:A** — AUTO 依赖数据库自增序列;ASSIGN_ID 才是雪花算法(AssignId),ASSIGN_UUID 使用不带横线的 UUID。
|
||||
|
||||
- [ ] **Q47. Spring Cloud Gateway 与传统 Zuul 1.x 的区别是?**
|
||||
- [x] **Q47. Spring Cloud Gateway 与传统 Zuul 1.x 的区别是?**
|
||||
A) Gateway 基于 Reactor 非阻塞(Netty),Zuul 1.x 是 Servlet 阻塞式(Tomcat)
|
||||
B) 无区别
|
||||
C) Zuul 更快
|
||||
@@ -444,7 +444,7 @@ D) Gateway 不支持负载均衡
|
||||
> [!summary]- Q47 答案与解析
|
||||
> **答案:A** — Spring Cloud Gateway 基于 Spring WebFlux (Netty),非阻塞响应式模型,吞吐量更高;Zuul 1.x 基于 Servlet,每个请求占用一个线程。
|
||||
|
||||
- [ ] **Q48. MyBatis 一级缓存和二级缓存的区别是?**
|
||||
- [x] **Q48. MyBatis 一级缓存和二级缓存的区别是?**
|
||||
A) 一级是 SqlSession 级别(默认开启且无法关闭),二级是 Namespace/Mapper 级别(需手动配置)
|
||||
B) 一级是全局的
|
||||
C) 二级默认开启
|
||||
@@ -453,7 +453,7 @@ D) 一级可跨 Session
|
||||
> [!summary]- Q48 答案与解析
|
||||
> **答案:A** — 一级缓存在同一个 SqlSession 内生效;二级缓存需 enableCache=true,同 namespace 的所有 Session 共享。
|
||||
|
||||
- [ ] **Q49. Spring Boot Actuator 主要用于?**
|
||||
- [x] **Q49. Spring Boot Actuator 主要用于?**
|
||||
A) 监控和管理应用(健康检查、指标暴露等)
|
||||
B) 热修复代码
|
||||
C) 前端打包
|
||||
@@ -464,7 +464,7 @@ D) 自动生成 UI
|
||||
|
||||
### 六、Redis(第 50-62 题)
|
||||
|
||||
- [ ] **Q50. Redis 的 RDB 和 AOF 两种持久化方式的比较中,正确的是?**
|
||||
- [x] **Q50. Redis 的 RDB 和 AOF 两种持久化方式的比较中,正确的是?**
|
||||
A) RDB 基于快照,恢复快但可能丢数据;AOF 逐条记录追加,更安全但文件更大
|
||||
B) AOF 基于快照
|
||||
C) RDB 实时性更好
|
||||
@@ -473,7 +473,7 @@ D) AOF 不可能丢数据
|
||||
> [!summary]- Q50 答案与解析
|
||||
> **答案:A** — RDB 定期 fork 子进程写快照;AOF 每条写入命令追加到 .aof 文件。生产常用 AOF=appendonly + appendfsync=everysec 的折中方案。
|
||||
|
||||
- [ ] **Q51. Redis 哨兵模式的自动故障转移流程是?**
|
||||
- [x] **Q51. Redis 哨兵模式的自动故障转移流程是?**
|
||||
A) Master fail → Sentinel 投票选 New Master → 提升 Slave → 通知 clients
|
||||
B) Master fail → 直接切换
|
||||
C) Master fail → Slave 自动提升(无需投票)
|
||||
@@ -482,7 +482,7 @@ D) 需要人工介入
|
||||
> [!summary]- Q51 答案与解析
|
||||
> **答案:A** — 哨兵通过 is-master-down-by-addr 探测失败,quorum 确认后 election 选出 new master,然后用 SLAVEOF NO ONE 提升它。
|
||||
|
||||
- [ ] **Q52. Redis 的持久化策略 appendfsync 三种模式安全性从高到低排列是?**
|
||||
- [x] **Q52. Redis 的持久化策略 appendfsync 三种模式安全性从高到低排列是?**
|
||||
A) always > everysec > no
|
||||
B) no > everysec > always
|
||||
C) everysec > always > no
|
||||
@@ -491,7 +491,7 @@ D) always = everysec
|
||||
> [!summary]- Q52 答案与解析
|
||||
> **答案:A** — always 每条 fsync(最安全,性能最低);everysec 每秒 fsync(折中,最多丢失 1s 数据);no 交由 OS 决定。
|
||||
|
||||
- [ ] **Q53. Redis Set 数据类型不支持的操作是?**
|
||||
- [x] **Q53. Redis Set 数据类型不支持的操作是?**
|
||||
A) union
|
||||
B) intersection
|
||||
C) difference
|
||||
@@ -500,7 +500,7 @@ D) range by index(范围索引查询)
|
||||
> [!summary]- Q53 答案与解析
|
||||
> **答案:D** — Set 是无序的哈希集合,不支持按位置索引;List 才支持 LRANGE。
|
||||
|
||||
- [ ] **Q54. Redis 发布订阅模式中,客户端断线后会怎样?**
|
||||
- [x] **Q54. Redis 发布订阅模式中,客户端断线后会怎样?**
|
||||
A) 收不到断线期间发布的消息
|
||||
B) 断线重连后可收到历史消息
|
||||
C) 自动 rejoin 上次 channel
|
||||
@@ -509,7 +509,7 @@ D) Redis 会自动缓存消息
|
||||
> [!summary]- Q54 答案与解析
|
||||
> **答案:A** — Pub/Sub 是 fire-and-forget,不持久化消息;需要持久化可用 Redis Streams 或 MQ。
|
||||
|
||||
- [ ] **Q55. Redis Pipeline 的优势是?**
|
||||
- [x] **Q55. Redis Pipeline 的优势是?**
|
||||
A) 减少 RTT(往返延迟),批量命令一次网络往返
|
||||
B) 增加数据一致性
|
||||
C) 替代事务
|
||||
@@ -518,7 +518,7 @@ D) 提高单个命令吞吐量
|
||||
> [!summary]- Q55 答案与解析
|
||||
> **答案:A** — 管道将多个命令打包在一次网络往返中,显著降低网络开销。例如 100 次 GET 原本需 100 RTT,Pipeline 只需 1 RTT。
|
||||
|
||||
- [ ] **Q56. Redis Cluster 分片是基于?**
|
||||
- [x] **Q56. Redis Cluster 分片是基于?**
|
||||
A) 哈希槽(Hash Slot),共 16384 个
|
||||
B) 按 key 字母排序
|
||||
C) 随机分配
|
||||
@@ -527,7 +527,7 @@ D) 按 value 大小
|
||||
> [!summary]- Q56 答案与解析
|
||||
> **答案:A** — CRC16(key) % 16384 定位 slot,每个 slot 映射到一个主节点。可使用 Hash Tag {} 强制多个 key 路由到同一 slot。
|
||||
|
||||
- [ ] **Q57. Redis 的 Keyspace Notification 功能可以用于?**
|
||||
- [x] **Q57. Redis 的 Keyspace Notification 功能可以用于?**
|
||||
A) 监听 key 过期事件,触发业务逻辑
|
||||
B) 替代 pub/sub
|
||||
C) 替代 Lua
|
||||
@@ -536,7 +536,7 @@ D) 压缩内存
|
||||
> [!summary]- Q57 答案与解析
|
||||
> **答案:A** — 可通过 CONFIG SET notify-keyspace-events KEA 开启 key 过期通知,常用于缓存失效时刷新。注意:不适用于高吞吐场景,可靠性不如 MQ。
|
||||
|
||||
- [ ] **Q58. Redis 的 HGETALL 在高版本优化后的行为是?**
|
||||
- [x] **Q58. Redis 的 HGETALL 在高版本优化后的行为是?**
|
||||
A) 不再一次性全部返回大 hash,需改用 HSCAN 避免阻塞
|
||||
B) 变得更慢了
|
||||
C) 改为异步输出
|
||||
@@ -545,7 +545,7 @@ D) 返回压缩格式
|
||||
> [!summary]- Q58 答案与解析
|
||||
> **答案:A** — HGETALL 对小 hash 仍一次性返回,大 hash 推荐使用 HSCAN 游标迭代,避免阻塞主线程。
|
||||
|
||||
- [ ] **Q59. Redis 的 ZSET(Sorted Set)分数相同时如何排序?**
|
||||
- [x] **Q59. Redis 的 ZSET(Sorted Set)分数相同时如何排序?**
|
||||
A) 按 member 字典序
|
||||
B) 随机
|
||||
C) 插入顺序
|
||||
@@ -554,7 +554,7 @@ D) 按 value 大小
|
||||
> [!summary]- Q59 答案与解析
|
||||
> **答案:A** — 分数相同情况下,Redis 按 member 字符串的字典序排序。这是 Redis 的内部实现细节,常被遗漏导致排序不符合预期。
|
||||
|
||||
- [ ] **Q60. Redis 中 DEL 命令删除一个不存在的 key 会怎样?**
|
||||
- [x] **Q60. Redis 中 DEL 命令删除一个不存在的 key 会怎样?**
|
||||
A) 返回 0(无效操作)
|
||||
B) panic
|
||||
C) 阻塞
|
||||
@@ -563,7 +563,7 @@ D) 自动重建 key
|
||||
> [!summary]- Q60 答案与解析
|
||||
> **答案:A** — DEL key 对于不存在 key 返回整数 0,不会报错。
|
||||
|
||||
- [ ] **Q61. Redis 的 Maxmemory-policy 设置 allkeys-lru 的含义是?**
|
||||
- [x] **Q61. Redis 的 Maxmemory-policy 设置 allkeys-lru 的含义是?**
|
||||
A) 所有 key 遵循 LRU 淘汰策略
|
||||
B) 仅 expired keys
|
||||
C) 永不淘汰
|
||||
@@ -572,7 +572,7 @@ D) 随机淘汰
|
||||
> [!summary]- Q61 答案与解析
|
||||
> **答案:A** — 对所有 key 近似 LRU 淘汰(采样 5 个取最旧的),直到内存低于 maxmemory。vsramble-lru 则是仅淘汰已过期的 key 中最近最少使用的。
|
||||
|
||||
- [ ] **Q62. Redis String 类型的 max size 是多少?**
|
||||
- [x] **Q62. Redis String 类型的 max size 是多少?**
|
||||
A) 512 MB
|
||||
B) 1 GB(理论上限)
|
||||
C) 256 MB
|
||||
@@ -583,7 +583,7 @@ D) 1 TB
|
||||
|
||||
### 七、MySQL(第 63-74 题)
|
||||
|
||||
- [ ] **Q63. MySQL InnoDB 默认的隔离级别是?**
|
||||
- [x] **Q63. MySQL InnoDB 默认的隔离级别是?**
|
||||
A) READ COMMITTED
|
||||
B) REPEATABLE READ
|
||||
C) READ UNCOMMITTED
|
||||
@@ -592,7 +592,7 @@ D) SERIALIZABLE
|
||||
> [!summary]- Q63 答案与解析
|
||||
> **答案:B** — 默认 RR(Repeatable Read),通过 MVCC + Next-Key Lock 防止幻读。
|
||||
|
||||
- [ ] **Q64. MySQL 的 B+ 树索引相比 B 树的优势是?**
|
||||
- [x] **Q64. MySQL 的 B+ 树索引相比 B 树的优势是?**
|
||||
A) 范围查询更高效,所有数据都在叶子节点并通过双向链表串联
|
||||
B) 查询更快
|
||||
C) 存储空间更小
|
||||
@@ -601,7 +601,7 @@ D) 不支持前缀索引
|
||||
> [!summary]- Q64 答案与解析
|
||||
> **答案:A** — B+ 树的非叶子节点只存 key(不存 value),树的高度更低;叶子节点通过链表串联,非常适合范围扫描。
|
||||
|
||||
- [ ] **Q65. MySQL 中 EXPLAIN 的 type 字段值 best→worst 排列正确的是?**
|
||||
- [x] **Q65. MySQL 中 EXPLAIN 的 type 字段值 best→worst 排列正确的是?**
|
||||
A) system > const > eq_ref > ref > range > index > ALL
|
||||
B) ALL > index > range > ref > eq_ref > const > system
|
||||
C) const > system > ref > range > index > ALL > eq_ref
|
||||
@@ -610,7 +610,7 @@ D) 无固定顺序
|
||||
> [!summary]- Q65 答案与解析
|
||||
> **答案:A** — 从左到右扫描效率递减,system/const 最优,ALL 是全表扫描最差。日常优化目标至少达到 range 级别。
|
||||
|
||||
- [ ] **Q66. MySQL 的 MVCC 通过什么实现?**
|
||||
- [x] **Q66. MySQL 的 MVCC 通过什么实现?**
|
||||
A) Undo Log + Read View
|
||||
B) Redo Log
|
||||
C) Binlog
|
||||
@@ -619,7 +619,7 @@ D) Buffer Pool
|
||||
> [!summary]- Q66 答案与解析
|
||||
> **答案:A** — 每行隐藏 rollback pointer 指向 undo log 版本链,当前事务通过 read view 决定能看到哪个版本的数据。RC 级别每次 SELECT 创建新 read view,RR 级别首次 SELECT 创建。
|
||||
|
||||
- [ ] **Q67. MySQL 的 binlog 三种格式 ROW/STATEMENT/MIXED 中,哪种记录最多数据量但最安全?**
|
||||
- [x] **Q67. MySQL 的 binlog 三种格式 ROW/STATEMENT/MIXED 中,哪种记录最多数据量但最安全?**
|
||||
A) ROW 格式,记录每一行的变更前后值
|
||||
B) STATEMENT,记录原始 SQL
|
||||
C) MIXED
|
||||
@@ -628,7 +628,7 @@ D) 都一样
|
||||
> [!summary]- Q67 答案与解析
|
||||
> **答案:A** — ROW 格式记录每行变更前后的完整值,精确可还原且不受 SQL 语义影响(如 NOW()、UUID())。STATEMENT 节省空间但有复制风险。
|
||||
|
||||
- [ ] **Q68. MySQL 中唯一索引和普通索引在存储上的差异是?**
|
||||
- [x] **Q68. MySQL 中唯一索引和普通索引在存储上的差异是?**
|
||||
A) 唯一索引强制要求列值不重复,插入重复 key 时抛 Duplicate Key Error
|
||||
B) 普通索引更快
|
||||
C) 唯一索引不能用 Covering Index
|
||||
@@ -637,7 +637,7 @@ D) 无差异
|
||||
> [!summary]- Q68 答案与解析
|
||||
> **答案:A** — 唯一索引维护唯一约束,与普通索引在 B+ 树存储结构上没有本质差异,但多了唯一性校验逻辑。
|
||||
|
||||
- [ ] **Q69. MySQL 联合索引 (a, b, c) 可以用到索引的最长连续前缀是?**
|
||||
- [x] **Q69. MySQL 联合索引 (a, b, c) 可以用到索引的最长连续前缀是?**
|
||||
A) (a), (a,b), (a,b,c)
|
||||
B) (b), (c)
|
||||
C) (a, c)
|
||||
@@ -646,7 +646,7 @@ D) (b, c)
|
||||
> [!summary]- Q69 答案与解析
|
||||
> **答案:A** — 最左前缀原则:必须从左边第一个列开始连续匹配。(a, c) 只能用 a 部分的索引,跳过的 b 会导致后面的 c 失效。
|
||||
|
||||
- [ ] **Q70. MySQL 中 DELETE 和 TRUNCATE 的区别是?**
|
||||
- [x] **Q70. MySQL 中 DELETE 和 TRUNCATE 的区别是?**
|
||||
A) DELETE 逐行删除可回滚(DML),TRUNCATE 释放页面不可回滚(DDL)
|
||||
B) 无区别
|
||||
C) TRUNCATE 更慢
|
||||
@@ -655,7 +655,7 @@ D) DELETE 不能带 WHERE
|
||||
> [!summary]- Q70 答案与解析
|
||||
> **答案:A** — DELETE 是 DML 语句走事务日志,可 WHERE 过滤并回滚;TRUNCATE 是 DDL 直接重置表空间,不可回滚,执行更快。
|
||||
|
||||
- [ ] **Q71. MySQL 的事务 ACID 中,Atomicity(原子性)由什么保证?**
|
||||
- [x] **Q71. MySQL 的事务 ACID 中,Atomicity(原子性)由什么保证?**
|
||||
A) Undo Log(回滚段)
|
||||
B) Redo Log(重做日志)
|
||||
C) Buffer Pool
|
||||
@@ -664,7 +664,7 @@ D) Binlog
|
||||
> [!summary]- Q71 答案与解析
|
||||
> **答案:A** — Undo Log 记录事务修改前的旧值,支持回滚以实现原子性。Redo Log 保障的是 Durability(持久性)。
|
||||
|
||||
- [ ] **Q72. MySQL 缓冲池(Buffer Pool)命中率接近 100% 意味着?**
|
||||
- [x] **Q72. MySQL 缓冲池(Buffer Pool)命中率接近 100% 意味着?**
|
||||
A) 几乎都在内存中访问,磁盘 IO 极少
|
||||
B) 物理内存不足
|
||||
C) 磁盘性能差
|
||||
@@ -673,7 +673,7 @@ D) 查询效率低
|
||||
> [!summary]- Q72 答案与解析
|
||||
> **答案:A** — 高命中率说明绝大部分数据已在内存中,减少磁盘 I/O。计算公式 = (Hits / (Hits + Misses)) × 100%。
|
||||
|
||||
- [ ] **Q73. MySQL 中 GROUP BY 默认会对结果集进行什么操作?**
|
||||
- [x] **Q73. MySQL 中 GROUP BY 默认会对结果集进行什么操作?**
|
||||
A) 隐式排序(会产生 extra filesort)
|
||||
B) 过滤
|
||||
C) 更新
|
||||
@@ -682,7 +682,7 @@ D) 分片
|
||||
> [!summary]- Q73 答案与解析
|
||||
> **答案:A** — 未开启 ONLY_FULL_GROUP_BY 时,GROUP BY 隐式 ORDER BY,会产生 extra filesort。加上该模式或在查询中显式 ORDER BY NULL 可跳过排序。
|
||||
|
||||
- [ ] **Q74. MySQL 中 PRIMARY KEY 和 UNIQUE KEY 能否共存?**
|
||||
- [x] **Q74. MySQL 中 PRIMARY KEY 和 UNIQUE KEY 能否共存?**
|
||||
A) 能,一个表可以有多个 UNIQUE 但只有一个 PRIMARY KEY
|
||||
B) 不能,二选一
|
||||
C) 可以互为别名
|
||||
@@ -693,7 +693,7 @@ D) PRIMARY KEY 也是 UNIQUE KEY 的一种
|
||||
|
||||
### 八、高并发设计 & 缓存策略(第 75-84 题)
|
||||
|
||||
- [ ] **Q75. Write-Behind(回写)缓存策略的特点是什么?**
|
||||
- [x] **Q75. Write-Behind(回写)缓存策略的特点是什么?**
|
||||
A) 先写缓存再异步落库,提升写入吞吐;牺牲强一致性换取高性能
|
||||
B) 先落库再写缓存
|
||||
C) 同步双写
|
||||
@@ -702,7 +702,7 @@ D) 只写不存
|
||||
> [!summary]- Q75 答案与解析
|
||||
> **答案:A** — 写入先命中缓存层即刻返回,后台定时批量刷盘。ThumbUP 点赞系统采用此策略:Redis 承接写入 → 10 秒时间片分桶 → 定时任务批量落库。
|
||||
|
||||
- [ ] **Q76. 二级缓存的设计目的通常是?**
|
||||
- [x] **Q76. 二级缓存的设计目的通常是?**
|
||||
A) 热点数据在本地减少远程调用,冷数据不落 L1 减少污染
|
||||
B) 替代单级缓存
|
||||
C) 加快 GC
|
||||
@@ -711,7 +711,7 @@ D) 减少 CPU 消耗
|
||||
> [!summary]- Q76 答案与解析
|
||||
> **答案:A** — L1 本地缓存存极热点数据(零网络开销),L2 远端缓存作为后备。ThumbUP 采用 Caffeine + Redis 二级:热点 Key 提升至本地缓存,降低 Redis 访问压力。
|
||||
|
||||
- [ ] **Q77. HeavyKeeper 算法主要用于解决什么问题?**
|
||||
- [x] **Q77. HeavyKeeper 算法主要用于解决什么问题?**
|
||||
A) Top-K 热点 Key 探测
|
||||
B) 数据加密
|
||||
C) 网络拥塞控制
|
||||
@@ -720,7 +720,7 @@ D) 分布式事务
|
||||
> [!summary]- Q77 答案与解析
|
||||
> **答案:A** — HeavyKeeper 通过最小堆 + 概率衰减机制,自适应流量变化持续追踪高频热点。ThumbUP 用它识别热门内容的点赞请求,避免穿透到 DB。
|
||||
|
||||
- [ ] **Q78. 令牌桶限流相比漏桶的区别在于?**
|
||||
- [x] **Q78. 令牌桶限流相比漏桶的区别在于?**
|
||||
A) 令牌桶允许突发流量,漏桶是匀速输出
|
||||
B) 令牌桶更简单
|
||||
C) 漏桶不允许峰值
|
||||
@@ -729,7 +729,7 @@ D) 两者完全一样
|
||||
> [!summary]- Q78 答案与解析
|
||||
> **答案:A** — 令牌桶积累令牌允许短时间内突发消费;漏桶以固定速率出水,不突发。Go-redis 实现的令牌桶限流存储在 Redis 中,适合分布式场景。
|
||||
|
||||
- [ ] **Q79. 点赞系统中 Lua 脚本保证原子性的目的是?**
|
||||
- [x] **Q79. 点赞系统中 Lua 脚本保证原子性的目的是?**
|
||||
A) 原子地读取-判断-递增,防止并发冲突
|
||||
B) 减少网络 IO
|
||||
C) 替代 Redis
|
||||
@@ -738,7 +738,7 @@ D) 持久化
|
||||
> [!summary]- Q79 答案与解析
|
||||
> **答案:A** — Lua 脚本在 Redis 中串行执行,确保 incr + TTL 逻辑不被中间状态打断。Lua 不仅做到批量执行,还能做条件判断——这是 Pipeline 和 MULTI/EXEC 做不到的。
|
||||
|
||||
- [ ] **Q80. 补偿任务的目的是?**
|
||||
- [x] **Q80. 补偿任务的目的是?**
|
||||
A) 兜底修复因异常导致的数据不一致(如未落库记录)
|
||||
B) 加速写入
|
||||
C) 替代定时任务
|
||||
@@ -747,7 +747,7 @@ D) 清除过期数据
|
||||
> [!summary]- Q80 答案与解析
|
||||
> **答案:A** — 定时批量写回可能因崩溃、网络异常等导致部分记录未落库。补偿任务定期对账(如 Redis 增量与 DB 统计比对)补齐丢失数据,保障最终一致性。
|
||||
|
||||
- [ ] **Q81. Redis 中利用字符串常量池作为锁对象的好处是?**
|
||||
- [x] **Q81. Redis 中利用字符串常量池作为锁对象的好处是?**
|
||||
A) 同用户串行执行,不同用户并行,减少不必要的互斥
|
||||
B) 节省内存
|
||||
C) 加快 GC
|
||||
@@ -756,7 +756,7 @@ D) 替代数据库锁
|
||||
> [!summary]- Q81 答案与解析
|
||||
> **答案:A** — ThumbUP 中以 "like:" + user_id 为粒度实现细粒度并行锁,避免了全局大锁导致的瓶颈。Java 字符串常量池保证相同内容的字符串指向同一对象,天然适合作为锁标识。
|
||||
|
||||
- [ ] **Q82. Redis 时间片分桶暂存增量的好处是?**
|
||||
- [x] **Q82. Redis 时间片分桶暂存增量的好处是?**
|
||||
A) 将分散的单次请求聚合为批处理请求,减少 DB 写入次数
|
||||
B) 减少 Redis 压力
|
||||
C) 替代 MQ
|
||||
@@ -765,7 +765,7 @@ D) 实现秒级 TPS
|
||||
> [!summary]- Q82 答案与解析
|
||||
> **答案:A** — 10 秒窗口内攒一批后再统一落库,比如 1000 次点赞聚合为 100 批 INSERT(每批 10 秒累积),大幅降低 DB 写入频率。
|
||||
|
||||
- [ ] **Q83. Caffeine 本地缓存相比 Guava Cache 的优势之一是?**
|
||||
- [x] **Q83. Caffeine 本地缓存相比 Guava Cache 的优势之一是?**
|
||||
A) W-TinyLFU 淘汰算法更接近 LRU 但更轻量
|
||||
B) 支持远程复制
|
||||
C) 更大内存上限
|
||||
@@ -774,7 +774,7 @@ D) 内置集群功能
|
||||
> [!summary]- Q83 答案与解析
|
||||
> **答案:A** — Caffeine 采用 W-TinyLFU(滑动窗口 Tiny-Filter LFU),命中率接近 LRU 但代价更低(内存开销仅为 LRU 的几分之一)。它是 Spring Cache 的默认实现。
|
||||
|
||||
- [ ] **Q84. Redis 的 watch 命令实现了什么功能?**
|
||||
- [x] **Q84. Redis 的 watch 命令实现了什么功能?**
|
||||
A) 乐观锁——监视 key 并在 multi/exec 时校验是否被修改
|
||||
B) 悲观锁
|
||||
C) 分区
|
||||
@@ -785,7 +785,7 @@ D) 复制
|
||||
|
||||
### 九、Docker & CI/CD(第 85-90 题)
|
||||
|
||||
- [ ] **Q85. Docker 多阶段构建的主要优势是?**
|
||||
- [x] **Q85. Docker 多阶段构建的主要优势是?**
|
||||
A) 最终镜像体积更小(只保留产物不含构建工具,如 JRE 代替 OpenJDK SDK)
|
||||
B) 自动部署
|
||||
C) 更快的网络
|
||||
@@ -794,7 +794,7 @@ D) 取代 K8s
|
||||
> [!summary]- Q85 答案与解析
|
||||
> **答案:A** — 不同 stage 分别完成编译和打包,COPY --from= 只拷贝最终产物到新镜像。知无涯项目中,Builder 阶段含 Maven/OpenJDK,Runner 阶段仅含 JRE,镜像体积可缩减 80%+。
|
||||
|
||||
- [ ] **Q86. Dockerfile 中 RUN、CMD、ENTRYPOINT 的区别是?**
|
||||
- [x] **Q86. Dockerfile 中 RUN、CMD、ENTRYPOINT 的区别是?**
|
||||
A) RUN 构建时执行,CMD 和 ENTRYPOINT 运行时执行(CMD 可被 docker run 覆盖)
|
||||
B) 三者完全相同
|
||||
C) CMD 在构建时执行
|
||||
@@ -803,7 +803,7 @@ D) ENTRYPOINT 可以被覆盖
|
||||
> [!summary]- Q86 答案与解析
|
||||
> **答案:A** — RUN 在镜像构建阶段执行,产生新的镜像层;ENTRYPOINT 为主命令不易变,CMD 是默认参数可被 docker run args 覆盖。
|
||||
|
||||
- [ ] **Q87. GitHub Actions 中 workflow_dispatch 触发器用于?**
|
||||
- [x] **Q87. GitHub Actions 中 workflow_dispatch 触发器用于?**
|
||||
A) 手动触发工作流
|
||||
B) Git push 自动触发
|
||||
C) PR 合并后触发
|
||||
@@ -812,7 +812,7 @@ D) cron 定时触发
|
||||
> [!summary]- Q87 答案与解析
|
||||
> **答案:A** — 通过 UI 点击手动触发,常用于测试新流水线配置或紧急发布。Gitea Actions 中也支持相同的触发器。
|
||||
|
||||
- [ ] **Q88. CI/CD 流水线中各阶段的典型顺序是?**
|
||||
- [x] **Q88. CI/CD 流水线中各阶段的典型顺序是?**
|
||||
A) Lint 检查 → 单元测试 → 构建镜像 → 推送镜像 → 部署
|
||||
B) 部署 → Lint 检查 → 单元测试 → 构建镜像
|
||||
C) 构建镜像 → Lint 检查 → 单元测试
|
||||
@@ -821,7 +821,7 @@ D) 单元测试在最晚的阶段,因为需要完整构建
|
||||
> [!summary]- Q88 答案与解析
|
||||
> **答案:A** — Lint 是最快发现规范问题的步骤,放在测试和构建之前以减少无效流水线运行。知无涯项目中飞书推送集成在每一步通过后触发通知。
|
||||
|
||||
- [ ] **Q89. Docker Compose 中 depends_on 的作用局限性是?**
|
||||
- [x] **Q89. Docker Compose 中 depends_on 的作用局限性是?**
|
||||
A) 仅表示服务间依赖顺序,不等待容器内进程就绪
|
||||
B) 自动重启失败的容器
|
||||
C) 管理环境变量
|
||||
@@ -830,7 +830,7 @@ D) 自动拉取镜像
|
||||
> [!summary]- Q89 答案与解析
|
||||
> **答案:A** — depends_on 只保证启动顺序,需要配合 healthcheck 或 wait-for-it 脚本才能确保服务可用。例如数据库容器启动了但还没完成初始化,此时应用连接仍会失败。
|
||||
|
||||
- [ ] **Q90. CI/CD 流水线中集成飞书 Lark SDK 推送流水线状态的价值是?**
|
||||
- [x] **Q90. CI/CD 流水线中集成飞书 Lark SDK 推送流水线状态的价值是?**
|
||||
A) 研发团队可实时感知构建结果,缩短故障发现和响应时间
|
||||
B) 替代单元测试
|
||||
C) 减少服务器资源消耗
|
||||
@@ -841,7 +841,7 @@ D) 自动修复构建失败的代码
|
||||
|
||||
### 十、SaaS 架构 & 微服务(第 91-96 题)
|
||||
|
||||
- [ ] **Q91. 微服务架构中最核心的挑战之一是?**
|
||||
- [x] **Q91. 微服务架构中最核心的挑战之一是?**
|
||||
A) 分布式一致性/跨服务通信
|
||||
B) 代码编写难度
|
||||
C) 内存占用
|
||||
@@ -850,7 +850,7 @@ D) CPU 使用率
|
||||
> [!summary]- Q91 答案与解析
|
||||
> **答案:A** — 服务间调用带来延迟、幂等、Saga/TCC 事务一致性等难题。Tcode 平台的 SaaS 多租户架构本身就是一组协作的微服务。
|
||||
|
||||
- [ ] **Q92. gRPC 默认使用的序列化协议是?**
|
||||
- [x] **Q92. gRPC 默认使用的序列化协议是?**
|
||||
A) Protobuf
|
||||
B) JSON
|
||||
C) XML
|
||||
@@ -859,7 +859,7 @@ D) MessagePack
|
||||
> [!summary]- Q92 答案与解析
|
||||
> **答案:A** — Protobuf 二进制编码,体积小、解析快,优于 JSON。gRPC 基于 HTTP/2,天然支持多路复用和流式传输。
|
||||
|
||||
- [ ] **Q93. SaaS 多租户架构中三种常见数据隔离方案的 Trade-off 是?**
|
||||
- [x] **Q93. SaaS 多租户架构中三种常见数据隔离方案的 Trade-off 是?**
|
||||
A) Level 1 独立库(最强隔离、最高成本)、Level 2 独立 Schema(折中)、Level 3 共用表 tenant_id(最低成本、隔离最弱)
|
||||
B) 一种:共享表
|
||||
C) 五种方案
|
||||
@@ -868,7 +868,7 @@ D) 两种:独立库和共享 Schema
|
||||
> [!summary]- Q93 答案与解析
|
||||
> **答案:A** — Tcode 平台选择哪种方案取决于租户的安全等级和规模:大客户用独立库,中小客户共享 Schema,免费用户共用表。隔离越强,运维成本越高。
|
||||
|
||||
- [ ] **Q94. RBAC(Role-Based Access Control)权限模型中的核心实体关系是?**
|
||||
- [x] **Q94. RBAC(Role-Based Access Control)权限模型中的核心实体关系是?**
|
||||
A) User 绑定 Role,Role 赋予 Permission,通过角色间接授权
|
||||
B) User 直接绑定 Permission,无需角色
|
||||
C) Department → Permission
|
||||
@@ -877,7 +877,7 @@ D) Tenant → Service
|
||||
> [!summary]- Q94 答案与解析
|
||||
> **答案:A** — User–Role–Permission 三层模型解耦了"谁能做什么"的直接映射,新增权限只需调整角色即可影响一组用户。Tcode 平台在此基础上扩展了树状组织架构的行列级权限。
|
||||
|
||||
- [ ] **Q95. 树状组织架构(部门层级)在 SaaS 平台中常见的实现方式不包括?**
|
||||
- [x] **Q95. 树状组织架构(部门层级)在 SaaS 平台中常见的实现方式不包括?**
|
||||
A) 邻接表 Adjacency List(父节点引用)
|
||||
B) 物化路径 Materialized Path(存储完整路径字符串)
|
||||
C) 嵌套集 Nested Sets
|
||||
@@ -886,7 +886,7 @@ D) Redis Hash 直接存储全量树
|
||||
> [!summary]- Q95 答案与解析
|
||||
> **答案:D** — Redis Hash 适合扁平键值存取,不支持高效的层级查询和子树遍历。树架构通常用邻接表(最简单)、物化路径(路径查询高效)或嵌套集(子树查询快但更新成本高)。
|
||||
|
||||
- [ ] **Q96. 【金银湖实习】RAG 模块中构建组件漏洞知识图谱的典型流程是?**
|
||||
- [x] **Q96. 【金银湖实习】RAG 模块中构建组件漏洞知识图谱的典型流程是?**
|
||||
A) 抽取组件三元组(组件名-漏洞类型-CVE编号)→ 存入图数据库 → 关联风险传播路径
|
||||
B) 写入 MySQL 普通表
|
||||
C) 纯 NLP 模型直接生成报告
|
||||
@@ -897,7 +897,7 @@ D) 人工标注
|
||||
|
||||
### 十一、AI & RAG(第 97-100 题)
|
||||
|
||||
- [ ] **Q97. RAG(Retrieval-Augmented Generation)的核心思想是?**
|
||||
- [x] **Q97. RAG(Retrieval-Augmented Generation)的核心思想是?**
|
||||
A) 从外部知识库检索相关信息,再让 LLM 基于这些资料生成回答
|
||||
B) 训练更大的模型
|
||||
C) 替换 Transformer 架构
|
||||
@@ -906,7 +906,7 @@ D) 直接微调全模型
|
||||
> [!summary]- Q97 答案与解析
|
||||
> **答案:A** — RAG 将检索与生成解耦,避免全量微调,实时更新知识库成本低。金银湖实验室中 RAG 为安全检测模块提供最新漏洞情报。
|
||||
|
||||
- [ ] **Q98. 【Gen2D】Eino Agent Graph 编排 Prompt 优化→素材生成→质量校验→格式适配管线,本质上是?**
|
||||
- [x] **Q98. 【Gen2D】Eino Agent Graph 编排 Prompt 优化→素材生成→质量校验→格式适配管线,本质上是?**
|
||||
A) DAG 有向无环图工作流,保证节点按拓扑顺序执行
|
||||
B) 简单的 for-loop
|
||||
C) 随机采样
|
||||
@@ -915,7 +915,7 @@ D) 并行随机组合
|
||||
> [!summary]- Q98 答案与解析
|
||||
> **答案:A** — DAG 确保依赖关系正确:只有前置节点完成才可进入下一阶段。这种编排模式支持灵活替换单个节点(如更换 LLM 模型而不影响管线其他部分)。
|
||||
|
||||
- [ ] **Q99. Reflect 自省机制在 AI Agent 中的作用是?**
|
||||
- [x] **Q99. Reflect 自省机制在 AI Agent 中的作用是?**
|
||||
A) 让 Agent 自我评估输出质量,不达标时自动回注提示词修正
|
||||
B) 加密数据
|
||||
C) 加速推理
|
||||
@@ -924,7 +924,7 @@ D) 替代向量数据库
|
||||
> [!summary]- Q99 答案与解析
|
||||
> **答案:A** — Self-reflection 使 Agent 形成闭环:生成→评判→修正→再生成,逐步提升质量。Gen2D 项目中还支持注入用户反馈,让 Agent 理解偏好并持续改进。
|
||||
|
||||
- [ ] **Q100. 构建组件漏洞知识图谱的典型流程是?**
|
||||
- [x] **Q100. 构建组件漏洞知识图谱的典型流程是?**
|
||||
A) 抽取组件三元组(组件-漏洞-CVE)→ 存入图数据库 → 关联风险传播路径
|
||||
B) 写入 MySQL
|
||||
C) 纯 NLP 模型生成
|
||||
|
||||
Reference in New Issue
Block a user