# jvm基础01

jvm基础01

1. jvm参数

1.1 jvm运行参数

    1. 标准参数 ，以-开头设置参数，可以用java -help 查看标准参数

java -help|showversion|version|server|client

  • 2.非标准参数-X,以-X开头，可以用java -X查看参数

java -Xint|Xcomp|Xmixed

  • 3.-XX参数，以-XX：开头，主要用于jvm的调优和debug操作

java -XX:newSize|+UseSerialGC|newRatio=1

1.2 -server与-client参数

    1. 初始化堆空间

ServerVM的初始堆空间会大一些，默认使用的是并行垃圾回收器，启动慢运行快。
ClientVM相对来讲会保守一些，初始堆空间会小一些，使用串行的垃圾回收器，
它的目标是为了让JVM的启动速度更快，但运行速度会比Serverm模式慢些。

    1. JVM在启动的时候会根据硬件和操作系统自动选择使用Server还是Client类型的JVM。

32位操作系统如果是Windows系统，不论硬件配置如何，都默认使用Client类型的JVM。
如果是其他操作系统上，机器配置有2GB以上的内存同时有2个以上CPU的话默认使用server模式，否则使用client模式。

64位操作系统只有server类型，不支持client类型。

    1. 执行命令： java‐server‐showversion TestJVM

1.3 执行模式

  • 在解释模式(interpretedmode)下，-Xint标记会强制JVM执行所有的字节码，当然这会降低运行速度，通常低10倍或更多。
  • -Xcomp参数与它（-Xint）正好相反，JVM在第一次使用时会把所有的字节码编译成本地代码，从而带来最大程度的优化。然而，很多应用在使用-Xcomp也会有一些性能损失，当然这比使用-Xint损失的少，原因是-xcomp没有让JVM启用JIT编译器的全部功能。JIT编译器可以对是否需要编译做判断，如果所有代码都进行编译的话，对于一些只执行一次的代码就没有意义了。
  • -Xmixed是混合模式，将解释模式与编译模式进行混合使用，由jvm自己决定，这是jvm默认的模式，也是推荐使用的模式。

强制设置运行模式

#强制设置为解释模式
[root@node01test]#java ‐showversion ‐Xint TestJVM
#强制设置为编译模式
[root@node01test]#java ‐showversion ‐Xcomp TestJVM
#默认的混合模式[root@node01test]#java ‐showversion TestJVM

1.4 jvm常用查看堆的参数

#-Xms与-Xmx,-Xmn分别是设置jvm的堆内存的初始大小和最大大小,最小大小
#-Xmx2048m：等价于-XX:MaxHeapSize，设置JVM最大堆内存为2048M。
#-Xms512m：等价于-XX:InitialHeapSize，设置JVM初始堆内存为512M。
[root@node01test]#java ‐Xms512m ‐Xmx2048m TestJVM

#查看jvm的运行参数
#1.运行java命令时打印参数
java‐XX:+PrintFlagsFinal ‐XX:+VerifySharedSpaces ‐version

#2.查看正在运行的jvm参数
#查看某一参数的值，用法：jinfo‐flag<参数名><进程id>
[root@node01bin]#jps -l #查看进程id
[root@node01bin]#jinfo ‐flag MaxHeapSize 6219

2. jvm内存模型

2.1 jvm内存区

    1. jdk1.7的内存模型

jvm运行时内存为：Eden区+2*Survivor区+OldGen区+Perm区 即是新生代和老年代，永久代的总和

    1. jdk1.8的内存模型

jvm运行时内存为：Eden区+2*Survivor区+OldGen区+MetaSpaces 即是新生代和老年代，元空间的总和
jdk1.8时，移除了永久代，因为JRockit VM虚拟机并不支持永久代，为了同时兼容HotSpot VM和JRockit VM虚拟采用元空间MetaSpaces来代替，此时的元空间不再受虚拟机的内存限制，而是直接受本地电脑内存的限制，从而大大地避免oom现象。

2.2 jvm堆内存模型

  • 新生代（Eden区+2*Survivor区）

Young区被划分为三部分，Eden区和两个大小严格相同的Survivor区，其中，Survivor区间中，某一时刻只有其中一个是被使用的，另外一个留做垃圾收集时复制对象用，在Eden区间变满的时候，GC就会将存活的对象移到空闲的Survivor区间中，根据JVM的策略，在经过几次垃圾收集后，任然存活于Survivor的对象将被移动到Tenured区间

  • 老年代（OldGen区）

Tenured区主要保存生命周期长的对象，一般是一些老的对象，当一些对象在Young复制转移一定的次数以后，对象就会被转移到Tenured区，一般如果系统中用了application级别的缓存，缓存中的对象往往会被转移到这一区间。

  • 永久代（Perm区）

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

  • Virtual区

