关于java:记一次java内存存异常排查过程

33次阅读

共计 1165 个字符,预计需要花费 3 分钟才能阅读完成。

一、景象
java 服务内存异样,占用服务器内存过高
二、排查步骤
1、首先看堆内存是否失常
下载 arthas,dashborad 一看,发现新生代只有 300M,而老年代有 6000M,很显著有内存透露,导致无奈回收,存活到了老年代
2、而后看看 gc 日志,因为服务器始终开着 gc,很容易找到 gc 日志,利用 gceasy.io 疾速看一下 gc 日志状况,惊奇的发现,新生代,老年代 gc 回收一切正常,而且 fullgc 不频繁,老年代失常回收,那为什么老年代那个大呢?
3、目前开来堆失常,然而内存始终变大,于是眼光转向堆外内存,于是利用 arthas 的察看一下堆外内存,然而发现 directmemory 和 mappedmemory 都失常,也不是堆外内存透露
4、根本能够确认堆内没,眼光还是放在堆外,起初发现了 jcmd 工具,然而须要重启服务,不敢乱用,然而发现了 jcmd 输入还有一个这个
Thread (reserved=159383KB, committed=159383KB)

                        (thread #156)
                        (stack: reserved=158720KB, committed=158720KB)
                        (malloc=482KB #788) 
                        (arena=182KB #310)

忽然想到服务线程情况还没看,用 arthas 一看,天,17000 个线程
5、那根本能够确定是线程创立过多导致,查看大量的线程名字是 pool-15000-thread-1,于是日志找一下就发现了这个线程是做什么的,发现了这样的代码

public JSONObject aaa(List<Long> Ids) throws Exception{ExecutorService executorService = Executors.newFixedThreadPool(5);
    List<Future<JSONArray>> futureList=new ArrayList<>();
    JSONObject resultJson=new JSONObject();
    for (Long Id:Ids) {
        futureList.add(executorService.submit(new Callable<JSONArray>() {
                @Override
                public JSONArray call() throws Exception {return bbb(Id);
                }
            })
        );
    }
    for (int i=0;i<Ids.size();i++){Future<JSONArray> future=futureList.get(i);
        resultJson.put(Ids.get(i).toString(),future.get());
    }
    return resultJson;
}

这是一个解决就新建了线程池,会导致创立大量的线程无奈回收
三、反思
应该利用公共的线程池,而不是用的时候就创立!!!

正文完
 0