3.8 Jvm调优与故障处理，可以自己手动实现以下；

最新推荐文章于 2024-03-21 14:32:53 发布

向上吧，少年！

最新推荐文章于 2024-03-21 14:32:53 发布

阅读量150

点赞数

分类专栏：日积跬步

本文链接：https://blog.csdn.net/m0_38045306/article/details/115533038

版权

日积跬步专栏收录该内容

113 篇文章 2 订阅

订阅专栏

JVM调优

调优可以依赖、参考的数据有系统运行日志、堆栈错误信息、gc日志、线程快照、堆转储快照等。

堆栈错误信息：当系统出现异常后，可以根据堆栈信息初步定位问题所在，比如根据“java.lang.OutOfMemoryError: Java heap space”可以判断是堆内存溢出；根据“java.lang.StackOverflowError”可以判断是栈溢出；根据“java.lang.OutOfMemoryError: PermGen space”可以判断是方法区溢出等。

GC日志

未完。。。

需要学习别人博客中写的jvm调优案例

https://www.cnblogs.com/Lxiaojiang/p/6707539.html
堆参数-XMS 与-XMX的说明
XMS : JVM初始分配的堆内存

XMX : JVM最大允许分配的堆内存，按需分配

堆内存分配:

JVM初始分配的堆内存由-Xms指定，默认是物理内存的1/64；

JVM最大分配的堆内存由-Xmx指定，默认是物理内存的1/4。

默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；

空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。

因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。

说明：如果-Xmx 不指定或者指定偏小，应用可能会导致java.lang.OutOfMemory错误，此错误来自JVM，不是Throwable的，无法用try...catch捕捉。

https://blog.csdn.net/SpringMBCM/article/details/106795246

-Xms 5000m
-Xms 代表设置初始化的内存大小为 5000m
1
-Xmx 5000m
设置最大内存大小为 5000m
1
-Xmn 2G
设置年轻代大小为 2G
1
-Xss 128k
设置每个线程所分配的栈堆内存大小为128k 大小

https://blog.csdn.net/a1439775520/article/details/97787160

类似-Xms、-Xmn这些参数的含义：

答：
堆内存分配：
JVM初始分配的内存由-Xms指定，默认是物理内存的1/64
JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4
默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制。
因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。对象的堆内存由称为垃圾回收器的自动内存管理系统回收。
非堆内存分配：
JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；
由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。
-Xmn2G：设置年轻代大小为2G。
-XX:SurvivorRatio，设置年轻代中Eden区与Survivor区的比值。

https://www.cnblogs.com/likehua/p/3369823.html

-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:设置持久代大小为16m。
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

https://www.cnblogs.com/xujanus/p/11551013.html

有图片有图片

记录一次JVM配置优化的案例
上周公司有一个应用，一到晚上高峰期的时候RT（响应时间）就很长。
后来上服务器看了下JVM的配置，发现运维在启动参数那里把-Xss给设成了10M。导致每个线程占用的内存过大，导致内存消耗过快，其它线程排队等待的情况。
后来把-Xss改成1M之后，系统性能有明显的提高。

总结：

1.-Xss参数不可以设的过大，特别在一些高并发场景的系统下。（低并发的话，没关系）
2.JVM的参数不要任由运维去配。运维使用的参数可能不符合当前系统的业务场景。还需要开发人员去优化

http://blog.jmecn.net/a-jvm-case-i-learned/

一个JVM内存调优案例

半年前一时兴起，跟风开发过一个贪吃蛇小游戏。只做了单机版，随后就失去了兴趣。

项目地址：https://github.com/jmecn/Snake

这个项目在运行时，内存占用量非常大。起步就有100MB，随着运行时间增加，内存消耗越来越大。5分钟后差不多就消耗了1GB内存。

我猜测问题是由于Zay-ES工作时创建了大量的对象实例导致的。GC回收不及时，导致这些对象一直保留在堆内存中。因为这个原因，我认为Zay-ES框架有内存泄露（Memory Leak），最终因此放弃了这个项目。

学习JVM的工作方式之后，我才明白这不是Zay-ES的错。是我没有设置好JVM的堆内存，所以出现了这个结果。

祭出Visual VM，查看对内存的使用情况。

蓝色线：已使用内存(Used Memory)
黄色线：堆大小（Heap Space）

从上图中可以发现，这个程序运行时所需的最低内存大概只有20MB左右。由于没有设置堆的大小，JVM认为可以使用尽量多的内存（1GB），因此GC的执行频率很低。只有在已使用内存接近堆内存上限时，才执行一次GC，并扩大堆内存的上限。

上图中，已使用的内存峰值接近250MB，我决定将JVM堆的容量设置为256MB，看看结果会有什么不同。

-Xms256m -Xmx256m

GC的频率明显变高了，而且实际使用的内存只有不到128MB！这已经说明Zay-ES其实并没有内存泄露。

再度调整堆的大小，改为启动内存32MB，最大内存128MB。

-Xms32m -Xmx128m

这一次运行，GC的回收频率更高了，已使用内存的大小也更加稳定。

不过这个设置的GC频率太高，而且中途还有一次full gc，程序卡顿非常明显，游戏感受不太舒服。

于是我把启动内存提高到64MB，最大内存依然控制在128MB。

-Xms64m -Xmx128m

这次运行流畅多了，而且内存消耗也在接受范围内。

https://blog.csdn.net/jingshuaizh/article/details/49588813

JVM 调优案例分析1

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

1.jvmstat
jvmstat是图形版的jstat，由Java 官方提供，目前最新版本为3.0。

下载地址：http://www.oracle.com/technetwork/java/jvmstat-142257.html

Jstat是JDK自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”。
中文名：java虚拟机统计信息工具外文名jstat

Jstat位于java的bin目录下，主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。
Jstat可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量。
jstat -class pid:显示加载class的数量，及所占空间等信息。
jstat -compiler pid:显示VM实时编译的数量等信息。
jstat -gc pid:可以显示gc的信息，查看gc的次数，及时间。其中最后五项，分别是young gc的次数，young gc的时间，full gc的次数，full gc的时间，gc的总时间。
=================================================