0
点赞
收藏
分享

微信扫一扫

JVM虚拟机小结1


1 jps -l //列出详细的类名和进程ID

2)jps -m // 显示运行的程序接收的参数

3)jps -v //查看接收的JVM方面的参数

4)jps 先查出进程ID后
jstat -gcutil pid 1000 10 //每隔离1000毫秒打印,搞10次


jstaat -gcnew pid //显示新生代情况

D:\PSTools>jstat -gcnew 5328
S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT
62976.0 58368.0 0.0 42323.6 14 15 62976.0 199168.0 106984.4 177 5.470


显示列名

具体描述

S0C

年轻代中第一个survivor(幸存区)的容量 (字节)

S1C

年轻代中第二个survivor(幸存区)的容量 (字节)

S0U

年轻代中第一个survivor(幸存区)目前已使用空间 (字节)

S1U

年轻代中第二个survivor(幸存区)目前已使用空间 (字节)

EC

年轻代中Eden(伊甸园)的容量 (字节)

EU

年轻代中Eden(伊甸园)目前已使用空间 (字节)

OC

Old代的容量 (字节)

OU

Old代目前已使用空间 (字节)

PC

Perm(持久代)的容量 (字节)
------------------------------------------------------

jstat -gcutil <pid>:统计gc信息

其中:

S0

年轻代中第一个survivor(幸存区)已使用的占当前容量百分比

S1

年轻代中第二个survivor(幸存区)已使用的占当前容量百分比

E

年轻代中Eden(伊甸园)已使用的占当前容量百分比

O

old代已使用的占当前容量百分比

P

perm代已使用的占当前容量百分比

YGC

从应用程序启动到采样时年轻代中gc次数

YGCT

从应用程序启动到采样时年轻代中gc所用时间(s)

FGC

从应用程序启动到采样时old代(全gc)gc次数

FGCT

从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT

从应用程序启动到采样时gc用的总时间(s)


-------------

jstat -gccapacity <pid>:可以显示,VM内存中三代(young,old,perm)对象的使用和占用大小


显示列名

具体描述

NGCMN

年轻代(young)中初始化(最小)的大小(字节)

NGCMX

年轻代(young)的最大容量 (字节)

NGC

年轻代(young)中当前的容量 (字节)

S0C

年轻代中第一个survivor(幸存区)的容量 (字节)

S1C

年轻代中第二个survivor(幸存区)的容量 (字节)

EC

年轻代中Eden(伊甸园)的容量 (字节)

OGCMN

old代中初始化(最小)的大小 (字节)

OGCMX

old代的最大容量(字节)

OGC

old代当前新生成的容量 (字节)

OC

Old代的容量 (字节)

PGCMN

perm代中初始化(最小)的大小 (字节)

PGCMX

perm代的最大容量 (字节)

PGC

perm代当前新生成的容量 (字节)

PC

Perm(持久代)的容量 (字节)

YGC

从应用程序启动到采样时年轻代中gc次数

FGC

从应用程序启动到采样时old代(全gc)gc次数

---------------------------------------
jstat -gcoldcapacity <pid>: old代对象的信息及其占用量


显示列名

具体描述

OGCMN

old代中初始化(最小)的大小 (字节)

OGCMX

old代的最大容量(字节)

OGC

old代当前新生成的容量 (字节)

OC

Old代的容量 (字节)

YGC

从应用程序启动到采样时年轻代中gc次数

FGC

从应用程序启动到采样时old代(全gc)gc次数

FGCT

从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT

从应用程序启动到采样时gc用的总时间(s)


5)jinfo opiton pid
jinfo -flag pid //查看某个进程用的GC,比如
、jinfo -flg UseSericGC PID


在JDK bundle中隐藏着一个精悍的小工具——jinfo。作为一个命令行工具,jinfo用于收集正在运行的Java进程的配置信息。jinfo吸引眼球的地方在于,它能通过-flag选项动态修改指定的Java进程中的某些JVM flag的值。虽然这样的flag数量有限,但它们偶尔能够帮助到你。通过以下的命令你便能看到JVM中哪些flag可以被jinfo动态修改:

