流殃的博客

| Comments

问题

  1. ypc频繁
  2. fgc频繁
  3. 内存泄漏

fgc频繁

原因

  • 代码中一次获取了大量的对象，导致内存溢出，此时可以通过eclipse的mat工具查看内存中有哪些对象比较多；
  • 内存占用不高，但是Full GC次数还是比较多，此时可能是显示的System.gc()调用导致GC次数过多，这可以通过添加-XX:+DisableExplicitGC来禁用JVM对显示GC的响应。

  • 解决步骤

  1. top 命令 查看哪个java进程CPU占用最高
  2. top -Hp 进程号 查看这个进程当中哪些线程占用CPU最高
  3. printf "%x" pid 将10进制的pid转化为16进制,因为jstack出来的线程是16进制，为了下面jstack做准备
  4. jstat -gcutil pid interval pid是线程id interval表示时间间隔，单位是秒
  5. 从上面图中就可以看出是ygc 频繁还是fgc 拼、或者是内存泄漏等问题

CPU过高

对于CPU的使用情况来说，一般超过80%就是比较高的，80%左右是合理情况

原因

  • FGC频繁
  • 代码中有比较耗时的代码

解决方案

如果是fgc频繁，就按照上面解决fgc频繁的方法来，如果是代码中有比较耗时的代码，就使用jstack 来获取到一个线程的具体堆栈信息，从中可以定位到某一个类的多少行，然后去看具体的代码来进行判断原因

不定期出现的接口耗时现象

其实这个问题主要是出在了不定期上面，既然是不定期，那我们就加大的访问量，压测它，让这种接口出现耗时现象的概率尽可能的增大，然后对比多个线程的堆栈日志，如果是有很多相同的堆栈日志，那么就是这里的问题了

死锁

通过jstack就可以定位到了

总结

  1. 通过top命令查看CPU情况，如果CPU比较高，则通过top -Hp 命令查看当前进程的各个线程运行情况，找出CPU过高的线程之后，将其线程id转换为十六进制的表现形式，然后在jstack日志中查看该线程主要在进行的工作。这里又分为两种情况
  • 如果是正常的用户线程，则通过该线程的堆栈信息查看其具体是在哪处用户代码处运行比较消耗CPU；
  • 如果该线程是VM Thread，则通过jstat -gcutil 命令监控当前系统的GC状况，然后通过jmap dump:format=b,file= 导出系统当前的内存数据。导出之后将内存情况放到eclipse的mat工具中进行分析即可得出内存中主要是什么对象比较消耗内存，进而可以处理相关代码；
  1. 如果通过top命令看到CPU并不高，并且系统内存占用率也比较低。此时就可以考虑是否是由于另外三种情况导致的问题。具体的可以根据具体情况分析：
  • 如果是接口调用比较耗时，并且是不定时出现，则可以通过压测的方式加大阻塞点出现的频率，从而通过jstack查看堆栈信息，找到阻塞点；
  • 如果是某个功能突然出现停滞的状况，这种情况也无法复现，此时可以通过多次导出jstack日志的方式对比哪些用户线程是一直都处于等待状态，这些线程就是可能存在问题的线程；
  • 如果通过jstack可以查看到死锁状态，则可以检查产生死锁的两个线程的具体阻塞点，从而处理相应的问题。

参考文章

Comments

评论