【JVM进阶之路】十：JVM调优总结，初级java工程师面试题库及答案

最新推荐文章于 2024-07-25 21:32:40 发布

2401_84437833

最新推荐文章于 2024-07-25 21:32:40 发布

阅读量776

点赞数 11

分类专栏： 2024年程序员学习文章标签： jvm java 面试

本文链接：https://blog.csdn.net/2401_84437833/article/details/138023751

版权

2024年程序员学习专栏收录该内容

16 篇文章 0 订阅

订阅专栏

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

正文

一般情况下，JVM调优可通过以下步骤进行：

分析系统系统运行情况：分析GC日志及dump文件，判断是否需要优化，确定瓶颈问题点；
确定JVM调优量化目标；
确定JVM调优参数（根据历史JVM参数来调整）；
依次确定调优内存、延迟、吞吐量等指标；
对比观察调优前后的差异；
不断的分析和调整，直到找到合适的JVM参数配置；
找到最合适的参数，将这些参数应用到所有服务器，并进行后续跟踪。

以上操作步骤中，某些步骤是需要多次不断迭代完成的。一般是从满足程序的内存使用需求开始的，之后是时间延迟的要求，最后才是吞吐量的要求，要基于这个步骤来不断优化，每一个步骤都是进行下一步的基础，不可逆行。

JVM调优步骤

5、JVM参数

=========================================================================

下面来看一下JDK的JVM参数。

5.1、基本参数

| 参数名称 | 含义 | 默认值 | |

| — | — | — | — |

| -Xms | 初始堆大小 | 内存的1/64 | 默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制. |

| -Xmx | 最大堆大小 | 内存的1/4 | 默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制 |

| -Xmn | 年轻代大小 | | 注意：此处的大小是（eden+ 2 survivor space).与jmap -heap中显示的New gen是不同的。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小. 增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8 |

| -Xss | 每个线程的堆栈大小 | | JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K.更具应用的线程所需内存大小进行调整.在相同物理内存下,减小这个值能生成更多的线程.但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右一般小的应用，如果栈不是很深，应该是128k够用的大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。（校长）和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:"” -Xss is translated in a VM flag named ThreadStackSize” 一般设置这个值就可以了。 |

| -XX:ThreadStackSize | Thread Stack Size | | (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.] |

| -XX:NewRatio | 年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代) | | -XX:NewRatio=4表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5 Xms=Xmx并且设置了Xmn的情况下，该参数不需要进行设置。 |

| -XX:+ExplicitGCInvokesConcurrent | 关闭System.gc() | disabled | Enables invoking of concurrent GC by using the System.gc() request. This option is disabled by default and can be enabled only together with the -XX:+UseConcMarkSweepGC option. |

| -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses | 关闭System.gc() | disabled | Enables invoking of concurrent GC by using the System.gc() request and unloading of classes during the concurrent GC cycle. This option is disabled by default and can be enabled only together with the -XX:+UseConcMarkSweepGC option. |

| -XX:MaxTenuringThreshold | 垃圾最大年龄 | | 如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代. 对于年老代比较多的应用,可以提高效率.如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概率该参数只有在串行GC时才有效. |

| -XX:SoftRefLRUPolicyMSPerMB | 每兆堆空闲空间中SoftReference的存活时间 | 1s | softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap |

Jdk7版本的主要参数

| 参数名称 | 含义 | 默认值 | |

| — | — | — | — |

Jdk8版本的重要特有参数

| 参数名称 | 含义 | 默认值 | |

| — | — | — | — |

5.2、并行收集器相关参数

| 参数名称 | 含义 | 默认值 | |

| — | — | — | — |

| -XX:+UseAdaptiveSizePolicy | 自动选择年轻代区大小和相应的Survivor区比例 | | 设置此选项后,并行收集器会自动选择年轻代区大小和相应的Survivor区比例,以达到目标系统规定的最低相应时间或者收集频率等,此值建议使用并行收集器时,一直打开. |

5.3、CMS相关参数

| 参数名称 | 含义 | 默认值 | |

| — | — | — | — |

| -XX:+AggressiveHeap | | | 试图是使用大量的物理内存长时间大内存使用的优化，能检查计算资源（内存，处理器数量）至少需要256MB内存大量的CPU／内存，（在1.4.1在4CPU的机器上已经显示有提升） |

| -XX+UseCMSCompactAtFullCollection | 在FULL GC的时候，对年老代的压缩 | | CMS是不会移动内存的，因此，这个非常容易产生碎片，导致内存不够用，因此，内存的压缩这个时候就会被启用。增加这个参数是个好习惯。可能会影响性能,但是可以消除碎片 |

5.4、辅助信息

| 参数名称 | 含义 | 默认值 | |

| — | — | — | — |

| -XX:+PrintGC | | | 输出形式: [GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs] |

