JVM和GC案例详解

接上文JVM环境配置说明：上文博客

一、JVM远程连接设置

1. JMX方式连接(这种方式没有GC监控)，设置如下

2. 连接成功后可以查看基础配置参数(和服务器配置一致)

2. jstatd方式连接(这种方式没有CPU监控)

1. 添加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字符串和类的静态变量

二、 模拟在压测情况下查看GC状况

1. 执行压测

年轻代GC回收频率：35/32=1.09s GC一次

2. 更改tomcat配置为1G

1. cd /usr/local/tomcat7-8083/bin/
   

2. 重启tomcat和 j-start-jstatd.sh查看配置
   

3. 再次压测
   

4. 查看GC频率
   
   年轻代GC回收频率：2/66=0.030s

5. GC压测现象
   GC太频繁，不够用了，JC次数太多对性能有影响，小于1肯定是有问题的，频繁垃圾回收太多，占用资源，尽量减少次数，JC回收频繁(可导致内存不足)，通过JC回收机制做性能优化

6. 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查看线程死锁报错，给开发分析原因
线程死锁：导致内存溢出或程序卡死