Java性能优化权威指南--笔记

-XX:+PrintGCTimeStamps	打印此次垃圾回收距离jvm开始运行的所耗时间
-XX:+PrintGCDetails	打印垃圾回收的细节信息
-Xloggc:<filename>	将垃圾回收信息输出到指定文件
-XX:+PrintGCDateStamps	需要打印日历形式的时间戳选项
-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime	打印应用程序由于执行VM安全点操作而阻塞的时间以及两个安全点操作之间应用程序的运行时间
-XX:+PrintSafepointStatistics	可以将垃圾回收的安全点与其他的安全点区分开

Java性能优化权威指南-读书笔记（三）-JVM性能调优-内存占用

新生代、老年代、永久代的概念不多说，这三个空间中任何一个不能满足内存分配请求时，就会发生垃圾收集。

新生代不满足内存分配请求时，发生Minor GC，老年代、永久代不满足内存分配请求时，发生Full GC，Minor GC比Full GC持续的时间要短很多。

所以内存空间设置的不合理就会频繁引起垃圾收集，以及OutOfMemoryError错误，严重影响程序性能。

Java堆大小计算法则

若你的应用部署在单独的服务器，且该服务器上只有这一个应用，那Java堆肯定是越大越好，但这种情况比较少。

Java堆大小可以参考下面这个表格：

空间	命令行选项	占用倍数
Java堆	-Xms:最小堆大小 -Xmx:最大堆大小	3~4倍Full GC后老年代空间占用
永久代	-XX:PermSize -XX:MaxPerSize	1.2~1.5倍Full GC后永久代空间占用
新生代	-Xmn	1~1.5倍Full GC后老年代空间占用
老年代	Java堆大小 - 新生代大小	2~3倍Full GC后老年代空间占用

其中这些空间占用，都是指应用程序在稳定状态（指应用运行了一段时间）下，Full GC后Java堆占用的空间大小，即活跃数据的大小。

参照下面这个GC日志：

12.251:

[Full GC

[PSYoungGen: 15945K->0K(278528K)]

[ParOldGen: 30724K->29331K(67072K)] 46670K->29331K(345600K),

[PSPermGen: 34785K->34774K(1081344K)], 0.1022337 secs]

[Times: user=0.20 sys=0.00, real=0.10 secs]

1). Java堆大小：29331K（约30M） * （3~4），即90M~120M

2). 永久代大小：34774K（约34M）* （1.2~1.5），即41M~51M

3). 新生代大小：29331K（约30M） * （1~1.5），即30M~45M

4). 老年代大小：(90M~120M) – (30M~45M)，即60M~75M

这个计算法则，只是起到指导性的意见，实际操作中，还是需要根据实际情况来应变。

在调整后面两项“延迟、吞吐量”时，这些堆的大小还需要进一步的调整。

Java性能优化权威指南-读书笔记（四）-JVM性能调优-延迟

延迟指服务器处理一个请求所花费的时间，单位一般是ms、s。

本文主要讲降低延迟可以做的服务器端JVM优化。

JVM延迟优化

新生代

新生代大小决定了应用平均延迟

如果平均Minor GC持续时间大于应用程序平均延迟性要求，可以适当减小新生代空间大小；

如果Minor GC频率大于应用程序平均延迟性要求，可以适当增大新生代空间；

老年代

老年代大小决定了应用最差延迟

FullGC频率大于应用程序最大FullGC频率要求，可以适当增大老年代空间大小；

FullGC持续时间大于应用程序最差延迟性要求，可以使用CMS垃圾收集器；

CMS收集器调优

CMS主要特性

CMS为老年代收集器，收集线程能与应用程序线程实现最大的并行度，降低了延迟。

CMS并不进行压缩，所以老年代使用空闲列表分配内存，在一定程度上增加了新生代晋升老年代时，耗费的时间。

但一旦老年代溢出就会触发Stop-The-World压缩式垃圾收集。

所以，CMS的优化大概有下面几点：

1. 避免用尽老年代空间；

2. 解决老年代碎片化问题，解决方法包括压缩、MinorGC回收原则；

