记一次JVM故障排除

今天，自己开发的事件驱动的java大规模爬虫程序上线了几个新任务后突然异常。

异常：

　　 程序业务异常，经查看CPU利用率满，内存满，一直报OOM，目测有内存泄露。如下图所示，四核16G的内粗，CPU高达400%，内存使用了 6G，刚好爆满，JVM启动参数为：

java -server -Xmx6114M -Xms2048M -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime -Xloggc:/home/ubuntu/logs/spider/master/gc.log -XX:+PrintGCDateStamps -XX:SurvivorRatio=8 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/ubuntu/heap/spider/master/dump -jar /home/ubuntu/apps/spider-service/spider-master/current

内存截图:

 

分析：

　　首先找java进程为13419，找到该进程的什么线程使用最多，运行top -p 13419 -H  得到如下截图，一直观察得出，有四个线程一直占用100%的CPU；

 

 

　　于是设法找到CPU的线程的调用栈，运行 jstack 13419 >表示 jstack.log 查看文件信息，发现没有对应线程的状态，也就找不到调用栈（注意，想找线程nid，可能需要转换16进制表示，因为线程nid在jstack.log中为16进制）

  

　　

　　想到这里，已经知道，该上面四个线程应该是GC线程，所以找不到，因此确定到堆文件分析；也就是初步断定没有死锁，而是堆溢出，但不一定是内存泄露；到这里，当然要去看看堆的GC情况了，运行jstat看看，如下图（S0为survive0区，S1为survive1区，而U代表使用，C代表总大小，E、O、M分别代表年轻代，年老代，Meta区，T为时间）,不断的YGC而没有释放内存。

　　在重量级的分析堆文件之前，我们可以运行jmap -histo 13419 >out.log查看对象的数量和持有内存分布，得到个大体情况；然后运行 jmap -dump:live,format=b,file=heap-dump.bin 13419  获得堆文件；其实jhat是可以分析堆文件的，但是我最终用了eclipse插件；

 

代码定位：

　　最后定位到一个EventBus类持有5G大小，上千万个对象没处理，看看该类代码：

package com.mobisummer.spider.master.eventbus;

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentLinkedQueue;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.atomic.AtomicInteger;

import com.mobisummer.spider.master.ctrlcentre.SpiderController;
import com.mobisummer.spider.master.ctrlcentre.monitor.Monitor;
import com.mobisummer.spider.master.ctrlcentre.monitor.Monitored;
import com.mobisummer.spider.master.eventbus.loop.BloEventGroup;
import com.mobisummer.spider.master.eventbus.loop.NloEventGroup;
import com.mobisummer.spider.master.eventbus.model.EventType;
import com.mobisummer.spider.master.eventbus.model.EventTask;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;


/**
 * 消息总线-双向队列
 * @date 2019年1月9日
 */
@Component
public class EventBus implements Monitored {

  private static Logger log = LoggerFactory.getLogger("event");
  private LinkedBlockingQueue<EventTask> taskRegistered = new LinkedBlockingQueue<>(); // wait to be handled
  private ConcurrentLinkedQueue<EventTask> taskPool = new ConcurrentLinkedQueue<>(); // for reuse
  private ConcurrentHashMap<Integer,AtomicInteger> eventCount =new ConcurrentHashMap<>();

  @Autowired
  SpiderController spiderController;

  public EventBus() {
    Monitor.register(this);
  }

  /**
   * add  event to queue tail
   *
   * @param eventType
   * @param itemId
   * @param object
   */
  public void push(String itemId,int eventType, Object object) {
    EventTask spiderEvent = retrieveEvent(eventType, itemId, object,spiderController);
    try {
      if(object==null){
        System.out.println("");
      }
      if(spiderEvent.object==null){
        System.out.println("");
      }
      taskRegistered.put(spiderEvent);
    } catch (InterruptedException e) {
      log.error("put item to queue cause an exception", e);
    }
    log.debug("add an event to tail of the queue, item id is {} , type is {}. the queue size is {} now", itemId, EventType
        .getDescription(spiderEvent.eventType), taskRegistered.size());
  }

  private EventTask retrieveEvent(int eventType, String itemId, Object object,EventHandler handler) {
    EventTask spiderEvent = taskPool.poll();
    if(spiderEvent == null) {
      spiderEvent = new EventTask(eventType, itemId, object,handler);
    } else {
      spiderEvent.eventType = eventType;
      spiderEvent.itemId = itemId;
      spiderEvent.object = object;
      spiderEvent.handler =handler;
    }
    return spiderEvent;
  }

  /**
   * 循环消费需要处理的事件
   */
  public void loop() {
    while (true) {
     
    }
  }

  public void releaseEvent(EventTask spiderEvent) {
    spiderEvent.object = null;
    taskPool.add(spiderEvent);
  }

  public static void eventError(Integer eventType, String itemId, Object object,Exception e){
    String errDesc= "handle event cause an exception ======" +e.toString()+"======";
    if(eventType!=null){
      errDesc = errDesc+eventType ;
    }
    if(itemId!=null){
      errDesc =errDesc+itemId;
    }
    if(object!=null){
      errDesc =errDesc+object.toString();
    }
    log.error(errDesc);
  }

  @Override
  public Object getHealthIndex() {
    String desc ="";
    for(Integer event :eventCount.keySet()){
      desc =desc+"\n事件："+EventType.getDescription(event)+" 该事件共产生次数"+eventCount.get(event);
    }
    return desc;
  }

  private void countEvent(int eventType){
    AtomicInteger count =  eventCount.get(eventType);
    if(count==null){
      count = new AtomicInteger();
      eventCount.put(eventType,count);
    }else {
      count.incrementAndGet();
    }
  }
}

 

　　这是一个事件总线，可以看出因为堆溢出，不断的GC，处理事件的是一个单线程根本没有被调度的机会，或许已经挂了！堆积事件不处理，这个不是内存泄露，只是系统崩盘了，最后重构调度代码，重视调度，构建调度抽象：

 

重构：

　　先把事件分类，绑定事件和控制器，做成状态机，然后通过EventBus分配给阻塞的Blo执行或者非阻塞的Nlo执行，而且各自分配Eventloop去执行；重构后上线，加大压测；能承受量加大了！不过系统还是要有机制拒绝服务才行的，这个就是后话了。 　　

 

转载于:https://www.cnblogs.com/iCanhua/p/10534643.html