十万个 why 选题 — 2026.06.18
大约 35 分钟
十万个 why 选题 — 2026.06.18
基于知乎 2026 年 6 月热门技术话题生成，结合 AI Agent / MCP / RAG / Java 21 / Redis / 微服务等当前高热方向。
一、AI Agent / 大模型方向（知乎当前最热赛道）
1. 十万个why：MCP 都已经是 Agent 调工具的标准协议了，为什么生产环境还是老老实实用 Function Calling？
- 热度来源：MCP 协议 2026 年上半年在知乎引发大量讨论，被称为 Agent 工具调用的"USB 接口"，但实际落地远不如预期
- 反差点：标准协议 vs 生产不敢用
- 切入角度：MCP 的 Server 启动开销、鉴权缺失、调试黑盒、与现有 OpenAI Function Calling 生态的兼容成本
2. 十万个why：给 Agent 接了十几个 MCP 工具，为什么工具越多它反而越不会选了？
- 热度来源：知乎多篇热文讨论"多工具 Agent 选择困难症"，工具数量与 Agent 决策准确率的负相关现象
- 反差点：工具越多能力越强 vs 工具越多决策越差
- 切入角度：LLM 的 tool description 注意力稀释、工具描述歧义导致误选、工具数量超过 10 个后准确率断崖式下降的实验数据
3. 十万个why：大模型上下文窗口已经支持百万 Token 了，为什么企业做知识问答还是离不开 RAG？
- 热度来源：知乎热文"RAG 已死？2026 年做 Agentic 和上下文工程？"引发激烈争论
- 反差点：百万上下文 vs RAG 没死反而更重要
- 切入角度：长上下文的"迷失在中间"问题、Token 成本线性爆炸、实时性需求、企业数据量远超单次上下文容量
4. 十万个why：AI 编程助手生成的代码能跑通所有单测，为什么一上生产就翻车？
- 热度来源：2026 年 AI 编程工具（Claude Code / Cursor / Copilot）全面普及，知乎大量讨论"AI 写的代码能不能直接上线"
- 反差点：单测全绿 vs 生产翻车
- 切入角度：AI 倾向于生成"能通过测试"而非"正确"的代码、Mock 掩盖了真实依赖的行为差异、边界条件和并发场景的覆盖盲区、AI 无法感知线上环境的隐式约束
二、Java 后端 / Spring 方向（知乎面试+实战持续高热）
5. 十万个why：Java 21 虚拟线程明明号称百万并发零开销，为什么接入 Spring Boot 后数据库连接池直接被打爆？
- 热度来源：Java 21 虚拟线程是 2026 年 Java 生态最热特性，知乎秋招面试高频题
- 反差点：百万并发 vs 连接池被打爆
- 切入角度：虚拟线程消除了线程数瓶颈，但 JDBC 连接池（HikariCP 默认 10 个连接）没跟着扩、pin 住平台线程的 synchronized 问题、虚拟线程让并发量瞬间暴涨反而暴露了下游资源的真实瓶颈
6. 十万个why：GraalVM Native Image 能把 Spring Boot 启动压到 0.1 秒，为什么大厂微服务还是跑在传统 JVM 上？
- 热度来源：GraalVM + Spring Boot 3 原生镜像是知乎云原生方向的热门话题
- 反差点：启动快 100 倍 vs 大厂不用
- 切入角度：AOT 编译不支持动态代理和反射的部分场景（大量 Spring 生态依赖反射）、运行时峰值吞吐量不如 JIT C2 编译器、构建时间长达 10 分钟+、调试排查困难、GC 选项有限
7. 十万个why：用 @Async 把方法改成异步执行明明是为了提速，为什么改完后主接口响应反而更慢了？
- 热度来源：Spring 异步编程是知乎 Java 面试和实战讨论的经典高频话题
- 反差点：异步提速 vs 反而更慢
- 切入角度：Spring 默认的 SimpleAsyncTaskExecutor 每次 new 一个线程、没配线程池导致线程创建开销比业务逻辑还大、@Async 和 @Transactional 同时用时事务失效、异步方法的异常被吞掉导致静默失败
三、Redis / 数据库方向（知乎长期热门）
8. 十万个why：Redis Cluster 扩容就是加几个节点的事，为什么扩完之后 P99 延迟反而飙了 10 倍？
- 热度来源：Redis 高可用架构是知乎后端方向的常青话题，2026 年结合云原生弹性伸缩讨论更热
- 反差点：加节点扩容 vs 延迟暴涨
- 切入角度：Slot 迁移期间的 ASK/MOVED 重定向开销、大 Key 迁移阻塞主线程、客户端路由表刷新不及时导致多次重定向、扩容期间 Gossip 协议的收敛延迟
9. 十万个why：在 Redis 前面加了一层 Caffeine 本地缓存，为什么热点接口的响应时间反而更长了？
- 热度来源：多级缓存架构是 2026 年知乎高并发方向的热议话题
- 反差点：加缓存层 vs 更慢
- 切入角度：本地缓存 TTL 和 Redis TTL 不一致导致频繁回源、Caffeine 的 refreshAfterWrite 触发同步加载阻塞请求线程、多实例之间本地缓存不一致引发业务逻辑混乱和额外校验开销
10. 十万个why：用 Canal 监听 Binlog 同步数据到 ES，一条消息都没丢，为什么搜出来的结果还是和数据库对不上？
- 热度来源：Canal + ES 数据同步是知乎搜索架构方向的高频讨论
- 反差点：消息没丢 vs 数据对不上
- 切入角度：ES 的 near-realtime 机制（默认 1 秒 refresh）、Canal 解析的是行级变更但业务用的是事务级一致性、同一条记录短时间内多次更新导致乱序消费、DDL 变更后 Canal 解析字段错位
备选题目
- 十万个why：Agentic RAG 明明比普通 RAG 更智能，为什么实际上线后 Token 成本翻了 5 倍效果却没好多少？
- 十万个why：Rust 性能吊打 Java 已经是共识了，为什么 2026 年后端招聘还是 Java 占绝对多数？
- 十万个why：K8s Pod 设了 CPU Limit，为什么容器内的 JVM 还是按物理机的核数算并行 GC 线程？
- 十万个why：Spring Cloud Gateway 的限流配置明明生效了，为什么突发流量还是把下游服务打挂了？
- 十万个why：ES 分片数设成了和节点数一样，为什么写入吞吐量反而不如只有一个分片的时候？
十万个 why 选题（第二批）— 2026.06.18
基于知乎 2026 年 6 月热门话题生成，覆盖 K8s 云原生 / 消息队列 / 分布式事务 / Go 语言 / 分库分表 / 安全认证等方向。
四、K8s / 云原生 / Serverless 方向（知乎云原生持续高热）
11. 十万个why：K8s Pod 明明设了 CPU Limit 为 2 核，为什么容器里的 JVM 还是启了跟宿主机一样多的 GC 线程？
- 热度来源：K8s + JVM 调优是 2026 年知乎云原生方向最经典的生产坑之一，Docker 镜像加速帖子每月更新热度不减
- 反差点：设了 CPU 限制 vs JVM 完全不理
- 切入角度：JDK 8u131 之前完全不感知 cgroup、JDK 11+ 虽然支持但 UseContainerSupport 默认行为和 cgroup v1/v2 的差异、ParallelGCThreads 按物理核算导致 GC 线程数远超分配核数引发频繁上下文切换
12. 十万个why：K8s HPA 自动扩容明明配了 CPU 阈值 70%，为什么流量高峰来了 Pod 还是扩不出来？
- 热度来源：知乎 K8s 弹性伸缩是 2026 年 SRE 和后端方向的高频讨论
- 反差点：配了自动扩容 vs 扩不出来
- 切入角度：metrics-server 采集延迟（默认 15 秒）+ HPA 计算周期（默认 15 秒）= 至少 30 秒反应时间、Pod 启动到 Ready 还要几十秒、突发尖峰流量在扩容生效前已经把现有 Pod 打崩、资源配额（ResourceQuota）不够导致 Pending
13. 十万个why：Serverless 函数明明是按调用次数计费用多少付多少，为什么上了之后月账单反而比 ECS 还贵？
- 热度来源：Serverless 落地成本是知乎云原生方向的热议话题，京东等大厂实践反馈引发讨论
- 反差点：按量付费省钱 vs 反而更贵
- 切入角度：冷启动导致函数执行时间膨胀计费翻倍、高频调用场景下每次请求的固定开销（调度、初始化）累积远超常驻进程、外部依赖（API 网关、日志服务、对象存储）的关联费用被忽略
五、消息队列 / 分布式事务方向（知乎面试+架构设计热门）
14. 十万个why：RocketMQ 事务消息明明已经 commit 了，为什么消费端偶尔还是会收到一条回查请求？
- 热度来源：RocketMQ 事务消息是知乎分布式事务方向的高频讨论，Seata + RocketMQ 组合方案热度持续上升
- 反差点：已经 commit vs 还在回查
- 切入角度：half 消息写入成功但 commit/rollback 的 Op 消息因为网络抖动未送达 Broker、Broker 端的回查定时任务扫到了这条 half 消息、本地事务执行成功但返回 COMMIT_MESSAGE 前进程被 kill
15. 十万个why：Kafka 消费者组里加了一台新机器本来是为了提升消费速度，为什么加完之后整个组反而卡了好几分钟不消费？
- 热度来源：Kafka Rebalance 是知乎消息队列方向的经典高频坑，2026 年结合大规模消费场景讨论更多
- 反差点：加机器提速 vs 全组停摆
- 切入角度：新成员加入触发 Rebalance、Stop-The-World 式的 Eager Rebalance 让所有消费者先释放分区再重新分配、Rebalance 期间无法消费、分区数多时分配计算耗时长、没开 CooperativeStickyAssignor 增量再平衡
16. 十万个why：Seata AT 模式的分布式事务回滚明明成功了，为什么数据还是不一致？
- 热度来源：Seata 是知乎分布式事务方向讨论最多的框架，AT 模式的脏写问题是高频踩坑点
- 反差点：回滚成功 vs 数据不一致
- 切入角度：AT 模式基于 undo_log 回滚的前提是"回滚前数据没被其他事务改过"、如果有非 Seata 管理的本地事务直接改了同一条数据，undo_log 的 afterImage 校验失败导致回滚补偿数据覆盖了正确数据
六、分库分表 / MySQL 方向（知乎数据库长期热门）
17. 十万个why：ShardingSphere 分库分表后 SQL 都能正常跑，为什么分页查到第 10 页以后数据顺序全乱了？
- 热度来源：ShardingSphere 分库分表是知乎数据库方向的热门实战话题，版本差异踩坑讨论极多
- 反差点：SQL 正常 vs 分页乱序
- 切入角度：分库分表场景下的分页归并排序问题——每个分片各自 ORDER BY LIMIT 取 N 条，ShardingSphere 需要在内存中做全局归并排序，深度分页时每个分片要回溯取前 N*分片数 条数据再归并，结果集爆炸且排序不稳定
18. 十万个why：MySQL 主从复制延迟只有 200 毫秒，为什么业务写完立刻读还是频繁读到旧数据？
- 热度来源：MySQL 读写分离是知乎数据库架构方向的经典话题，ShardingSphere 读写分离实践持续活跃
- 反差点：延迟只有 200ms vs 还是读到旧数据
- 切入角度：200ms 是 Seconds_Behind_Master 的平均值而非实时值、大事务回放导致瞬时延迟飙到几秒、业务"写完立刻读"的间隔往往不到 50ms、ShardingSphere 默认读走从库没配强制路由主库的 Hint
七、Go / Rust / 跨语言方向（知乎 2026 编程语言最热争论）
19. 十万个why：Go 的 Goroutine 号称比线程轻量 1000 倍，为什么起了 10 万个 Goroutine 之后进程直接 OOM 了？
- 热度来源：Go 并发模型是知乎 2026 年编程语言讨论的核心话题，Go vs Rust 争论持续白热化
- 反差点：轻量协程 vs OOM
- 切入角度：每个 Goroutine 初始栈虽然只有几 KB 但会动态增长、10 万个 Goroutine 如果每个都持有一个 HTTP 连接或读取大 buffer，内存消耗远超协程栈本身、Goroutine 泄漏（channel 没 close、context 没 cancel）导致数量只增不减
20. 十万个why：Go 服务用 sync.Mutex 加了锁保证并发安全，为什么压测一上量 P99 延迟就从 5ms 飙到了 500ms？
- 热度来源：Go 并发性能调优是知乎 Go 方向的热门实战话题，Grab 用 Rust 重写高 QPS 服务的案例引发广泛讨论
- 反差点：加锁保证安全 vs 延迟飙 100 倍
- 切入角度：sync.Mutex 在高争用场景下的锁饥饿问题、Go 1.8 之前的非公平锁让某些 Goroutine 长期拿不到锁、即使 1.9+ 引入饥饿模式切换也有阈值（1ms），在临界区稍大的场景下仍然扛不住、应该用分片锁或 sync.Map 降低争用粒度
八、安全认证方向（知乎安全+架构交叉热门）
21. 十万个why：OAuth 2.0 授权流程明明已经拿到了 Access Token，为什么直接拿它做用户登录反而是个安全漏洞？
- 热度来源：OAuth/OIDC 认证是知乎安全和架构方向的持续热点，零信任架构讨论升温
- 反差点：拿到 Token vs 做登录是漏洞
- 切入角度：OAuth 2.0 是授权协议不是认证协议、Access Token 只能证明"有权访问资源"不能证明"是谁"、攻击者用恶意应用拿到的 Token 可以冒充用户登录其他应用（Token 替换攻击）、必须用 OIDC 的 ID Token + nonce 才能安全认证身份
22. 十万个why：微服务之间的调用已经在内网了，为什么安全团队还要求每个请求都带上 JWT 做身份校验？
- 热度来源：零信任架构是 2026 年知乎安全方向的上升话题，分布式系统 JWT 实践讨论热度高
- 反差点：内网调用 vs 还要带 JWT
- 切入角度：零信任架构的核心——"内网不等于可信网络"、一个被攻陷的微服务可以伪造请求横向移动访问所有内部服务、JWT 非对称签名可以防篡改且不需要每次调认证中心、服务网格 mTLS 只能验证"是哪个服务"但不能验证"是哪个用户在操作"
第二批备选题目
- 十万个why：Docker 容器里的时区明明设成了 Asia/Shanghai，为什么 Java 应用的日志时间还是 UTC？
- 十万个why：Prometheus 监控的 CPU 使用率明明没超过 50%，为什么应用还是在疯狂 Full GC？
- 十万个why：gRPC 的传输效率明明比 HTTP REST 高好几倍，为什么大厂开放 API 还是清一色用 REST？
- 十万个why：Spring Cloud Gateway 的限流配置明明生效了，为什么突发流量还是把下游服务打挂了？
- 十万个why：Redisson 分布式锁有 watchdog 自动续期，为什么锁还是在业务没执行完时被释放了？
十万个 why 选题（第三批·主题发散）— 2026.06.18
从已发布的 36 篇 + 未发布的 25 篇文章中提取 7 条主题脉络，每条脉络向外发散 2 个新选题。
脉络一：Kafka 系（已有：Partition 性能 / 暂停消费 / Rebalance / offset 重复消费）
23. 十万个why：Kafka 消息明明都设了相同的 Key 保证分区有序，为什么消费端拿到的顺序还是乱的？
- 发散自：「Kafka offset 提交成功还是重复消费」「消费者线程还在打日志 Kafka 判它死亡」
- 反差点：同 Key 同分区应该有序 vs 消费端乱序
- 切入角度：生产者端的 max.in.flight.requests.per.connection > 1 时重试导致乱序、消费者端多线程消费拉到的一批消息并行处理打乱了顺序、分区扩容后 Key 的 hash 结果变了同一个 Key 可能落到不同分区
24. 十万个why：Kafka 生产者 acks 配了 all 而且三副本都确认了，为什么 Broker 宕机后消息还是丢了？
- 发散自：「Kafka Partition 越多写入性能越差」「暂停消费为什么别用 Thread.sleep」
- 反差点：acks=all 三副本确认 vs 宕机消息丢了
- 切入角度：min.insync.replicas 没设成 2，只要 leader 一个副本 ack 就算 all、unclean.leader.election.enable=true 允许落后的副本当 leader 导致数据回滚、OS 层面 Page Cache 没刷盘 Broker 整机宕机数据没真正持久化
脉络二：MySQL / 索引系（已有：死锁 / OR 全表扫描 / 深分页 / explain 走索引但慢 / 索引多影响性能）
25. 十万个why：联合索引的字段明明覆盖了查询条件和排序字段，为什么 explain 还是出现了 Using filesort？
- 发散自：「两个字段加了单列索引 OR 全表扫描」「explain type=ref 走了索引还是查 8 秒」
- 反差点：联合索引全覆盖 vs 还是文件排序
- 切入角度：联合索引的字段顺序和 ORDER BY 的顺序不一致、WHERE 里用了范围查询（> < BETWEEN）导致后面的字段无法利用索引排序、ASC/DESC 混用在 MySQL 8.0 之前不支持降序索引
26. 十万个why：MySQL 的 COUNT(*) 不就是数个总数吗，为什么一张两千万的表要跑四五秒？
- 发散自：「索引多了会影响性能」「MySQL 分页前 10 条飞快翻到 100 万条卡死」
- 反差点：数总数这么简单的事 vs 跑好几秒
- 切入角度：InnoDB 的 MVCC 机制决定了不同事务看到的行数可能不同所以无法缓存总行数、COUNT(*) 要走一遍聚簇索引或二级索引逐行判断可见性、MyISAM 有行数缓存但 InnoDB 没有、解决方案：预估用 SHOW TABLE STATUS 或维护计数器表
脉络三：Redis 系（已有：缓存击穿方案 / key 过期内存撑爆 / 批量删 key / RedLock 废弃 / 延迟双删 / Redis 6.0 多线程）
27. 十万个why：Redis Lua 脚本明明是原子执行的，为什么在 Cluster 集群模式下还是出了数据不一致？
- 发散自：「RedLock 废弃」「延迟双删高并发不靠谱」
- 反差点：Lua 原子执行 vs 集群下不一致
- 切入角度：Redis Cluster 下 Lua 脚本操作的所有 Key 必须在同一个 Slot，否则直接报 CROSSSLOT 错误、开发者用 Hash Tag 强制同 Slot 但导致数据倾斜某个节点压力过大、Lua 脚本执行时间过长阻塞单线程导致其他命令超时被客户端当失败处理
28. 十万个why：Redis 的 BigKey 删除不就是一条 DEL 命令吗，为什么能让整个实例卡顿好几秒？
- 发散自：「批量删了两百万个 key used_memory 不动」「key 过期内存撑爆」
- 反差点：一条 DEL 命令 vs 整个实例卡顿
- 切入角度：DEL 是同步删除，一个包含百万元素的 Hash/Set/ZSet 在主线程逐个释放内存、Redis 单线程模型下这几秒内所有其他命令都在排队等待、UNLINK 命令可以异步删除但很多老项目还在用 DEL、过期 key 的惰性删除也可能触发同步大 Key 释放
脉络四：Spring 系（已有：三级缓存 / @Transactional 同类方法失灵 / synchronized + 事务 / 循环依赖）
29. 十万个why：Spring 的 @Scheduled 定时任务明明设了 fixedRate = 5000，为什么实际间隔有时候几十秒甚至直接不跑了？
- 发散自：「@Transactional 同类方法失灵」「方法加了 synchronized 套上事务又线程不安全了」
- 反差点：配了 5 秒执行 vs 几十秒甚至不执行
- 切入角度：Spring 的 @Scheduled 默认是单线程调度器（ScheduledTaskRegistrar），一个任务执行慢了后面全部排队等、fixedRate 的下一次执行要等上一次跑完不是严格按时间触发的、没配 @EnableScheduling 时注解直接无效但不报错
30. 十万个why：方法参数上明明加了 @Validated 做校验，为什么嵌套对象里的非法字段直接放行了？
- 发散自：「Service 方法 A 调同类方法 B @Transactional 失灵」
- 反差点：加了校验注解 vs 嵌套字段没校验
- 切入角度：@Validated 只校验当前对象的直接字段、嵌套对象必须在字段上额外加 @Valid 注解才能触发级联校验、List<@Valid Item> 这种泛型参数的校验需要在类上加 @Validated 而不是方法参数上、校验不过的异常类型还不一样 MethodArgumentNotValidException vs ConstraintViolationException
脉络五：微服务 / 网关 / 注册中心系（已有：Nacos 下线 / Feign 超时 / API 网关 / 二次鉴权 / Nginx + Gateway / 超时链路放大 / 单体拆微服务变慢）
31. 十万个why：Sentinel 限流规则明明配了 QPS 阈值 100，为什么监控显示 QPS 快到 200 了才开始拒绝请求？
- 发散自：「Feign 超时时间设了 3 秒实际等了 10 秒」「公司拆了微服务系统反而越来越慢」
- 反差点：限流阈值 100 vs 快 200 才触发
- 切入角度：Sentinel 默认用的滑动窗口统计 QPS，窗口采样精度（SampleCount）只有 2 时统计不精确、集群模式下每个实例各自限流阈值是总阈值/实例数但实例间流量不均匀、Sentinel 的 warm up 预热模式在冷启动期间阈值会从低到高慢慢爬升
32. 十万个why：微服务灰度发布明明只放了 5% 的流量给新版本，为什么监控显示新版本实际承接了将近 30%？
- 发散自：「Nacos 点了下线流量还是打到停机的机器上」「两个微服务都设了 3 秒超时请求用了 30 秒」
- 反差点：5% 灰度 vs 实际 30%
- 切入角度：网关层 5% 的灰度只控制了入口流量，但新版本服务在内部调用链中被其他服务当成正常实例路由、新版本注册到 Nacos 后 Ribbon/LoadBalancer 的实例列表里新旧版本权重一样、一条请求链路经过 6 个服务每层都可能随机打到新版本，叠加后远超 5%
脉络六：AI / 大模型系（已有：向量库胡说八道 / Agent 踢皮球 / Agent 落地难 / NER 提取 JSON / 大模型记忆 / RAG vs 微调 / RAG 准确率）
33. 十万个why：大模型的 temperature 设成 0 了，为什么同一个问题问两次答案还是不一样？
- 发散自：「大模型不设计成带有记忆的」「大模型做意图识别别再用 Prompt 提取 JSON」
- 反差点：temperature=0 应该确定性输出 vs 结果不一样
- 切入角度：GPU 浮点运算的非确定性（CUDA 的并行归约顺序不固定）、batch size 不同时计算路径不同结果有微小差异、部分推理框架的 KV Cache 策略导致 prefill 阶段计算精度波动、真正要确定性输出需要设 seed 参数且推理框架支持确定性模式
34. 十万个why：RAG 召回的文档相关性评分都在 0.9 以上了，为什么大模型回答时完全忽略了这些内容自己编？
- 发散自：「向量库明明搜到匹配结果大模型还是胡说八道」「RAG 准确率提升方案」
- 反差点：相关性 0.9 vs 大模型自己编
- 切入角度：召回文档放在 System Prompt 的位置被模型当成"背景知识"优先级低于用户问题里的隐含指令、文档内容太长超过了模型的有效注意力窗口被"稀释"、文档和用户问题用的术语不一致模型没建立起关联、Prompt 没有明确指示"必须基于以下文档回答"的强约束
脉络七：Java 基础系（已有：ArrayList foreach / HashMap 0.75 / Integer 128 / ThreadLocal / finally / ConcurrentHashMap / try-catch / Docker OOM）
35. 十万个why：CompletableFuture 的异步任务明明抛了异常，为什么主线程一点感知都没有直接拿到了 null？
- 发散自：「finally 块吞异常」「ThreadLocal 弱引用内存泄漏」「ConcurrentHashMap 并发数据对不上」
- 反差点：异步任务异常了 vs 主线程无感
- 切入角度：thenApply/thenAccept 链路中某一环抛异常后面的链路直接跳过、没用 exceptionally/handle 捕获异常时 get() 才会抛 ExecutionException 但如果用了 getNow(null) 或 join() 的超时版本就直接拿到 null、用 ForkJoinPool.commonPool() 时异常日志默认不打印、最隐蔽的坑：supplyAsync 里的异常被 thenCompose 吞掉
36. 十万个why：Logback 用了 AsyncAppender 异步写日志明明是为了不阻塞业务线程，为什么日志量一大接口反而更卡了？
- 发散自：「try-catch 影响性能」「Java 应用在物理机跑好好的丢进 Docker 就 OOM」
- 反差点：异步写日志不阻塞 vs 接口更卡
- 切入角度：AsyncAppender 的内部队列（默认 256）满了之后默认策略是阻塞等待不是丢弃、高并发日志打印速度远超磁盘写入速度队列瞬间打满、discardingThreshold 默认 20% 只丢 DEBUG/TRACE 不丢 INFO/ERROR、队列满时所有业务线程都被 BlockingQueue.put() 卡住等于变成同步写
第三批备选题目
- 十万个why：用 Spring Event 发了一个事件，为什么 @EventListener 的监听方法有时候执行了有时候没执行？
- 十万个why：Nacos 配置中心改了配置明明推送成功了，为什么有几台机器就是不生效？
- 十万个why：MyBatis 的一级缓存明明是为了提升性能，为什么在微服务场景下反而成了 Bug 来源？
- 十万个why：用了 @Retryable 做接口重试，为什么某些异常重试了而某些异常直接穿透了？
- 十万个why：分布式定时任务用了 XXL-JOB 的分片广播模式，为什么有些分片任务永远不会被执行？
十万个 why 选题（第四批）— 2026.06.21
覆盖线程池 / ES / WebSocket / 连接池 / 分布式 ID / JVM / 网络 / 响应式编程 / Spring Security / 链路追踪等方向。
九、线程池 / 并发编程方向（知乎 Java 面试永恒热点）
37. 十万个why：线程池明明配了 maximumPoolSize = 200，为什么任务堆积到 OOM 了也只有核心线程在干活？
- 热度来源：线程池配置是知乎 Java 面试方向的"必考题"，但大量开发者对 corePoolSize / 队列 / maximumPoolSize 的执行优先级理解有误
- 反差点：最大线程数 200 vs 只有核心线程在跑
- 切入角度：线程池的任务调度顺序是"核心线程 → 队列 → 最大线程"，不是"核心线程 → 最大线程 → 队列"、用了无界队列（LinkedBlockingQueue 默认 Integer.MAX_VALUE）任务永远在排队永远到不了创建非核心线程的阶段、队列满了才会创建到 maximumPoolSize 的线程
38. 十万个why：用了 Executors.newFixedThreadPool 固定线程池处理请求，为什么跑着跑着堆内存就爆了？
- 热度来源：阿里巴巴 Java 开发规约"禁止使用 Executors 创建线程池"是知乎讨论最多的规约之一
- 反差点：固定线程池应该稳定 vs 内存爆了
- 切入角度：newFixedThreadPool 用的是 LinkedBlockingQueue（无界队列），请求速度大于处理速度时任务无限堆积、每个任务对象 + 请求数据在队列里一直不释放、堆内存被队列里几百万个待执行的 Runnable 对象撑爆
十、Elasticsearch 方向（知乎搜索架构高频话题）
39. 十万个why：ES 写入数据后 Refresh 间隔设成了 1 秒，为什么刚写入的数据等了好几秒还是搜不到？
- 热度来源：ES 近实时搜索机制是知乎搜索方向的经典考点
- 反差点：1 秒 Refresh vs 好几秒搜不到
- 切入角度：Refresh 只是让数据对搜索可见但不是实时的——translog 写入和 segment 刷新有时间差、bulk 写入量大时 Refresh 被合并或推迟、客户端用了连接池连到不同节点而副本同步有延迟、最坑的：Kibana 查询默认带时间范围过滤器可能把刚写入的数据排除在外
40. 十万个why：ES 集群加了一个新节点本来是为了分担压力，为什么加完后整个集群 CPU 直接拉满了？
- 热度来源：ES 集群运维是知乎后端架构方向的热门实战话题
- 反差点：加节点分担压力 vs CPU 拉满
- 切入角度：新节点加入后触发分片重平衡（Shard Rebalancing），大量分片迁移消耗磁盘 IO 和网络带宽、迁移期间还要对迁移中的分片提供查询服务、没有提前设 cluster.routing.allocation.cluster_concurrent_rebalance 限制并发迁移数量、主分片和副本分片同时搬导致某些索引短时间内无可用副本
十一、WebSocket / 长连接方向（知乎实时通信热门话题）
41. 十万个why：WebSocket 连接明明已经建立成功了，为什么客户端隔一两分钟就断开重连？
- 热度来源：IM 和实时推送是知乎后端方向的经典架构话题，2026 年结合 AI 流式输出讨论更多
- 反差点：连接已建立 vs 频繁断开
- 切入角度：Nginx 反向代理默认的 proxy_read_timeout 是 60 秒，WebSocket 空闲超过这个时间就被 Nginx 断掉、云厂商 SLB/ALB 的空闲超时通常是 60-90 秒、没做心跳保活或心跳间隔大于代理的超时时间、客户端网络切换（Wi-Fi 转 4G）TCP 连接已经断了但服务端不知道
42. 十万个why：SSE（Server-Sent Events）明明比 WebSocket 简单轻量，为什么大模型流式输出还是有人用 WebSocket？
- 热度来源：大模型流式输出是 2026 年最热的实时通信场景，SSE vs WebSocket 争论热度很高
- 反差点：SSE 更简单 vs 还是用 WebSocket
- 切入角度：SSE 是单向通信（服务端→客户端），用户如果要中途打断生成需要额外发 HTTP 请求、SSE 基于 HTTP/1.1 时浏览器有 6 个并发连接限制开多个对话窗口就打满了、某些企业代理/网关不支持 chunked transfer 会缓冲完整响应再转发导致流式效果消失、HTTP/2 下 SSE 的连接复用能力比 HTTP/1.1 好很多但服务端适配成本高
十二、连接池 / 数据源方向（知乎性能调优经典话题）
43. 十万个why：HikariCP 连接池的 maximumPoolSize 设成 50 了，为什么高峰期还是频繁报"连接获取超时"？
- 热度来源：数据库连接池调优是知乎 Java 后端性能方向的长期热点
- 反差点：50 个连接应该够用 vs 超时
- 切入角度：连接被慢 SQL 占住不释放导致池中没有可用连接、事务方法里调了远程接口（HTTP/RPC），连接在等远程响应期间一直被占着、@Transactional 注解范围过大把非数据库操作也包进事务里、minimumIdle 设得太低冷启动时来不及创建连接
44. 十万个why：HttpClient 连接池明明设了 maxTotal = 200，为什么并发请求一上来就报"Connection pool shut down"？
- 热度来源：HTTP 客户端连接池配置是知乎微服务方向的常见踩坑话题
- 反差点：200 个连接 vs 直接报错
- 切入角度：maxTotal 是全局连接数但还有个 defaultMaxPerRoute 默认只有 2——同一个目标域名最多同时 2 个连接、连接池的连接被空闲检测回收后没有及时补充、SSL 握手超时导致连接创建失败但连接计数器已经加了、Spring 的 RestTemplate 默认不用连接池每次都 new 连接
十三、分布式 ID / 雪花算法方向（知乎分布式系统经典话题）
45. 十万个why：雪花算法生成的 ID 明明是全局唯一的，为什么数据库里还是出现了重复 ID？
- 热度来源：分布式 ID 生成是知乎分布式系统方向的经典考点，雪花算法是标准答案
- 反差点：全局唯一 vs 出现重复
- 切入角度：两个服务实例的 workerId 配成了一样的值（手动配置没管理好）、服务器时钟回拨导致在已经用过的时间段内重新生成了相同的 ID、K8s Pod 重启后 workerId 分配逻辑没去重、雪花算法的时间戳精度是毫秒级同一毫秒内序列号用完了溢出归零
46. 十万个why：前端拿到的雪花 ID 和后端生成的不一样，最后几位数字对不上，这是什么灵异事件？
- 热度来源：知乎前后端联调话题中经典的"Long 精度丢失"问题，每隔几个月就有新帖讨论
- 反差点：同一个 ID vs 前后端不一致
- 切入角度：JavaScript 的 Number 类型是 IEEE 754 双精度浮点数最大安全整数是 2^53-1（约 9007 万亿），雪花算法生成的 64 位 Long 超过这个范围后低位被截断、JSON 序列化时 Long 被当成 Number 传给前端就丢精度了、解决方案：后端把 Long 转成 String 传输或用 Jackson 的 @JsonSerialize(using = ToStringSerializer.class)
十四、JVM 调优方向（知乎 Java 面试+性能调优热点）
47. 十万个why：JVM 启动参数设了 -Xms4g -Xmx4g，为什么 top 命令看到的 RES 内存占了 6 个多 G？
- 热度来源：JVM 内存模型是知乎 Java 面试方向的"万年考点"，结合容器化部署讨论更热
- 反差点：堆只设了 4G vs 进程占了 6G+
- 切入角度：-Xmx 只管堆内存、Metaspace（类元数据）默认不限大小、线程栈（-Xss 默认 1MB × 线程数）、DirectByteBuffer 堆外内存、JIT 编译器的 CodeCache、GC 本身需要的工作内存、NIO 的 MappedByteBuffer 映射的文件页
48. 十万个why：Full GC 的日志显示每次回收后老年代使用率都降到了 10% 以下，为什么还是频繁 Full GC？
- 热度来源：GC 调优是知乎 JVM 方向的高频实战话题
- 反差点：回收效果很好 vs 频繁触发
- 切入角度：Metaspace 满了触发的 Full GC 跟老年代无关但日志里照样显示老年代信息、System.gc() 被某个三方库显式调用、CMS GC 的 concurrent mode failure 导致退化成 Serial Full GC、JVM 的自适应策略（Ergonomics）自动调小了老年代大小导致频繁触碰阈值
十五、网络 / DNS / CDN 方向（知乎运维+架构交叉话题）
49. 十万个why：域名的 DNS 解析 TTL 明明设成了 60 秒，为什么改了解析记录后有些用户等了好几个小时才生效？
- 热度来源：DNS 解析是知乎运维和网络方向的常青话题，域名迁移和故障切换场景讨论热度高
- 反差点：TTL 60 秒 vs 好几小时不生效
- 切入角度：运营商的递归 DNS 服务器不一定遵守源站设的 TTL，很多运营商自己加了缓存层并且用更长的过期时间、Java 的 InetAddress 有自己的 DNS 缓存默认永久不过期（networkaddress.cache.ttl=-1）、浏览器也有 DNS 缓存、操作系统也有 DNS 缓存——四层缓存任何一层没过期都可能访问到旧 IP
50. 十万个why：用了 CDN 加速静态资源，为什么更新了文件后用户看到的还是旧版本？
- 热度来源：CDN 缓存管理是知乎前端和运维方向的经典踩坑话题
- 反差点：用了 CDN 加速 vs 内容不更新
- 切入角度：CDN 边缘节点缓存了旧文件且没过期、手动刷新 CDN 缓存只刷了部分节点、文件名没变 CDN 认为内容没变不会回源拉新版本、最佳实践是文件名带 hash 指纹（如 app.3f2a1b.js）而不是靠 CDN 刷新
十六、响应式编程 / WebFlux 方向（知乎 Java 新技术话题）
51. 十万个why：Spring WebFlux 号称用少量线程就能扛住高并发，为什么性能压测结果跟传统 MVC 差不多？
- 热度来源：WebFlux 是知乎 Spring 方向的热议新技术，"到底比 MVC 快多少"的讨论从未停过
- 反差点：少量线程高并发 vs 跟 MVC 差不多
- 切入角度：WebFlux 的优势是 IO 密集型场景，如果压测的接口是 CPU 密集型计算那非阻塞没用、代码里用了 block() 或调了 JDBC（同步阻塞）直接把 EventLoop 线程卡死、压测工具的并发数没拉到足够高体现不出线程数的差距、MVC + 虚拟线程（Java 21）在很多场景下效果已经跟 WebFlux 差不多了
52. 十万个why：Project Reactor 的 Mono/Flux 链路里某个操作抛了异常，为什么 try-catch 根本捕获不到？
- 热度来源：响应式编程的异常处理是知乎 Java 方向的高频踩坑话题
- 反差点：try-catch 包住了 vs 捕获不到
- 切入角度：响应式链路是"声明式"的——你写的代码只是在组装一条管道，异常发生在订阅（subscribe）的时候而不是组装的时候、try-catch 只能捕获同步阶段的异常、必须用 onErrorResume / onErrorReturn / doOnError 等操作符在链路内处理、最隐蔽的坑：flatMap 里的异常会取消整个上游流
十七、Spring Security / 认证鉴权方向（知乎安全+Spring 交叉热点）
53. 十万个why：Spring Security 的过滤器链明明放行了某个接口，为什么请求打过来还是返回 403？
- 热度来源：Spring Security 配置是知乎 Spring 方向最经典的"配了不生效"话题
- 反差点：配了放行 vs 还是 403
- 切入角度：antMatchers 的路径匹配顺序有讲究——先匹配先生效，如果前面有个
/**的拦截规则就把后面的放行规则覆盖了、CORS 预检请求（OPTIONS）没放行导致实际请求被拒、Spring Security 6.x 改了 API（用 requestMatchers 代替 antMatchers）老写法直接不生效但不报错
54. 十万个why：JWT Token 明明还没过期，为什么用户刷新页面后突然被踢出登录了？
- 热度来源：JWT 认证方案是知乎安全方向的长期热议话题，Token 过期处理策略讨论活跃
- 反差点：Token 没过期 vs 被踢出
- 切入角度：前端存 Token 用的是 sessionStorage 而不是 localStorage，关了标签页就没了、服务端部署了多个实例但 JWT 的签名密钥不一致导致另一台实例验签失败、服务端升级后密钥更新了老 Token 全部失效、网关或 Spring Security 的时钟校验有偏差（exp 用的是 UTC 时间但服务器用了本地时区比较）
十八、链路追踪 / 可观测性方向（知乎 SRE 热门话题）
55. 十万个why：SkyWalking 的链路追踪明明接入了所有服务，为什么有些请求的调用链到中间就断了？
- 热度来源：分布式链路追踪是知乎微服务架构方向的热门运维话题
- 反差点：全部接入 vs 链路断了
- 切入角度：异步线程切换后 TraceContext 没传递（CompletableFuture / 线程池），SkyWalking 的 Agent 对自定义线程池的自动注入有版本限制、跨消息队列（Kafka/RocketMQ）消费端没配 SkyWalking 的消息插件导致 TraceId 丢失、服务用了 WebFlux 但没引入对应的响应式插件
56. 十万个why：Prometheus 监控的 JVM 堆内存使用量一直在 70% 上下波动，为什么 Grafana 的告警就是不触发？
- 热度来源：Prometheus + Grafana 监控告警是知乎 SRE 方向的必备技能话题
- 反差点：指标到阈值了 vs 告警不触发
- 切入角度：Grafana 的告警规则用的是 PromQL 查询区间向量的平均值而不是瞬时值，70% 上下波动取平均可能刚好低于阈值、告警规则的 for 持续时间（如 5m）要求指标持续超过阈值才触发但 GC 回收后立刻降下去了、Prometheus 的抓取间隔（15s）和 Grafana 的查询步长不一致导致数据被平滑了
第四批备选题目
- 十万个why：gRPC 的传输效率明明比 HTTP REST 高好几倍，为什么大厂开放 API 还是清一色用 REST？
- 十万个why：GraphQL 明明可以让前端按需取数据避免过度获取，为什么大部分团队试了之后又换回了 REST？
- 十万个why：用了 Spring Boot Actuator 的 /health 端点做 K8s 存活探针，为什么 Pod 老是被误杀重启？
- 十万个why：Netty 的 EventLoop 线程数设成了 CPU 核数的两倍，为什么连接数上去后吞吐量反而下降了？
- 十万个why：MongoDB 的写入速度明明很快也不用建表，为什么用它替代 MySQL 后查询变得越来越慢？