3. 降低初始标记阶段和重新标记阶段占用的时间，因为这两个阶段应用程序线程会被阻塞；

Survivor空间调优

调整Survivor空间，是为了让其有足够空间容纳存活对象足够长的时间，直到几个周期后对象老化，解决上面的第一、二条问题。

Survivor空间的大小可以通过下面这个参数调整：

-XX:SurvivorRatio=<ratio>

<ratio>必须大于0，-XX:SurvivorRatio=<ratio>表示单个Survivor和Eden的比率。

survivor空间大小 = –Xmn/(-XX:SurvivorRatio=<ratio> + 2)

监控晋升阈值

-XX:MaxTenuringThreshold=n //设置最大晋升阈值

-XX:+PrintTenuringDistribution //打印晋升的分布或对象年龄分布到GC日志

如下面这个晋升日志：

Desired survivor size 1114112 bytes, new threshold 1 (max 6)

- age 1: 2213864 bytes, 2213864 total

Desired survivor size 1114112 bytes是Survivor空间大小 * 目标存活率（可以设定，默认50%）

new threshold 1 JVM内部计算出的晋升阈值 (max 6)设置的晋升阈值

age 1（对象年龄代） 2213864 bytes（这个年龄对象总大小）, 2213864 total（所有年龄对象总大小）

Survivor目标存活率:指Minor GC后Survivor空间占用比率，如果太大，下次Minor GC后存活的对象就有可能放不下

从这个日志可以看出，存活对象2213864bytes大于期望Survivor大小为1124112bytes，所以对象年龄为1时，就提升到了老年代。

解决这个问题的方法就是增大Survivor空间，存活对象大小 / 目标存活率 = Survivor空间大小，本例中大概4.5M，所以修改JVM参数为：

01	`-Xmx512m -Xms512m -Xmn50m -XX:SurvivorRatio=5`

调整后的晋升日志大概如下，这个已不是上面那个应用了，所以Survivor空间不一样，能说明问题就行：

Desired survivor size 87359488 bytes, new threshold 15 (max 15)

- age 1: 20701528 bytes, 20701528 total

- age 2: 4924656 bytes, 25626184 total

- age 3: 3261000 bytes, 28887184 total

- age 4: 7941120 bytes, 36828304 total

调整Survivor空间的一个重要原则：

调整Survivor空间时，应保持Eden空间不变，否则会导致Minor GC频率变小。

初始化CMS收集周期

CMS中发生的Stop-The-World压缩式垃圾收集可以在GC日志中查找并发模式失效（concurrent mode failure）定位。

如果有这个问题，就需要调整CMS收集周期。

-XX:CMSInitiatingOccupancyFraction=<percent> //设置CMS垃圾收集周期在老年代空间占用达到多少是启动

-XX:+UseCMSInitiatingOccupancyOnly //告知JVM总是使用 CMSInitiatingOccupancyFraction比率启动CMS，否则只是在CMS第一次启动时

原则：CMSInitiatingOccupancyFraction设置的比率至少是老年代活跃数据的1.5倍

如果老年代空间消耗的比较慢，可以稍晚启动CMS，即将CMSInitiatingOccupancyFraction设定的更大；

如果老年代空间消耗的很快，可以将CMSInitiatingOccupancyFraction设定的更小，但不能低于活跃数据占用的比率；

降低CMS重新标记阶段占用时间

-XX:ParallelGCThreads //控制重新标记的线程数，建议将CMS的收集线程数设置的小于默认值，否则大量GC线程会影响应用性能

-XX:+CMSScavengeBeforeRemark //在CMS进入重新标记阶段先进行一次Minor GC，可以减少引用老年代的新生代对象数量，降低重新标记阶段的工作量

-XX:+ParallelRefProcEnabled //使用多线程处理引用，不过在JDK6u25和6u26上有BUG

Java性能优化权威指南-读书笔记（五）-JVM性能调优-吞吐量

吞吐量是指，应用程序的TPS: 每秒多少次事务，QPS: 每秒多少次查询等性能指标。

吞吐量调优就是减少垃圾收集器消耗的CPU周期数，从而将更多的CPU周期用于执行应用程序。