my-precious me$ java -XX:+PrintFlagsFinal -version|grep manageable
intx CMSAbortablePrecleanWaitMillis = 100 {manageable}
intx CMSWaitDuration = 2000 {manageable}
bool HeapDumpAfterFullGC = false {manageable}
bool HeapDumpBeforeFullGC = false {manageable}
bool HeapDumpOnOutOfMemoryError = false {manageable}
... cut for brevity ...
bool PrintGC = false {manageable}
bool PrintGCDateStamps = false {manageable}
bool PrintGCDetails = false {manageable}
bool PrintGCTimeStamps = false {manageable}
通过选项-XX:+PrintFlagsFinal可以列出所有的JVM flag,而其中的标注为manageable 的flag则是值得我们关注的部分。这些flag可通过JDK management interface(-XX:+PrintFlagsFinal)动态修改。虽然在JConsole中也能查到与其十分相似的MBean。但在我看来,以命令行的方式查看它们更加的便捷。

如何使用jinfo
让我们通过实战来学习如何使用jinfo。在下面的例子中,我们将在一个正在运行的JVM中动态开启GC日志功能:

my-precious me$ jps
12278 HighAllocationRate
12279 Jps
12269 JConsole
my-precious me$ jinfo -flag +PrintGCDetails 12278
my-precious me$ jinfo -flag +PrintGC 12278
my-precious me$
在jinfo中需要打开-XX:+PrintGC和 -XX:+PrintGCDetails两个选项才能开启GC日志,这与用命令行参数的方式实现有着细微的差别——如果你通过启动脚本(startup script)来设置参数,仅需-XX:+PrintGCDetails即可,因为-XX:+PrintGC会被自动打开。

不过,从standard output的结果来看,PID为12278的进程的GC日志的确能够滚动地显示出来:

...
[GC (Allocation Failure) [PSYoungGen: 876416K->102624K(909312K)] 1094420K->320820K(1161216K), 0.2173131 secs] [Times: user=0.74 sys=0.00, real=0.22 secs]
...
[GC (Allocation Failure) [PSYoungGen: 890304K->102240K(917504K)] 1108924K->320956K(1169408K), 0.2446639 secs] [Times: user=0.82 sys=0.01, real=0.25 secs]
...
同理,若想关闭GC日志功能,只需要执行jinfo -flag -PrintGCDetails 12278和 jinfo -flag -PrintGC 12278命令即可。


6)jmap -dump:format=b,file=c:\aaa.bin pid
dump 出内存相关再用eclipse mat去分析;


如果结果是+号,标识有用,否则无用

7)jhat对 JMAP DUMP出来的BIN文件进行分析
jhat d:\xxxx.bin

完了后用http://localhost:7000/ 查询

8)jstack -F //强制打印
jstack -m //打印JAVA和本地方法栈
jstack -l pid //打印包含锁的信息


9) -XX:+PrintClassHistogram
按下Ctrl+Break后,打印类的信息:
num #instances #bytes class name
----------------------------------------------
1: 890617 470266000 [B
2: 890643 21375432 java.util.HashMap$Node
3: 890608 14249728 java.lang.Long
4: 13 8389712 [Ljava.util.HashMap$Node;
5: 2062 371680 [C
6: 463 41904 java.lang.Class


分别显示:序号、实例数量、总大小、类型

10) -XX:+TraceClassLoading
监控类的加载
[Loaded java.lang.Object from shared objects file]
[Loaded java.io.Serializable from shared objects file]
[Loaded java.lang.Comparable from shared objects file]
[Loaded java.lang.CharSequence from shared objects file]
[Loaded java.lang.String from shared objects file]
[Loaded java.lang.reflect.GenericDeclaration from shared objects file]
[Loaded java.lang.reflect.Type from shared objects file]


11) Xmn
设置新生代大小
-XX:NewRatio
新生代(eden+2*s)和老年代(不包含永久区)的比值
4 表示 新生代:老年代=1:4,即年轻代占堆的1/5
-XX:SurvivorRatio
设置两个Survivor区和eden的比
8表示 两个Survivor :eden=2:8,即一个Survivor占年轻代的1/10


12) -XX:+HeapDumpOnOutOfMemoryError
OOM时导出堆到文件
-XX:+HeapDumpPath
导出OOM的路径
-Xmx20m -Xms5m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:/a.dump


13)

打印GC的简要信息–[GC 4790K->374K(15872K), 0.0001606 secs]–
[GC 4790K->374K(15872K), 0.0001474 secs]–
[GC 4790K->374K(15872K), 0.0001563 secs]–
[GC 4790K->374K(15872K), 0.000168

这里-XX:+PrintGC,在GC前,堆空间4MB,GC后,堆为374KB,括号内表示当前可用堆为16MB


更详细的,需要-XX:+PrintGCDetails 参数;
-XX:+PrintGCTimeStamps–打印CG发生的时间戳?例–
[GC[DefNew: 4416K->0K(4928K), 0.0001897 secs] 4790K->374K(15872K), 0.0002232 secs]
[Times: user=0.00 sys=0.00, real=0.00 se


-Xloggc:log/gc.log–指定GC log的位置,以文件输出–帮助开发人员分析问题

14) 可以设置-xms=-xmx,减少程序运行的时候垃圾回收次数,提高性能;

15) 堆的分配参数?-Xmn–设置新生代大小
?-XX:NewRatio–新生代(eden+2*s)和老年代(不包含永久区)的比值–4 表示 新生代:老年代=1:4=(老年代/新生代=-xx:NewRatio);

