「JVM调优」-记录一次线上调优经历

背景

一款游戏运行卡顿，玩家一直进不去，连接游戏服务一直超时。游戏服务器情况2core2g

排查流程

1.先看服务端负载情况

2.再看磁盘情况

3.如果不是磁盘满了，查看服务端进程问题

3.进程没有问题，查看内存是不是不够，是不是有内存泄露问题

排查过程

1.top命令查看服务器负载情况

load average数值非常高，top显示有一个Java线程CPU达到 500%。当看到这里的时候我就怀疑是Java线程写的有问题。

2.排查磁盘情况

df -h

发现磁盘正常，说明不是磁盘满了。

3.排查进程情况

前面排查到了线程CPU高达500%，说明一定有线程有问题。

4.查看负载高的线程

top -Hp pid 这个pid是top命令中找到的进程pid

发现有只有一个线程pid高达500左右。

5.导出Java线程栈

jstack -l pid >> stack.log

在stack.log里面搜索这个负载非常高的线程pid

最终找到如下

6.定位代码

at com.xxxx.xx.game.ludo.logic.Room.getPropCheckerNumber(Room.java:259)

通过这行代码，找到了位置。发现该方法有一个while循环，产生了死循环。

这里就发现了代码确实有问题，修改后恢复正常。

笔者也是一个菜鸡程序员，为什么会写这样一个while函数，并且导致了死循环。

/**
 * 获得棋子道具地方 而且不能有棋子在上面
 * @return
 */
private int getPropCheckerNumber(){
    int number = random.nextInt(CheckerBoard.maxNum) + 1 ;
    while(checkerPropMap.containsKey(number) || checkerBoardChessMap.containsKey(number)){
        number = random.nextInt(CheckerBoard.maxNum) + 1;
    }
    return number;
}

这是以前写的代码。背景是希望在棋牌空位上获取一个随机的位置放置道具。

笔者做法是，不停的随机一个位置，判断该位置有没有道具，或者没有玩家棋子，如果没有就说明有效，可以返回。

仔细一看是没有问题。

但是checkerPropMap这个位置，由于旧道具没有从map中清除掉（其他功能的问题），导致checkerPropMap最后整个棋牌都是道具，然后while循环退不出去，死循环，线程直接爆了，cpu直接爆了，服务器就挂了。

这种实现有两个问题。

1.不停的while循环，如果命中率不高，很有可能就性能不好。

2.一但while循环受到其他问题的影响，不能退出，可能对整个服务都造成影响。

后面笔者修改为

    /**
     * 获得棋子道具地方 而且不能有棋子在上面,只能是落在空白处
     * @return
     */
    private int getPropCheckerNumber(){
        List<Integer> getAvailableNumbers = new ArrayList<>();
        for (Integer i = 1; i <= CheckerBoard.maxNum; i++) {
            if(checkerPropMap.containsKey(i) || checkerBoardChessMap.containsKey(i) || immunityChecker.contains(i) || cannotInitProp.contains(i)){

            }else{
                getAvailableNumbers.add(i);
            }
        }
        if(getAvailableNumbers.size() == 0){
            return 0;
        }
        return getAvailableNumbers.get(random.nextInt(getAvailableNumbers.size()));
    }

做法是，找出棋盘上所有能用的空位置，随机一个空位置即可。问题解决。

后面笔者对于while循环特别慎重，希望读者不要犯笔者这个低级错误，原谅笔者这个菜鸡吧。

最后问题解决

当然如果不是线程问题，接下来如何处理呢？

7.导出dump堆

jmap -dump:format=b,file=文件名 [pid]

8.查看pid内存情况

jmap -heap pid

观察新生代，老年代，内存情况，看看老年代是不是满了，发生full gc

9.查看pid gc情况

jstat -gcutil pid 1000

每秒观察一次gc情况，看是否gc,full gc 次数多。

如果说gc次数多，有可能是新生代和老年代分配内存大小不合理，可以尝试调整下比率。

如果是full gc次数非常多，查看有没有可能由内存泄露，有内存一直没有释放。

10.jvisualvm查看内存情况

将导出来的堆信息，用jvisualvm来分析一下，看大内存到底是什么。

11.用Eclipse Memory Analyzer tool(MAT)来分析是否有内存泄露。

以上就是笔者的一次线上调优经验，笔者犯了一个低级错误，但是也成长了。希望这份经验能对你们有用。