POD重启问题排查

当您的CPU使用率突然飙升到100%，同时G1 old gen和G1 survivor space也急剧上升，并导致POD重启时，这通常表明您的Java应用程序存在严重的性能问题或内存管理问题。以下是一个详细的排查思路，帮助您定位并解决问题：

1. 紧急处理与初步观察

查看Kubernetes事件日志: 使用 kubectl describe pod <pod-name> 或 kubectl get events 查看POD重启的原因。常见的如 OOMKilled (内存溢出被Killed)、CrashLoopBackOff 等。
监控指标回顾: 检查问题发生前后的CPU、内存、网络I/O等历史监控数据，确定飙升的具体时间点和持续时长。
应用日志: 立即查看应用日志，寻找在CPU和GC飙升时间点前后是否有异常错误、大量请求、慢查询、死循环迹象或特定业务逻辑的执行。

2. 定位CPU飙升原因

CPU飙升通常是由于某个线程或多个线程在执行密集计算、无限循环、频繁I/O操作或GC活动过于频繁。

获取POD内Java进程PID:
bash 复制代码
```
kubectl exec -it <pod-name> -- ps -ef | grep java
```
记下Java进程的PID。
获取CPU占用最高的线程ID:
bash 复制代码
```
kubectl exec -it <pod-name> -- top -H -p <java-pid>
```
观察 top 命令输出，找到CPU占用最高的线程（TID 列），记下其十六进制表示（将十进制TID转换为十六进制）。
生成线程Dump:
bash 复制代码
```
kubectl exec -it <pod-name> -- jstack -l <java-pid> > thread_dump.txt
```
将 thread_dump.txt 文件下载到本地。
分析线程Dump:
- 在 thread_dump.txt 中搜索之前获取到的高CPU占用线程的十六进制ID。
- 查看该线程的堆栈信息，确定它正在执行什么代码。这通常能直接指向问题代码（如无限循环、复杂计算、频繁的正则表达式匹配等）。
- 检查是否有大量线程处于 RUNNABLE 状态，并且都在执行类似的操作。
- 检查是否有死锁（deadlock）或长时间等待（waiting on monitor）的线程。
使用Java Flight Recorder (JFR) 或 async-profiler (如果环境允许):
- JFR (JDK 8u40+): 可以在不影响性能的情况下收集丰富的运行时数据，包括CPU使用、GC活动、锁争用、I/O等。
  bash 复制代码
```
# 启动JFR录制1分钟
kubectl exec -it <pod-name> -- jcmd <java-pid> JFR.start duration=1m filename=/tmp/my_recording.jfr
# 停止并下载
kubectl cp <pod-name>:/tmp/my_recording.jfr ./my_recording.jfr
```
  使用Java Mission Control (JMC) 工具分析 .jfr 文件。
- async-profiler: 一个轻量级的Java性能分析工具，可以提供非常详细的CPU和内存火焰图。
  bash 复制代码
```
# 部署async-profiler到POD内，并启动CPU分析
# 具体部署和使用方式请参考async-profiler官方文档
```

3. 定位G1 GC飙升原因

G1 old gen和survivor space飙升通常与内存泄漏、对象分配速率过高、GC配置不当或大对象（Humongous Objects）有关。

开启GC日志:

在JVM启动参数中添加以下配置，以便收集详细的GC日志：
复制代码
```
-Xlog:gc*:file=/var/log/gc.log:time,level,tags:filecount=10,filesize=100M
```
重启POD后，当问题再次发生时，下载 gc.log 文件。
分析GC日志:

使用GCViewer、GCEasy或gclogviewer等工具分析GC日志。关注以下指标：
- GC频率和持续时间: 是否有频繁的Full GC或Young GC暂停时间过长。
- Young GC和Old GC的比例: 如果Old GC（尤其是Concurrent Mark或Remark阶段）频繁或耗时，可能表明老年代空间不足或晋升速率过快。
- 晋升失败 (Promotion Failure): 大量对象从Young Gen晋升到Old Gen时失败，导致Full GC。
- 并发标记失败 (Concurrent Marking Failure): G1在并发标记阶段无法完成，导致STW (Stop-The-World) 的Full GC。
- Humongous Objects: G1会直接将大于一半Region大小的对象分配到老年代。如果大量大对象被创建，会加速老年代的填充。
- 堆使用趋势: 观察GC前后堆内存的使用情况，是否有持续增长的趋势（内存泄漏）。

