乐趣区

Java虚拟机详解-一点课堂多岸教育

垃圾收集器

young 区

1.Serial

关注点:stw 的时间 复制算法 STW

2.ParNew

关注点:stw 的时间 Serial 的多线程版本 复制算法 STW

参数 -XX:ParallelGCThreads 并行线程数

3.Parallel Scavenge

关注点:达到一个可控制的吞吐量(吞吐量优先)复制算法
所谓吞吐量就是 CPU 运行用户代码的时间和 CPU 消耗的时间的比值,即吞吐量 = 运行用户代码时间 /(运行用户代码时间 + 垃圾收集时间)。

Paralled Scavenge 收集器提供了两个参数用于精确控制吞吐量。分别是控制最大垃圾收集停顿时间的 -XX:MaxGCPauseMillis , 以及直接设置吞吐量大小的 -XX:GCTimeRatio 参数。

参数

-XX:MaxGCPauseMillis 
-XX:GCTimeRatio
-XX:+UseAdaptiveSizePolicy 自适应调节策略

old 区

1.Serial Old

Serial 的老年代版本 
JDK1.5 之前可搭配 Parallel Scavenge 使用
在 CMS 发生 Concurrent mode failure 时使用
Mark-Compact

2.Parallel Old

Parallel Scavenge 的老年代版本
JDK1.6 出现 搭配 Parallel Scavenge 使用
Mark-Compact

3.CMS

-XX:+UseConcMarkSweepGC
Mark-Sweep
过程:初始标记 并发标记 重新标记 并发清除
初始标记和重新标记会 STW
耗时最长是并发标记和并发清除
默认回收线程数:CMS 默认启动的回收线程数目是 (ParallelGCThreads + 3)/4),可以通过 -XX:ParallelCMSThreads=20 来设定

优点:并发低停顿
缺点:1、对 CPU 资源非常敏感 
占用部分线程(CPU 资源)导致应用程序变慢,吞吐量降低
默认线程数 =(CPU 数量 +3)/4
2、无法处理浮动垃圾,可能出现 Concurrent mode failure 而导致另一次 fullGC 的产生
参数 -XX:CMSInitiatingOccupancyFraction 默认 68% CMS 触发百分比,CMS 执行期间,预留空间无法满足,就会出现 Concurrent mode failure 失败,启动后备 SerialOld 的方案,停顿时间更长了。(所以 CMSInitiatingOccupancyFraction 不能设置的过大)3、内存碎片
参数 -XX:+UseCMSCompactAtFullCollection(停顿时间加长) 默认开启
-XX:CMSFullGCsBeforeCompaction(执行多少次不进行碎片整理的 FullGC 后进行一次带压缩的)

其他参数
初始标记的并行化 -XX:+CMSParallelInitialMarkEnabled
为了减少第二次暂停的时间,开启并行 remark: -XX:+CMSParallelRemarkEnabled, 如果 remark 还是过长的话,可以开启 -XX:+CMSScavengeBeforeRemark(在 CMS GC 前启动一次 ygc,目的在于减少 old gen 对 ygc gen 的引用,降低 remark 时的开销 ----- 一般 CMS 的 GC 耗时 80% 都在 remark 阶段)为了避免 Perm 区满引起的 full gc,建议开启 CMS 回收 Perm 区选项:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

-XX:+UseConcMarkSweepGC:设置年老代为并发收集。测试中配置这个以后,-XX:NewRatio= 4 的配置失效了,原因不明。所以,此时年轻代大小最好用 -Xmn 设置。-XX:+UseParNewGC: 设置年轻代为并行收集。可与 CMS 收集同时使用。JDK5.0 以上,JVM 会根据系统配置自行设置,所以无需再设置此值。

G1 收集器

收集器组合开关选项