CMS吞吐调优

CMS包括Minor GC所带来的开销应该小于10%，如果垃圾收集的开销在3%或更少，说明通过调优吞吐量，提升性能的空间就极其有限了。

可用的调优方法如下：

1. 增大新生代空间，以降低Minor GC频率，减少CPU周期占用；

2. 增加老年代空间，以降低CMS频率，并可以减少老年代内存碎片；

3. 优化CMS周期的启动条件，尽可能在较晚的时候进行；

总的来说，就是减少垃圾收集占用的CPU周期。

ParallelGC吞吐调优

这里说的ParallelGC是指开启了下面两个JVM参数

-XX:+UseParallelGC
-XX:+UseParallelOldGC

对ParallelGC调优的目标是尽可能避免发生Full GC，这就需要优化对象老化频率，可以调整Survivor空间实现对对象老化的优化。

使用ParallelGC时，垃圾收集的开销应小于5%，如果已经减少到1%甚至更少，那基本上就已经达到了极限。

Survivor调优

ParallelGC默认可以自动调整Survivor空间，大部分应用用自动调整已经可以，对要求比较高的应用就需要关闭自动调整，进行手动调整。

为JVM添加下面两个参数，只针对ParallelGC有用：

-XX:-UseAdaptiveSizePolicy //关闭自适应调整

-XX:+PrintAdaptiveSizePolicy //打印详细Survivor空间占用日志

如下面日志：

2016-12-11T16:44:03.653+0800: 5.042: [GC (Allocation Failure) AdaptiveSizePolicy::update_averages:

survived: 10464720

promoted: 1096456

overflow: true

survived:“TO”Survivor空间占用大小；

promoted: 新生代提升至老年代的对象大小；

overflow：是否有Survivor空间的对象溢出到老年代；

从上面的日志可以看出，Minor GC后新生代存活对象大小10M，因为没有设置-XX:TargetSurvivorRatio，默认Survivor空间占用比率为50%，

所以Survivor空间应为20M。

找到稳定态下Full GC之间所有Minor GC中最大的存活对象大小，然后就可以调整Survivor空间大小。

原JVM参数如下：

01	`-Xmx1024m –Xms1024m –Xmn50m -XX:SurvivorRatio=3`

可以计算出：原Survivor空间：10M，原Eden空间：30M

现在增大Survivor空间到20M

保证Eden空间不变，则新生代大小为70M；

70M / （SurvivorRatio + 2）=20M，所以SurvivorRatio=1.5

保证老年代空间不变，则Java堆大小调整为1044M

所以最后JVM参数为：

01	`-Xmx1044m -Xms1044m -Xmn70m -XX:SurvivorRatio=1.5`

如果Java堆大小已经不能再增大，可以计算下Minor GC后，存活对象的最小值、最大值、平均值，如果不存在大幅波动，

可以尝试提高Survivor空间的占用百分比-XX:TargetSurvivorRatio=<n>，其默认为50%。

并行线程调优

-XX:ParallelGCThreads

并行垃圾收集器的线程数，建议收集线程数设置的小于默认值，否则大量GC线程会影响应用性能

其他性能命令行选项

-XX:+AggressiveOpts	自动优化，但有可能不太稳定
-XX:+DoEscapeAnalysis	逃逸分析
-XX:+UseBiasedLocking	偏向锁
-XX:+UseLargePages	大页面支持

kinbridge

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Java性能优化权威指南--笔记

一：CPU1. 用户态CPU是指执行应用程序代码的时间占总CPU时间的百分比。系统态CPU是指应用执行操作系统调用的时间占总CPU时间的百分比。系统态CPU高意味着共享资源有竞争或者I/O设备之间有大量的交互。提高应用性能和扩展性的一个目标就是尽可能降低系统态CPU使用率。2. CPU运行队列就是那些已经准备好运行、正等待可用CPU的轻量级进程。当运行队列长度达到处理器的4倍或者更多时，系统的相应就非常迟缓了。解决运行队列长有两种办法：1). 增加CPU以分担负载；2). 分
复制链接

扫一扫