JVM优化(一)

1.为什么要对JVM做优化?
解决应用卡住 日志不输出 程序没有反应 服务器CPU负载突然升高 分配线程数量 等问题

2.三种参数类型
java -help 查询标准参数

3.常用命令
java -version 查看jvm版本
java -x 查看非标准参数
-xx参数也是非标准参数 主要用于jvm的调优和debug操作

如:-XX:+DisableExplicitGC 表示禁用手动调用gc操作,也就是说调用
System.gc()无效

-Xms与-Xmx分别是设置jvm的堆内存的初始大小和最大大小。
-Xmx2048m:等价于-XX:MaxHeapSize,设置JVM最大堆内存为2048M。
-Xms512m:等价于-XX:InitialHeapSize,设置JVM初始堆内存为512M。
适当的调整jvm的内存大小,可以充分利用服务器资源,让程序跑的更快

java ‐Xms512m ‐Xmx2048m TestJVM

4.JDK1.7堆内存模型

 年轻区  :年轻区被划分为三部分 Eden区和两个大小严格相同的Survivor区 其中Survivor区间中 某一时刻只有其中一个是被使用的
另外一个留作垃圾收集时赋值对象用  在Eden区间变满的时候 GC就会将存货的对象移到控线的Survivor区间中  根据JVM的策略
在经过 几次垃圾收集后 仍然存活于Survivor对象将被移到到Tenured区间
Tenured 年老区 
Tenured区主要保存生命周期长的对象,一般是一些老的对象,当一些对象在Young
复制转移一定的次数以后,对象就会被转移到Tenured区,一般如果系统中用了
application级别的缓存,缓存中的对象往往会被转移到这一区间。

Perm 永久区

Perm代主要保存class,method,filed对象,这部份的空间一般不会溢出,除非一次性
加载了很多的类,不过在涉及到热部署的应用服务器的时候,有时候会遇到
java.lang.OutOfMemoryError : PermGen space 的错误,造成这个错误的很大原因
就有可能是每次都重新部署,但是重新部署后,类的class没有被卸载掉,这样就造
成了大量的class对象保存在了perm中,这种情况下,一般重新启动应用服务器可以
解决问题。
Virtual区:
最大内存和初始内存的差值,就是Virtual区。

5.JDK1.8的堆内存模型
年轻代:Eden + 2* Survivor
年老代:OldGen
在jdk1.8中变化最大的Perm区 用Metaspace (元数据空间)进行了替换
注:Metaspace所占用的内存空间不是在虚拟机内部 而是在本地内存空间中 这也是与1.7的永久代最大的区别所在

问题:为什么要废弃1.7中的永久代?
现实使用中 由于永久代内存经常不够用或发生内存泄露 爆出异常 java.lang.OutOfMemoryError:PermGen
基于此 将永久区废弃 而改用元空间 改为了使用本地内存空间

6.通过jstat命令查看堆内存使用情况

E:\Study\test>jps
7264
20152 Jps

E:\Study\test>jstat -class 7264
Loaded  Bytes  Unloaded  Bytes     Time
69478 143929.7     2445  2738.5     182.31

Loaded:加载class的数量
Bytes:所占用空间大小
Unloaded:未加载数量
Bytes:未加载占用空间
Time:时间

7.查看编译统计 jstat -compiler 7264

E:\Study\test>jstat -compiler 7264
Compiled Failed Invalid   Time   FailedType FailedMethod
   63960     12       0   240.40          1 com/intellij/codeInspection/bytecodeAnalysis/BytecodeAnalysisIndex$EquationsExternalizer readEquations
Compiled:编译数量。
Failed:失败数量
Invalid:不可用数量
Time:时间
FailedType:失败类型
FailedMethod:失败的方法

8.垃圾回收统计 jstat -gc 7264

S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
29184.0 29184.0 7919.7  0.0   233664.0 131073.0  583844.0   196526.6  439784.0 418569.4 60388.0 52855.2    344    2.466   7      8.294   10.760
S0C:第一个Survivor区的大小(KB)
S1C:第二个Survivor区的大小(KB)
S0U:第一个Survivor区的使用大小(KB)
S1U:第二个Survivor区的使用大小(KB)
EC:Eden区的大小(KB)
EU:Eden区的使用大小(KB)
OC:Old区大小(KB)
OU:Old使用大小(KB)
MC:方法区大小(KB)
MU:方法区使用大小(KB)
CCSC:压缩类空间大小(KB)
CCSU:压缩类空间使用大小(KB)
YGC:年轻代垃圾回收次数
YGCT:年轻代垃圾回收消耗时间
FGC:老年代垃圾回收次数
FGCT:老年代垃圾回收消耗时间
GCT:垃圾回收消耗总时间

9.jmap的使用以及内存溢出分析
1)查看内存使用情况 jmap -heap 7264
https://blog.csdn.net/coding__coder/article/details/107570307
2)jmap -hosto 7264 | more 查看所有对象 包括活跃以及非活跃的
3)将内存使用情况dump到文件中 jmap -dump:format=b,file=E:\Study\test\test.dat 7264

C:\Users\21016> jmap -dump:format=b,file=E:\Study\test\test.dat 7264
Dumping heap to E:\Study\test\test.dat ...
Heap dump file created

4)通过jhat对dump文件进行分析
我们将jvm的内存dump到文件中 这个文件时一个二进制的文件 不方便查看 这时可以借助jhat工具进行查看

C:\Users\21016>jhat -port 9999 E:\Study\test\test.dat
Reading from E:\Study\test\test.dat...
Dump file created Thu Sep 24 20:19:42 CST 2020
Snapshot read, resolving...
Resolving 4984647 objects...
Chasing references, expect 996 dots.

打开浏览器访问:
在这里插入图片描述

10.通过Mat工具对dump文件进行分析:下节再见

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值