Ai拆代码的曹操 - Java性能调优·线上问题排查

线程池没满，JVM 先 OOM 了——Executors 的并发陷阱

线程池没满，JVM 先 OOM 了——Executors 的并发陷阱场景：订单处理服务使用 Executors.newFixedThreadPool(10) 处理消息队列，上线一年某天突然 OOM。线程池没满、拒绝策略没触发——但堆里躺了 870 万条待处理任务。路径：现象（OOM 现场）→ 还

线程堆栈吃光 16GB 容器——一个 NMT 查不到的坑场景：16GB 容器 RSS 涨到 15.7GB、堆只用了 2.3GB，进程被 OOM killer 反复杀掉。不是堆外内存，是线程栈把整台机器撑爆了。路径：dmesg → jstat → /proc/status 查线程数 → NMT 盲

RSS 2.8GB 堆才 1.2GB——native memory 去哪了场景：Java 服务 RSS 持续涨到 2.8GB，jmap 一看堆才 1.2GB。不是 heap 不够，是 native memory 在漏。路径：pmap → /proc/smaps NMT Baseline → NM

双栈 ClusterIP 配好了，IPv6 就是不通——少加载了一个内核模块场景：集群升级双栈后，Service 的 IPv6 ClusterIP 永远连接超时、IPv4 正常——不是配置错了，是 kube-proxy 的 ip6tables 规则压根没写进去路径：坐标（双栈 Service 创

双栈 Service 配置完：IPv6 秒通、IPv4 每次等 5 秒——ipFamilies 的主从陷阱场景：Service 配置 ipFamilyPolicy: PreferDualStack 后，IPv6 客户端秒通、IPv4 客户端每次等 5 秒才连上——不是 CNI 不支持双栈，是 ip

换了 Cilium 以后，iptables 查不到了——跨 Namespace 超时的 eBPF 排障实录场景：集群从 Flannel 迁移 Cilium 后，跨 Namespace gRPC 调用间歇超时——iptables 查不到任何规则、Pod 内 tcpdump 有 SYN 无 SYN-A

一个 Pod 吃掉整节点带宽？K8s 限速 annotation 无效——TC/CNI 流量整形真相场景：CI/CD Runner Pod 与生产服务混部，构建任务下载依赖占满节点出口带宽路径：Pod 延迟确认 → 逐层追带宽（Pod→Node→CNI→tc）→ 排查命令 → annotatio

查了 3 天 DNS 间歇超时，排除了网络、CNI、kube-proxy——最后发现是 CoreDNS 自动扩缩容的参数设反了场景：微服务集群 ~120 个 Service，高峰期部分 Pod 报 Temporary failure in name resolution，API 响应从 <50ms

Gateway API 上线第 1 天就 503：Ingress 与新路由的 3 个隐性冲突场景：集群已有 Ingress 规则在跑，接入 Gateway API 后部分路由 503 路径：GatewayClass → Gateway → HTTPRoute → 控制器兼容性版本：K8s v1.

灰度 20% 流量全挂了——Istio DestRule 一个 label 拼错引发的 503 血案上篇讲了 Istio sidecar 启动慢是控制面配置没到，这篇我们来看另一个更沉默的陷阱：sidecar 启动好了、控制面也通了，但流量就是走不对。场景：order-service 做灰度发布