java服务jvm使用查看

        写这篇博客, 发生的前提并不是刻意的去学习和了解jvm的知识, 然后做总结. 旨在记录一次因为线上dubbu服务超时而引起的Waiting server-side response timeout.
        初看报错信息为响应超时, 可以通过服务监控发现, 服务提供端一切都正常, 服务执行时间, SQL执行时间都很快, 偏偏在服务消费端的执行监控中, 该服务竟然需要近8S才得到响应, 而设置的超时时间是10S, 更诡异的是, 其它服务消费都是正常的, 单单就这个服务出现了问题. 而且为啥服务都跑了1个多月了, 现在才出现?
        一度摸不着头脑, 还以为该服务哪个地方的资源没有释放导致内存出问题了. 巧的是, 就这一个突然的想法, 想到了去查看当前服务的jvm使用情况!

首先查看当前服务所在的PID

# ps aux|grep mini

查看线程使用情况

# jstack 27542

一串像异常的东西, 看不懂, 也没有把问题解决, 也没找到点上

查看jvm内存使用情况

# jmap -heap 27542

         看到那一串串的99.999%, 瞬间明白问题出现在哪了, 新生代不够发生fullGC了. 新生代默认大小为服务分配内存的1/8. 对于jvm有一定了解的, 应该已经知道所以然了.
        不太了解的小伙伴可以参考jvm常用的调优参数

对于结果各参数的意义, 网上找到了一张图, 描述的挺清晰的, 就直接借用了

 最后就来说说解决的办法

1. 最快的, 最简单的, 莫过于服务重启了, 简单粗暴
2. 调整新生代,老年代的比例, 或者设置新生代大小
        -Xmn3g ： 新生代大小，一般设置为堆空间的1/3 1/4左右，新生代大则老年代小