一，jvisualVM介绍
jvisualVM是一款jdk自带的图像化jvm性能监控工具，可以：
- 实时监控堆内存的变化情况
- 一键生成堆转储文件并解析并图形化展示
- dump线程信息(相当于jstack)
- 堆内存profiler(相当于jmap -histo展示堆内对象直方图)
- CPU、内存、线程、已加载的类统计
二，实时监控堆内存使用情况
很棒的一点是，这个图是动态变化的，可以动态的看见堆内存各区域的动态变化：
- eden区内存占用逐渐增多
- eden区垃圾回收
- eden区对象复制到幸存区
- 幸存区对象复制到老年代
- full gc
- ygc的统计数据
- fgc的统计数据
使用案例：
生产环境服务器处理业务请求变慢，通过jvisualVM发现ygc的次数非常频繁，没发生fgc，老年代的空间非常充足，以上现象说明eden区的空间小，但是这台机器的内存是32G，不至于缺乏内存，从jvisualVM上看，可用的eden区内存高达3G。那为什么会频繁的ygc呢？
仔细研究发现，虽然eden区的可用内存也即最大可分配内存高达3G，但实际分配给eden区的内存只有150M，难怪ygc那么频繁。
那为什么只分配给eden区150M内存呢，继续观察发现old区的分配内存也没有想象中的多，但是old区在不断的动态调整，不断扩大，eden区的实际分配内存基本没有变化。
心里大致有底了，检查了下jvm参数，发现没有配置-Xms、-Xmx，在没有明确指定堆内存的大小的情况下，jvm会根据应用所需要的最小堆内存进行内存规划，导致了eden区过小。
定位到了这个问题，就知道该怎么办了，显式配置-Xms8g、-Xmx8g，重启应用，ygc明显减少，应用吞吐量大幅增加，一次成功的jvm优化。
这里需要清楚jvisualVM的visual gc界面的使用，visual gc是jvisualVM的插件，要先安装，安装极其简单，通过jvisualVM即可快速完成。
visual gc界面详解：
三， 一键生成堆转储文件并解析并图形化展示
后面再分析MAT的使用。
四，dump线程信息(相当于jstack)
查看线程状态及各状态持续时间。
可惜的是，不能搜索，生成环境几十上百个线程，不能搜索就代表着鸡肋。
案例：定位C3P0连接池满导致应用阻塞，响应缓慢
thread2一直被阻塞，直接原因是线程池连接数全部被占用，连接池被用完有如下几个可能：
- 连接池数设置过少
- sql执行慢，导致连接长时间被占用
- 连接使用完成后未被释放
- 数据库异常，如锁表
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/157976.html