生成堆Dump (Heap Dump):

当内存使用率高但尚未OOM时，生成堆Dump：

bash 复制代码

kubectl exec -it <pod-name> -- jmap -dump:format=b,file=/tmp/heapdump.hprof <java-pid>
# 或者使用 jcmd (推荐，对应用影响小)
kubectl exec -it <pod-name> -- jcmd <java-pid> GC.heap_dump /tmp/heapdump.hprof

将 heapdump.hprof 文件下载到本地。

分析堆Dump:

使用Eclipse Memory Analyzer Tool (MAT) 或 VisualVM 分析堆Dump文件。
- 内存泄漏检测: 查找"Dominator Tree"或"Leak Suspects"报告，识别占用内存最大的对象及其引用链。
- 对象数量和大小: 检查哪些类的对象数量最多或占用内存最大。
- 高分配速率: 结合GC日志，如果Young GC频繁且Survivor Space快速满，可能是有大量短生命周期对象被创建。

4. Kubernetes环境检查

资源限制 (Resource Limits): 检查POD的CPU和内存限制 (resources.limits) 是否合理。如果CPU限制过低，即使应用有空闲资源，也可能被K8s限流，导致处理请求变慢，进而堆积并触发GC问题。
Liveness/Readiness Probes: 检查探针配置是否过于激进或不合理。如果探针在应用短暂的GC暂停期间失败，可能导致POD被误判为不健康并重启。
节点资源: 检查POD所在节点的CPU、内存、磁盘I/O等资源是否充足，是否有其他POD抢占资源。
网络延迟: 如果应用依赖外部服务（数据库、缓存、API），检查网络延迟是否增加，导致请求处理时间变长，进而堆积。

5. 潜在原因与解决方案

内存泄漏:
- 原因: 对象被无意中长期持有，无法被GC回收。常见于静态集合、缓存未清理、ThreadLocal使用不当、监听器未移除等。
- 解决方案: 根据堆Dump分析结果，修改代码，解除不必要的引用。
高对象分配速率:
- 原因: 应用程序在短时间内创建了大量临时对象，导致Young GC频繁。
- 解决方案: 优化代码，减少不必要的对象创建，使用对象池，复用对象，使用基本数据类型而非包装类，避免在循环中创建大对象。
低效算法或无限循环:
- 原因: 某些业务逻辑使用了时间复杂度高的算法，或者存在逻辑错误导致无限循环。
- 解决方案: 根据线程Dump和Profiler结果，优化算法，修复逻辑错误。
GC配置不当:
- 原因: 默认的G1 GC参数不适合当前应用的负载特性。
- 解决方案:
  - 调整堆大小: -Xms 和 -Xmx 设置为相同值，避免运行时调整堆大小的开销。
  - 调整GC暂停时间目标: -XX:MaxGCPauseMillis=<ms> (例如200ms)。
  - 调整G1触发GC的阈值: -XX:InitiatingHeapOccupancyPercent=<percent> (例如35-45%)，降低该值可以更早触发并发标记，减少Full GC的可能性。
  - 调整G1 Young Gen和Old Gen比例: -XX:G1NewSizePercent 和 -XX:G1OldSizePercent。
  - 避免大对象频繁创建: 如果有很多Humongous对象，考虑优化数据结构或调整G1 Region大小（-XX:G1HeapRegionSize）。
突发流量或负载过高:
- 原因: 短时间内涌入大量请求，超出应用处理能力。
- 解决方案: 增加POD副本数（水平扩容），优化限流策略，提高应用处理效率。
外部依赖问题:
- 原因: 数据库、缓存、消息队列等外部服务响应缓慢或不可用，导致应用线程阻塞，请求堆积，最终引发资源耗尽。
- 解决方案: 检查外部服务的健康状况和性能，优化外部调用逻辑（如增加超时、熔断、降级机制）。

总结

这是一个系统性的排查过程，需要您从多个维度收集数据并进行分析。通常，线程Dump 能快速定位CPU飙升的代码，而 GC日志 和 堆Dump 则是解决G1 GC和内存问题的关键。务必在问题发生时尽快收集这些数据，以便进行离线分析。