最大内存和初始内存的差值，就是Virtual区

2.3 查看堆内存使用情况

  • jstat命令可以查看堆内存各部分的使用量，以及加载类的数量
[root@node01~]#jps #查看进程ID
# jstat[-命令选项][vmid][间隔时间/毫秒][查询次数]:
#1：查看class加载统计
[root@node01~]#jstat ‐class 6219
Loaded Bytes Unloaded Bytes Time 
3273	7122.3 	0 	0.0	3.98
  • Loaded：加载class的数量Bytes：所占用空间大小Unloaded：未加载数量Bytes：未加载占用空间Time：时间
#2：查看编译统计
[root@node01~]# jstat ‐compiler 6219

说明：

  • Compiled：编译数量。
  • Failed：失败数量
  • Invalid：不可用数量
  • Time：时间
  • FailedType：失败类型
  • FailedMethod：失败的方法
#3：垃圾回收统计
[root@node01~]# jstat ‐gc 6219
#也可以指定打印的间隔和次数，每1秒中打印一次，共打印5次
[root@node01~]#	jstat	‐gc	62191	000 5

说明：

  • 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：垃圾回收消耗总时间
  • jmap的使用以及内存溢出分析
[root@node01~]#jps #查看进程ID
#1：查看内存使用情况（NewRatio，SurvivorRatio，NewRatio）
[root@node01~]# jmap ‐heap 6219
#2：查看内存中对象数量及大小
#查看所有对象，包括活跃以及非活跃的
[root@node01~]# jmap ‐histo<pid>|more
#查看活跃对象
[root@node01~]# jmap ‐histo:live <pid> | more
[root@node01~]# jmap ‐histo:live 6219 |more
num  #instances #bytes class  name
........

#3：将内存使用情况dump到文件中
#示例
[root@node01~]# jmap‐dump:format=b,file=/tmp/dump.dat 6219
....

#4：通过jhat对dump文件进行分析
[root@node01~]#  jhat‐port9999/tmp/dump.dat
  • jstack的使用查看正在运行的jvm的线程情况

查看下jvm中的线程执行情况，比如，发现服务器的CPU的负载突然增高了、出现了死锁、死循环等
[root@node01bin]#jstack2203

  • VisualVM工具的使用

VisualVM，能够监控线程，内存情况，查看方法的CPU时间和内存中的对象，已被GC的对象，反向查看分配的
堆栈(如100个String对象分别由哪几个对象分配出来的)。VisualVM使用简单，几乎0配置，功能还是比较丰富的，几乎囊括了其它JDK自带命令的所有功能。

  • 内存信息线程信息
  • Dump堆（本地进程）
  • Dump线程（本地进程）
  • 打开堆Dump。堆Dump可以用jmap来生成。
  • 打开线程Dump
  • 生成应用快照（包含内存信息、线程信息等等）
  • 性能分析。CPU分析（各个方法调用时间，检查哪些方法耗时多），内存分析（各类对象占用的内存，检查哪些类占用内存多）
#启动方式 进入jdk的安装目录的bin目录下，找到jvisualvm.exe
[root@node01~]# jvisualvm # 可以看到对应的jvm对信息和参数
  • 监控远程的jvmVisualJVM

VisualJVM不仅是可以监控本地jvm进程，还可以监控远程的jvm进程，需要借助于JMX技术实现
JMX（JavaManagementExtensions，即Java管理扩展）是一个为应用程序、设备、系统等植入管理功能的框架。
JMX可以跨越一系列异构操作系统平台、系统体系结构和网络传输协议，灵活的开发无缝集成的系统、网络和服务管理应用

  • 监控远程的tomcat

远程的tomcat进行对JMX配置

#在tomcat的bin目录下，修改catalina.sh，添加如下的参数
JAVA_OPTS="‐Dcom.sun.management.jmxremote ‐
Dcom.sun.management.jmxremote.port=9999 ‐
Dcom.sun.management.jmxremote.authenticate=false ‐
Dcom.sun.management.jmxremote.ssl=false" 
#这几个参数的意思是：
#‐Dcom.sun.management.jmxremote：允许使用JMX远程管理
#‐Dcom.sun.management.jmxremote.port=9999：JMX远程连接端口
#‐Dcom.sun.management.jmxremote.authenticate=false：不进行身份认证，任何用户都可以连接
#‐Dcom.sun.management.jmxremote.ssl=false：不使用ssl

使用VisualJVM连接远程tomcat: 连接远程主机：ip:9999

posted @ 2021-06-22 17:46  易阳羽之灵异  阅读(60)  评论(0)  编辑  收藏  举报