-XX:+UseSerialGC Serial+SerialOld
-XX:+UseParNewGC ParNew+SerialOld
-XX:+UseParallelGC ParallelScavenge+SerialOld 
-XX:+UseConcMarkSweepGC ParNew+CMS+SerialOld  FullGC 算法:单线程的 Mark Sweep Compact(MSC)
-XX:+UseParallelOldGC ParallelScavenge+Parallel Old  FullGC 算法:PS MarkSweep

JVM 参数

垃圾回收参数
-Xnoclassgc 是否对类进行回收
-verbose:class -XX:+TraceClassUnloading 查看类加载和卸载信息

-XX:SurvivorRatio Eden 和其中一个 survivor 的比值
-XX:PretenureSizeThreshold 大对象进入老年代的阈值,Serial 和 ParNew 生效
-XX:MaxTenuringThreshold 晋升老年代的对象年龄,默认 15, CMS 默认是 4
-XX:HandlePromotionFailure 老年代担保
-XX:+UseAdaptiveSizePolicy 动态调整 Java 堆中各个区域大小和进入老年代年龄
-XX:ParallelGCThreads 并行回收的线程数
-XX:MaxGCPauseMillis Parallel Scavenge 参数,设置 GC 的最大停顿时间
-XX:GCTimeRatio  Parallel Scavenge 参数,GC 时间占总时间的比率,默认 99%,即 1% 的 GC 时间
-XX:CMSInitiatingOccupancyFraction,old 区触发 cms 阈值,默认 68%
-XX:+UseCMSCompactAtFullCollection(CMS 完成后是否进行一次碎片整理,停顿时间加长)
-XX:CMSFullGCsBeforeCompaction(执行多少次不进行碎片整理的 FullGC 后进行一次带压缩的)
-XX:+ScavengeBeforeFullGC,在 fullgc 前触发一次 minorGC

垃圾回收统计信息
-XX:+PrintGC 输出 GC 日志
-verbose:gc 等同于上面那个
-XX:+PrintGCDetails 输出 GC 的详细日志

堆大小设置
-Xmx: 最大堆大小
-Xms: 初始堆大小(最小内存值)
-Xmn: 年轻代大小
-XX:NewSize 和 -XX:MaxNewSize 新生代大小
-XX:SurvivorRatio:3 意思是年轻代中 Eden 区与两个 Survivor 区的比值。注意 Survivor 区有两个。如:3,表示 Eden:Survivor=3:2,一个 Survivor 区占整个年轻代的 1 /5
-XX:NewRatio=4: 设置年轻代(包括 Eden 和两个 Survivor 区)与年老代的比值(除去持久代)。设置为 4,则年轻代与年老代所占比值为 1:4,年轻代占整个堆栈的 1 /5
-Xss 栈容量 默认 256k
-XX:PermSize 永久代初始值
-XX:MaxPermSize 永久代最大值

生产环境参数配置(CMS-GC)

Java < 8
    -server
    -Xms<heap size>[g|m|k] -Xmx<heap size>[g|m|k]
    -XX:PermSize=<perm gen size>[g|m|k] -XX:MaxPermSize=<perm gen size>[g|m|k]
    -Xmn<young size>[g|m|k]
    -XX:+DisableExplicitGC
    -XX:SurvivorRatio=<ratio>
    -XX:+UseConcMarkSweepGC 
    -XX:+CMSParallelRemarkEnabled
    -XX:+CMSScavengeBeforeRemark
    -XX:+UseCMSInitiatingOccupancyOnly 
    -XX:CMSInitiatingOccupancyFraction=<percent>
    -XX:+PrintGCDateStamps -verbose:gc -XX:+PrintGCDetails -Xloggc:"<path to log>"
    -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M
    -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path to dump>`date`.hprof
    -Dsun.net.inetaddr.ttl=<TTL in seconds>
    -Djava.rmi.server.hostname=<external IP>
    -Dcom.sun.management.jmxremote.port=<port> 
    -Dcom.sun.management.jmxremote.authenticate=false 
    -Dcom.sun.management.jmxremote.ssl=false