| -XX:+PrintGCDetails | | | 输出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs] |

| -XX:+PrintGC:PrintGCTimeStamps | | | 可与-XX:+PrintGC -XX:+PrintGCDetails混合使用输出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs] |

| -XX:+PrintGCApplicationStoppedTime | 打印垃圾回收期间程序暂停的时间.可与上面混合使用 | | 输出形式:Total time for which application threads were stopped: 0.0468229 seconds |

| XX:+PrintTenuringDistribution | 查看每次minor GC后新的存活周期的阈值 | | Desired survivor size 1048576 bytes, new threshold 7 (max 15) new threshold 7即标识新的存活周期的阈值为7。 |

6、主要工具

========================================================================

6.1、JDK工具

JDK自带了很多性能监控工具，我们可以用这些工具来监测系统和排查内存性能问题。

JDK自带工具

6.2、Linux 命令行工具

进行性能监控和问题排查的时候，常常是结合操作系统本身的命令行工具来进行。

| 命令 | 说明 |

| — | — |

| top | 实时显示正在执行进程的 CPU 使用率、内存使用率以及系统负载等信息 |

| vmstat | 对操作系统的虚拟内存、进程、CPU活动进行监控 |

| pidstat | 监控指定进程的上下文切换 |

| iostat | 监控磁盘IO |

其它还有一些第三方的监控工具，同样是性能分析和故障排查的利器，如MAT、GChisto、JProfiler、arthas。

7、常用调优策略

==========================================================================

这里还是要提一下，及时确定要进行JVM调优，也不要陷入“知见障”，进行分析之后，发现可以通过优化程序提升性能，仍然首选优化程序。

7.1、选择合适的垃圾回收器

CPU单核，那么毫无疑问Serial 垃圾收集器是你唯一的选择。

CPU多核，关注吞吐量，那么选择PS+PO组合。

CPU多核，关注用户停顿时间，JDK版本1.6或者1.7，那么选择CMS。

CPU多核，关注用户停顿时间，JDK1.8及以上，JVM可用内存6G以上，那么选择G1。

参数配置：

//设置Serial垃圾收集器（新生代）

开启：-XX:+UseSerialGC

//设置PS+PO,新生代使用功能Parallel Scavenge 老年代将会使用Parallel Old收集器

开启 -XX:+UseParallelOldGC

//CMS垃圾收集器（老年代）

开启 -XX:+UseConcMarkSweepGC

//设置G1垃圾收集器

开启 -XX:+UseG1GC

7.2、调整内存大小

现象：垃圾收集频率非常频繁。

原因：如果内存太小，就会导致频繁的需要进行垃圾收集才能释放出足够的空间来创建新的对象，所以增加堆内存大小的效果是非常显而易见的。

注意：如果垃圾收集次数非常频繁，但是每次能回收的对象非常少，那么这个时候并非内存太小，而可能是内存泄露导致对象无法回收，从而造成频繁GC。

参数配置：

//设置堆初始值

指令1：-Xms2g

指令2：-XX:InitialHeapSize=2048m

//设置堆区最大值

指令1：-Xmx2g

指令2： -XX:MaxHeapSize=2048m

//新生代内存配置

指令1：-Xmn512m

指令2：-XX:MaxNewSize=512m

7.3、设置符合预期的停顿时间

现象：程序间接性的卡顿

原因：如果没有确切的停顿时间设定，垃圾收集器以吞吐量为主，那么垃圾收集时间就会不稳定。

注意：不要设置不切实际的停顿时间，单次时间越短也意味着需要更多的GC次数才能回收完原有数量的垃圾.

参数配置：

//GC停顿时间，垃圾收集器会尝试用各种手段达到这个时间

-XX:MaxGCPauseMillis

7.4、调整内存区域大小比率

现象：某一个区域的GC频繁，其他都正常。

原因：如果对应区域空间不足，导致需要频繁GC来释放空间，在JVM堆内存无法增加的情况下，可以调整对应区域的大小比率。

注意：也许并非空间不足，而是因为内存泄造成内存无法回收。从而导致GC频繁。

参数配置：

//survivor区和Eden区大小比率

指令：-XX:SurvivorRatio=6 //S区和Eden区占新生代比率为1:6,两个S区2:6

//新生代和老年代的占比

-XX:NewRatio=4 //表示新生代:老年代 = 1:4 即老年代占整个堆的4/5；默认值=2

7.5、调整对象升老年代的年龄

现象：老年代频繁GC，每次回收的对象很多。

原因：如果升代年龄小，新生代的对象很快就进入老年代了，导致老年代对象变多，而这些对象其实在随后的很短时间内就可以回收，这时候可以调整对象的升级代年龄，让对象不那么容易进入老年代解决老年代空间不足频繁GC问题。

注意：增加了年龄之后，这些对象在新生代的时间会变长可能导致新生代的GC频率增加，并且频繁复制这些对象新生的GC时间也可能变长。

