接上文JVM环境配置说明：上文博客
一、JVM远程连接设置
1. JMX方式连接(这种方式没有GC监控)，设置如下
2. 连接成功后可以查看基础配置参数(和服务器配置一致)
2. jstatd方式连接(这种方式没有CPU监控)
- 添加jstatd方式连接
双击Tomcat，选择GC
-
由上图分析：
- Eden满了—>S0或S1
- GC Time（GC回收，总GC)：241ms执行了GC6次
- 从JVM参数上看是1：2的关系，老年代占比1.333G+年轻代差不多在2048m
-
VisualGC回顾分析：
- 年轻代eden
- Java应用在分配Java对象时，这些对象会被分配到年轻代堆空间中去,这个空间大多是小对象并且会被频繁回收
- s0与s1 生存区
- Eden区域被填满时,触发minor GC,此时将有效对象移动到s0或s1中去,s0与s1不会同时存放数据
- 老年代old
- 年轻代堆空间的长期存活对象会转移到（也许是永久性转移）年老代堆空间
- 这个堆空间通常比年轻代的堆空间大，并且其空间增长速度较缓
- 持久代（Permanent Generation）(JDK8之后叫元空间)
- 存放VM和Java类的元数据（metadata），以及interned字符串和类的静态变量
- 年轻代eden
二、 模拟在压测情况下查看GC状况
1. 执行压测
年轻代GC回收频率：35/32=1.09s GC一次
2. 更改tomcat配置为1G
-
cd /usr/local/tomcat7-8083/bin/
-
重启tomcat和 j-start-jstatd.sh查看配置
-
再次压测
-
查看GC频率
年轻代GC回收频率：2/66=0.030s -
GC压测现象
GC太频繁，不够用了，JC次数太多对性能有影响，小于1肯定是有问题的，频繁垃圾回收太多，占用资源，尽量减少次数，JC回收频繁(可导致内存不足)，通过JC回收机制做性能优化 -
GC的指标
Minor GC(年轻代垃圾回收)时间不到50ms,执行不频繁,不低于10秒一次
Full GC(老年代垃圾回收)执行时间不到1s,执行频率不低于10分钟一次
3. 模拟线程死锁
cd /usr/local/web/WebRoot/WEB-INF/classes/
vi config.properties
将最后一行改为Jtest=1,之后重启tomcat,就会模拟线程死锁的情况(开发特意配置，模拟现实环境)
点击线程Dump查看线程死锁报错，给开发分析原因
线程死锁：导致内存溢出或程序卡死