即年轻代占堆的1/5?
-XX:SurvivorRatio–设置两个Survivor区和eden的比–8表示 两个Survivor :eden=2:8,即一个Survivor占年轻代的1/10

16)-XX:MaxDirectoryMemorySize,NIO用的直接内存,不属于堆;

17)./java -server -version
为服务模式,启动慢,但尝试更多信息去调优JVM,64位一般都为SERVER模式

18)标记清除算法,会产生碎片,适合老年代;标记复制算法,分两部分空间,把存活的对象赶到另外一半空间中,然后清除其中的有碎片的空间,适合新生代,因为垃圾多;

标记压缩算法:不需要两个空间,通过可达性分析,找到存活对象,直接压缩到另外一半空间,然后再清除剩下的,适合老年代;


19) JAVA强引用,软引用,弱引用,虚引用

参考:
​​​https://mp.weixin.qq.com/s/Rua3dUJbSyk02ide0R7rSA ​​​
软引用:当堆空间不足的时候,软引用被回收;当普通GC的时候,软引用不一定会被回收;
弱引用:只要发现,一律回收;
软引用和弱引用,十分适合做缓存,当内存不足的时候可以回收,当内存足的时候可以在内存相当时间;
虚引用:就象没引用一样,随时回收;

20) 回收器
A) 新生代用串行收集器
最古老,最稳定
效率高
可能会产生较长的停顿
-XX:+UseSerialGC
新生代、老年代使用串行回收
新生代复制算法
老年代标记-压缩
B 老年代--串行收集器,使用标记压缩算法,老年代停顿时间长

C 新生代ParNew
-XX:+UseParNewGC
新生代并行
老年代串行

-XX:+UseConcMarkSweepGC:新生代用parnew,老生代用CMS
Serial收集器新生代的并行版本
复制算法
多线程,需要多核支持
-XX:ParallelGCThreads 限制线程数量

D 新生代parallelGC


类似ParNew
新生代复制算法,关注吞吐量
老年代 标记-压缩
更加关注吞吐量
-XX:+UseParallelGC
使用Parallel收集器+ 老年代串行
-XX:+UseParallelOldGC
使用Parallel收集器+ 并行老年代
-XX:MaxGCPauseMills
最大停顿时间,单位毫秒
GC尽力保证回收时间不超过设定值
-XX:GCTimeRatio
0-100的取值范围
垃圾收集时间占总时间的比
默认99,即最大允许1%时间做GC
这两个参数是矛盾的。因为停顿时间和吞吐量不可能同时调优

E 老年代用并行parallelOldGC: 新生代用 parallelGC,老年代用并行,关注吞吐量

F CMS收集器
Concurrent Mark Sweep 并发标记清除
标记-清除算法
与标记-压缩相比
并发阶段会降低吞吐量
老年代收集器(新生代使用ParNew)
-XX:+UseConcMarkSweepGC


G CMS运行过程比较复杂,着重实现了标记的过程,可分为
初始标记
根可以直接关联到的对象
速度快
并发标记(和用户线程一起)
主要标记过程,标记全部对象
重新标记
由于并发标记时,用户线程依然运行,因此在正式清理前,再做修正
并发清除(和用户线程一起)
基于标记结果,直接清理对象


-XX:+ UseCMSCompactAtFullCollection Full GC后,进行一次整理
整理过程是独占的,会引起停顿时间变长
-XX:+CMSFullGCsBeforeCompaction
设置进行几次Full GC后,进行一次碎片整理
-XX:ParallelCMSThreads
设定CMS的线程数量


21) MaxTenuringThreshole,参数控制新生代对象的最大年龄,控制经过多少次GC后,进入年老代;但有的时候,即使到了,也不一定会晋升的;

22) PretenureSizeThreshold参数,控制新生代对象直接进入到老年代,前提是关闭TLAB

举报

相关推荐

JVM虚拟机

jvm虚拟机

JVM虚拟机与Android虚拟机

JVM虚拟机规范——1.简介

jvm虚拟机指令

java虚拟机(JVM)

java虚拟机 (JVM)

Java虚拟机(JVM)

0 条评论