配置参数：

//进入老年代最小的GC年龄,年轻代对象转换为老年代对象最小年龄值，默认值7

-XX:InitialTenuringThreshol=7

7.6、调整大对象的标准

现象：老年代频繁GC，每次回收的对象很多,而且单个对象的体积都比较大。

原因：如果大量的大对象直接分配到老年代，导致老年代容易被填满而造成频繁GC，可设置对象直接进入老年代的标准。

注意：这些大对象进入新生代后可能会使新生代的GC频率和时间增加。

配置参数：

//新生代可容纳的最大对象,大于则直接会分配到老年代，0代表没有限制。

-XX:PretenureSizeThreshold=1000000

7.7、调整GC的触发时机

现象：CMS，G1 经常 Full GC，程序卡顿严重。

原因：G1和CMS 部分GC阶段是并发进行的，业务线程和垃圾收集线程一起工作，也就说明垃圾收集的过程中业务线程会生成新的对象，所以在GC的时候需要预留一部分内存空间来容纳新产生的对象，如果这个时候内存空间不足以容纳新产生的对象，那么JVM就会停止并发收集暂停所有业务线程（STW）来保证垃圾收集的正常运行。这个时候可以调整GC触发的时机（比如在老年代占用60%就触发GC），这样就可以预留足够的空间来让业务线程创建的对象有足够的空间分配。

注意：提早触发GC会增加老年代GC的频率。

配置参数：

//使用多少比例的老年代后开始CMS收集，默认是68%，如果频繁发生SerialOld卡顿，应该调小

-XX:CMSInitiatingOccupancyFraction

//G1混合垃圾回收周期中要包括的旧区域设置占用率阈值。默认占用率为 65%

-XX:G1MixedGCLiveThresholdPercent=65

7.8、调整 JVM本地内存大小

现象：GC的次数、时间和回收的对象都正常，堆内存空间充足，但是报OOM

原因： JVM除了堆内存之外还有一块堆外内存，这片内存也叫本地内存，可是这块内存区域不足了并不会主动触发GC，只有在堆内存区域触发的时候顺带会把本地内存回收了，而一旦本地内存分配不足就会直接报OOM异常。

注意：本地内存异常的时候除了上面的现象之外，异常信息可能是OutOfMemoryError：Direct buffer memory。解决方式除了调整本地内存大小之外，也可以在出现此异常时进行捕获，手动触发GC（System.gc()）。

配置参数：

XX:MaxDirectMemorySize

8、JVM调优实例

===========================================================================

以下是整理自网络的一些JVM调优实例：

8.1、网站流量浏览量暴增后，网站反应页面响很慢

1、问题推测：在测试环境测速度比较快，但是一到生产就变慢，所以推测可能是因为垃圾收集导致的业务线程停顿。

2、定位：为了确认推测的正确性，在线上通过jstat -gc 指令看到JVM进行GC 次数频率非常高，GC所占用的时间非常长，所以基本推断就是因为GC频率非常高，所以导致业务线程经常停顿，从而造成网页反应很慢。

3、解决方案：因为网页访问量很高，所以对象创建速度非常快，导致堆内存容易填满从而频繁GC，所以这里问题在于新生代内存太小，所以这里可以增加JVM内存就行了，所以初步从原来的2G内存增加到16G内存。

最后

面试是跳槽涨薪最直接有效的方式，马上金九银十来了，各位做好面试造飞机，工作拧螺丝的准备了吗？

掌握了这些知识点，面试时在候选人中又可以夺目不少，暴击9999点。机会都是留给有准备的人，只有充足的准备，才可能让自己可以在候选人中脱颖而出。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

看到JVM进行GC 次数频率非常高，GC所占用的时间非常长，所以基本推断就是因为GC频率非常高，所以导致业务线程经常停顿，从而造成网页反应很慢。

最后

面试是跳槽涨薪最直接有效的方式，马上金九银十来了，各位做好面试造飞机，工作拧螺丝的准备了吗？

[外链图片转存中…(img-1mHYLqjM-1713663589093)]

[外链图片转存中…(img-qkd8GcYV-1713663589094)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-hmpvURn6-1713663589094)]

2401_84437833

关注

11
点赞
踩
15

收藏

觉得还不错? 一键收藏
0
评论
【JVM进阶之路】十：JVM调优总结，初级java工程师面试题库及答案

面试是跳槽涨薪最直接有效的方式，马上金九银十来了，各位做好面试造飞机，工作拧螺丝的准备了吗？掌握了这些知识点，面试时在候选人中又可以夺目不少，暴击9999点。机会都是留给有准备的人，只有充足的准备，才可能让自己可以在候选人中脱颖而出。网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）一个人可以走的很快，但一群人才能走的更远！
复制链接

扫一扫