Java >= 8
    -server
    -Xms<heap size>[g|m|k] -Xmx<heap size>[g|m|k]
    -XX:MaxMetaspaceSize=<metaspace size>[g|m|k]
    -Xmn<young size>[g|m|k]
    -XX:+DisableExplicitGC
    -XX:SurvivorRatio=<ratio>
    -XX:+UseConcMarkSweepGC 
    -XX:+CMSParallelRemarkEnabled
    -XX:+CMSScavengeBeforeRemark
    -XX:+UseCMSInitiatingOccupancyOnly
    -XX:CMSInitiatingOccupancyFraction=<percent>
    -XX:+PrintGCDateStamps -verbose:gc -XX:+PrintGCDetails -Xloggc:"<path to log>"
    -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M
    -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path to dump>`date`.hprof
    -Dsun.net.inetaddr.ttl=<TTL in seconds>
    -Djava.rmi.server.hostname=<external IP>
    -Dcom.sun.management.jmxremote.port=<port> 
    -Dcom.sun.management.jmxremote.authenticate=false 
    -Dcom.sun.management.jmxremote.ssl=false

理解 GC 日志

DefNew:Serial 收集器新生代名称 - Tenured - Perm
ParNew:ParNew 收集器新生代名称 - 
PSYoungGen:Parallel Scavenge 收集器新生代名称

JVM 调优

  • GC 的时间足够的小
  • GC 的次数足够的少
  • 发生 Full GC 的周期足够的长

    前两个目前是相悖的,要想 GC 时间小必须要一个更小的堆,要保证 GC 次数足够少,必须保证一个更大的堆,我们只能取其平衡。

(1)针对 JVM 堆的设置,一般可以通过 -Xms -Xmx 限定其最小、最大值,为了防止垃圾收集器在最小、最大之间收缩堆而产生额外的时间,我们通常把最大、最小设置为相同的值

(2)年轻代和年老代将根据默认的比例(1:2)分配堆内存,可以通过调整二者之间的比率 NewRadio 来调整二者之间的大小,也可以针对回收代,比如年轻代,通过 -XX:newSize -XX:MaxNewSize 来设置其绝对大小。同样,为了防止年轻代的堆收缩,我们通常会把 -XX:newSize -XX:MaxNewSize 设置为同样大小。-XX:PermSize,-XX:MaxPermSize 设置为一样防止老年代收缩。
-XX:NewRatio=4: 设置年轻代(包括 Eden 和两个 Survivor 区)与年老代的比值(除去持久代)。设置为 4,则年轻代与年老代所占比值为 1:4,年轻代占整个堆栈的 1 /5
-XX:MaxTenuringThreshold=0:设置垃圾最大年龄。如果设置为 0 的话,则年轻代对象不经过 Survivor 区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在 Survivor 区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概论。

(3)年轻代和年老代设置多大才算合理?这个我问题毫无疑问是没有答案的,否则也就不会有调优。我们观察一下二者大小变化有哪些影响
年轻代老年代设置:整个 JVM 内存大小 = 年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为 64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun 官方推荐年轻代配置为整个堆的 3 /8。

  • 更大的年轻代必然导致更小的年老代,大的年轻代会延长普通 GC 的周期,但会增加每次 GC 的时间;小的年老代会导致更频繁的 Full GC
  • 更小的年轻代必然导致更大年老代,小的年轻代会导致普通 GC 很频繁,但每次的 GC 时间会更短;大的年老代会减少 Full GC 的频率
  • 如何选择应该依赖应用程序对象生命周期的分布情况:如果应用存在大量的临时对象,应该选择更大的年轻代;如果存在相对较多的持久对象,年老代应该适当增大。但很多应用都没有这样明显的特性,在抉择时应该根据以下两点:(A)本着 Full GC 尽量少的原则,让年老代尽量缓存常用对象,JVM 的默认比例 1:2 也是这个道理(B)通过观察应用一段时间,看其他在峰值时年老代会占多少内存,在不影响 Full GC 的前提下,根据实际情况加大年轻代,比如可以把比例控制在 1:1。但应该给年老代至少预留 1 / 3 的增长空间

