首页

# 背景

在话务量环境中，我们发现接口响应变慢。由于该环境中运行着多种业务，难以直接判断是哪个业务引发了这个问题。因此，我们需要进行深入的性能分析和问题定位。

# 问题定位过程

# 1. 使用 jstat 观察垃圾收集情况

首先，我们使用 jstat -gcutil 命令查看垃圾收集的情况。观察结果显示：

  • 老年代使用率较高
  • GC 次数和时间明显偏多

这些迹象表明系统可能正在频繁进行 Full GC。

# 2. 使用 jmap 分析堆内存

接下来，我们使用 jmap -heap <pid> 命令查看堆内存使用情况，发现内存使用量确实很高。

为了进一步分析，我们执行了以下步骤：

  1. 手动触发一次 Full GC： jmap -histo:live <pid>
  2. 再次执行 jmap -heap <pid> 查看堆内存情况

执行完后，再执行 jmap -heap <pid> ，没有发现明显变化。

这时我们推测，JVM 中可能没有多少可回收的垃圾，问题可能出在某个业务模块使用了大量缓存（如 Map 等数据结构）。不过，这个结论还不够确定，因为 jmap -histo:live 的结果可能受到正在执行的线程影响，这一步得出的结论还不足以定位出具体是哪一块的问题。

# 3. 分析堆转储文件

为了获得更详细的信息，我们决定生成堆转储文件进行分析：

jmap -dump:format=b,file=/home/xxx/sch/my.dump <pid>

我们使用 VisualVM 分析 dump 文件（也可以使用 MAT）。分析结果显示：

  • String 对象数量异常多
  • SimpleMessage 对象数量异常多
  • LinkedBlockingQueue$Node 对象数量异常多

通过代码审查，我们发现这些对象与线程池的任务队列有关。进一步分析发现：

  1. 使用了无界队列
  2. 消费速度跟不上生产速度
  3. 队列中积压了大量任务，从而触发频繁的 Full GC

我们意识到，如果继续这样下去，很可能会导致 OutOfMemoryError。

# 解决方案

问题定位后，我们考虑了以下解决方案：

  1. 修改队列类型：考虑到原设计可能有其合理性，我们暂时没有采取这个方案。

  2. 优化任务处理逻辑：

    • 将原来使用 synchronized 的地方改为使用 Lock ，降低锁的粒度。
    • 实现批量处理逻辑：当队列中任务数量超过阈值时，启用批量处理模式，提高处理效率。

实施步骤：

  1. 我们首先在话务量环境中部署了第一个优化方案（使用 Lock 替换 synchronized ）。
  2. 验证没有问题后，这解决了紧急情况。
  3. 随后，我们又实现并部署了批量处理的优化，进一步提升了系统性能。

# 总结

这次问题的解决过程展示了系统性能优化的一般步骤：

  1. 发现问题：监控系统性能指标。
  2. 初步分析：使用 JVM 工具如 jstat 和 jmap 快速定位可能的问题区域。
  3. 深入分析：生成并分析堆转储文件，结合代码审查找出根本原因。
  4. 制定方案：根据分析结果设计优化方案。
  5. 逐步实施：先解决紧急问题，然后进行进一步的优化。
  6. 持续监控：部署优化方案后继续监控系统，确保问题得到解决。