JVM性能调优

最新推荐文章于 2024-03-06 09:27:19 发布

Stream_who

最新推荐文章于 2024-03-06 09:27:19 发布

阅读量210

点赞数

分类专栏： JVM

本文链接：https://blog.csdn.net/stream_who/article/details/101454895

版权

JVM 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

一、原则

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

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

3. 在应用上线之前，先考虑将机器的JVM参数设置到最优（最适合）

4. 减少创建对象的数量

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

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

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

二、目的

1. GC的时间足够的小

2. GC的次数足够的少

3. 发生Full GC的周期足够的长

4. 将转移到老年代的对象数量降低到最小

三、调优方法

1. 一般思路

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

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

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

4）选择合适的GC收集器

2. 常用解决方案

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

2）年轻代和年老代将根据默认的比例（1：2）分配堆内存，可以通过调整二者之间的比率NewRadio来调整二者之间的大小，也可以针对回收代，比如年轻代，通过 -XX:newSize -XX:MaxNewSize来设置其绝对大小。同样，为了防止年轻代的堆收缩，我们通常会把-XX:newSize -XX:MaxNewSize设置为同样大小

3）年轻代和年老代设置多大才算合理？这个我问题毫无疑问是没有答案的，否则也就不会有调优。我们观察一下二者大小变化有哪些影响

	（1）更大的年轻代必然导致更小的年老代，大的年轻代会延长普通GC的周期，但会增加每次GC的时间；小的年老代会导致更频繁的Full GC

	（2）更小的年轻代必然导致更大年老代，小的年轻代会导致普通GC很频繁，但每次的GC时间会更短；大的年老代会减少Full GC的频率

	（3）如何选择应该依赖应用程序对象生命周期的分布情况：如果应用存在大量的临时对象，应该选择更大的年轻代；如果存在相对较多的持久对象，年老代应该适当增大
	
	（4）但很多应用都没有这样明显的特性，在抉择时应该根据以下两点：

		（A）本着Full GC尽量少的原则，让年老代尽量缓存常用对象，JVM的默认比例1：2也是这个道理

		（B）通过观察应用一段时间，看其他在峰值时年老代会占多少内存，在不影响FullGC的前提下，根据实际情况加大年轻代，比如可以把比例控制在1：1。但应该给年老代至少预留1/3的增长空间

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

5）线程堆栈的设置：每个线程默认会开启1M的堆栈，用于存放栈帧、调用参数、局部变量等，对大多数应用而言这个默认值太了，一般256K就足用。理论上，在内存不变的情况下，减少每个线程的堆栈，可以产生更多的线程，但这实际上还受限于操作系统		

6）年轻代大小选择：

	（1）响应时间优先的应用，尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生gc的频率是最小的。同时，也能够减少到达年老代的对象

	（2）吞吐量优先的应用，也尽可能的设置大，因为对响应时间没有要求，垃圾收集可以并行进行，建议适合8CPU以上的应用使用

7）	年老代大小选择

	（1）响应时间优先的应用，年老代一般都是使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间

	（2）最优化的方案，一般需要参考以下数据获得：

		a. 并发垃圾收集信息

		b. 持久代并发收集次数

		c. 传统GC信息

		d. 花在年轻代和年老代回收上的时间比例

3. 代码优化（参考：Java性能调优之代码调优（一） https://blog.csdn.net/why_still_confused/article/details/52622935）

四、调优步骤

1. 监控GC的状态

1）使用各种JVM工具，查看当前日志，分析当前JVM参数设置，并且分析当前堆内存快照和gc日志，根据实际的各区域内存划分和GC执行时间，觉得是否进行优化

2.分析结果，判断是否需要优化

1）如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化；如果GC时间超过1-3秒，或者频繁GC，则必须优化

2）如果满足下面的指标，则一般不需要进行GC

	（1）Minor GC执行时间不到50ms

	（2）Minor GC执行不频繁，约10秒一次

	（3）Full GC执行时间不到1s

	（4）Full GC执行频率不算频繁，不低于10分钟1次

3.调整GC类型和内存分配

1）如果内存分配过大或过小，或者采用的GC收集器比较慢，则应该优先调整这些参数，并且先找1台或几台机器进行beta，然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择

4.不断的分析和调整

1）通过不断的试验和试错，分析并找到最合适的参数

5.全面应用参数

1）如果找到了最合适的参数，则将这些参数应用到所有服务器，并进行后续跟踪

参考网址

注：文章是经过参考其他的文章然后自己整理出来的，有可能是小部分参考，也有可能是大部分参考，但绝对不是直接转载，觉得侵权了我会删，我只是把这个用于自己的笔记，顺便整理下知识的同时，能帮到一部分人。
ps : 有错误的还望各位大佬指正,小弟不胜感激

Stream_who

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
JVM性能调优

一、原则1. 多数的Java应用不需要在服务器上进行GC优化2. 多数导致GC问题的Java应用，都不是因为我们参数设置错误，而是代码问题3. 在应用上线之前，先考虑将机器的JVM参数设置到最优（最适合）4. 减少创建对象的数量5. 减少使用全局变量和大对象6. GC优化是到最后不得已才采用的手段7. 在实际使用中，分析GC情况优化代码比优化GC参数要多得多二、目的...
复制链接

扫一扫