(4)在配置较好的机器上(比如多核、大内存),可以为年老代选择并行收集算法:-XX:+UseParallelOldGC,默认为 Serial 收集

(5)线程堆栈的设置:每个线程默认会开启 1M 的堆栈,用于存放栈帧、调用参数、局部变量等,对大多数应用而言这个默认值太了,一般 256K 就足用。理论上,在内存不变的情况下,减少每个线程的堆栈,可以产生更多的线程,但这实际上还受限于操作系统。-Xss256k:设置每个线程的堆栈大小。JDK5.0 以后每个线程堆栈大小为 1M,以前每个线程堆栈大小为 256K。更具应用的线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在 3000~5000 左右。

(6)可以通过下面的参数打 Heap Dump 信息

  -XX:HeapDumpPath
  -XX:+PrintGCDetails
  -XX:+PrintGCTimeStamps
  -Xloggc:/usr/aaa/dump/heap_trace.txt
  通过下面参数可以控制 OutOfMemoryError 时打印堆的信息
  -XX:+HeapDumpOnOutOfMemoryError

注:通过分析 dump 文件可以发现,每个 1 小时都会发生一次 Full GC,经过多方求证,只要在 JVM 中开启了 JMX 服务,JMX 将会 1 小时执行一次 Full GC 以清除引用.

性能分析工具

jps

-m 主类的参数 
-l 主类的全名,如果执行的是 jar 包,输出 jar 路径
-v 虚拟机参数

jstat

监视虚拟机运行状态信息,包括类装载、GC、运行期编译(JIT)用于输出 java 程序内存使用情况,包括新生代、老年代、元数据区容量、垃圾回收情况
 jstat -gcutil 52670 2000 5 进程号 2s 输出一次一共 5 次

S0:幸存 1 区当前使用比例
S1:幸存 2 区当前使用比例
E:伊甸园区使用比例
O:老年代使用比例
M:元数据区使用比例
CCS:压缩使用比例
YGC:年轻代垃圾回收次数
YGCT:年轻代垃圾回收消耗时间
FGC:老年代垃圾回收次数
FGCT:老年代垃圾回收消耗时间
GCT:垃圾回收消耗总时间

jmap

jmap:用于生成堆转储快照。一般称为 dump 或 heapdump 文件。jmap -histo 3618
上述命令打印出进程 ID 为 3618 的内存情况,包括有哪些对象,对象的数量。但我们常用的方式是将指定进程的内存 heap 输出到外              部文件,再由专门的 heap 分析工具进行分析, 例如 mat(Memory Analysis Tool),所以我们常用的命令是:jmap -dump:live,format=b,file=heap.hprof 3618
-F 强制生成 dump 快照

jstack

jstack:用户输出虚拟机当前时刻的线程快照,常用于定位因为某些线程问题造成的故障或性能问题。一般称为 threaddump 文件。参数
- F 当正常输出没有响应的时候强制打印栈信息,一般情况不需要使用
- l 长列表. 打印关于锁的附加信息,一般情况不需要使用
-m 如果调用本地方法的话,可打印 c /c++ 的堆栈

jinfo

查看和修改虚拟机参数

可视化工具
JConsole Java 监视与管理控制台
VisualVM 多合一故障处理工具

Java Class 文件类型前缀

Element Type        Encoding
boolean             Z
byte                B
char                C
double              D
float               F
int                 I
long                J
short               S 
class or interface  Lclassname;
[L 代表了相应类型数组嵌套的层数

内存泄漏及解决方法

1. 系统崩溃前的一些现象:

每次垃圾回收的时间越来越长,由之前的 10ms 延长到 50ms 左右,FullGC 的时间也有之前的 0.5s 延长到 4、5s

FullGC 的次数越来越多,最频繁时隔不到 1 分钟就进行一次 FullGC

年老代的内存越来越大并且每次 FullGC 后年老代没有内存被释放

之后系统会无法响应新的请求,逐渐到达 OutOfMemoryError 的临界值。

2. 生成堆的 dump 文件
通过 JMX 的 MBean 生成当前的 Heap 信息,大小为一个 3G(整个堆的大小)的 hprof 文件,如果没有启动 JMX 可以通过 Java 的 jmap 命令来生成该文件。

3. 分析 dump 文件

下面要考虑的是如何打开这个 3G 的堆信息文件,显然一般的 Window 系统没有这么大的内存,必须借助高配置的 Linux。当然我们可以借助 X -Window 把 Linux 上的图形导入到 Window。我们考虑用下面几种工具打开该文件:

1.Visual VM
2.IBM HeapAnalyzer
3.JDK 自带的 Hprof 工具

使用这些工具时为了确保加载速度,建议设置最大内存为 6G。使用后发现,这些工具都无法直观地观察到内存泄漏,Visual VM 虽能观察到对象大小,但看不到调用堆栈;HeapAnalyzer 虽然能看到调用堆栈,却无法正确打开一个 3G 的文件。因此,我们又选用了 Eclipse 专门的静态内存分析工具:Mat。

4. 分析内存泄漏

通过 Mat 我们能清楚地看到,哪些对象被怀疑为内存泄漏,哪些对象占的空间最大及对象的调用关系。针对本案,在 ThreadLocal 中有很多的 JbpmContext 实例,经过调查是 JBPM 的 Context 没有关闭所致。

另,通过 Mat 或 JMX 我们还可以分析线程状态,可以观察到线程被阻塞在哪个对象上,从而判断系统的瓶颈。

5. 回归问题

Q:为什么崩溃前垃圾回收的时间越来越长?

A: 根据内存模型和垃圾回收算法,垃圾回收分两部分:内存标记、清除(复制),标记部分只要内存大小固定,时间是不变的,变的是复制部分,因为每次垃圾回收都有一些回收不掉的内存,所以增加了复制量,导致时间延长。所以,垃圾回收的时间也可以作为判断内存泄漏的依据

Q:为什么 Full GC 的次数越来越多?

A:因此内存的积累,逐渐耗尽了年老代的内存,导致新对象分配没有更多的空间,从而导致频繁的垃圾回收

Q: 为什么年老代占用的内存越来越大?

A: 因为年轻代的内存无法被回收,越来越多地被 Copy 到年老代

调优方法

一切都是为了这一步,调优,在调优之前,我们需要记住下面的原则:

1、多数的 Java 应用不需要在服务器上进行 GC 优化;

2、多数导致 GC 问题的 Java 应用,都不是因为我们参数设置错误,而是代码问题;

3、在应用上线之前,先考虑将机器的 JVM 参数设置到最优(最适合)

4、减少创建对象的数量;

5、减少使用全局变量和大对象;

6、GC 优化是到最后不得已才采用的手段;

7、在实际使用中,分析 GC 情况优化代码比优化 GC 参数要多得多;

GC 优化的目的有两个

1、将转移到老年代的对象数量降低到最小;

2、减少 full GC 的执行时间;

为了达到上面的目的,一般地,你需要做的事情有:

1、减少使用全局变量和大对象;

2、调整新生代的大小到最合适;

3、设置老年代的大小为最合适;

4、选择合适的 GC 收集器


QQ 讨论群组:984370849 706564342 欢迎加入讨论

想要深入学习的同学们可以加入 QQ 群讨论,有全套资源分享,经验探讨,没错,我们等着你,分享互相的故事!

退出移动版