性能文章>HeapDump性能社区专题系列六:手把手教你玩转JVM性能调优>

HeapDump性能社区专题系列六:手把手教你玩转JVM性能调优原创

https://a.perfma.net/img/3110416
9月前
264025

 

程序在上线前的测试或运行中有时会出现一些大大小小的JVM问题,比如cpu load过高、请求延迟、tps降低等,甚至出现内存泄漏(每次垃圾收集使用的时间越来越长,垃圾收集频率越来越高,每次垃圾收集清理掉的垃圾数据越来越少)、内存溢出导致系统崩溃,因此需要对JVM进行调优,使得程序在正常运行的前提下,获得更高的用户体验和运行效率。

 

这次的专题就是手把手教你玩转jvm优化,堆堆汇总了社区的各位jvm大佬们的经验和实战,相信看完这次专题,必能帮助小伙伴们更加了解JVM性能优化!

 

掌握干货才能迅速进阶!

 

JVM故障分析及性能优化系列之一:使用jstack定位线程堆栈信息

在对Java内存泄漏进行分析的时候,需要对jvm运行期间的内存占用、线程执行等情况进行记录的dump文件进行分析,目前常用的主要有thread dump和heap dump,通过对dump文件进行分析才能发现JVM故障的原因。

 

JVM故障分析及性能优化系列之二:jstack生成的Thread Dump日志结构解析

知道了如何使用jstack生成日志文件,接下来就要对Thread Dump日志文件的结构进行分析,一个典型的thread dump文件Thread Dump日志包含五部分。

 

JVM故障分析及性能优化系列之三:jstat命令的使用及VM Thread分析

Jstat是JDK自带的一个轻量级小工具,全称"JavaVirtualMachine statistics monitoringtool”,它位于java的bin目录下主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控包括了对Heapsize和垃圾回收状况的监控。

 

JVM故障分析及性能优化系列之四:jstack生成的Thread Dump日志线程状态

本文主要针对日志文件中 Java EE middleware, third party & custom application Threads 部分线程的状态进行详细的分析。

 

JVM故障分析及性能优化系列之五:常见的Thread Dump日志案例分析

Thread Dump的主要症状是CPU占用率很高,响应很慢、CPU占用率不高,但响应很慢、系统线程状态为 deadlock、系统线程状态为 waiting for monitor entry 或 in Object.wait()、系统线程状态为 waiting on condition、系统线程状态为 blocked。

 

JVM故障分析及性能优化系列之六:JVM Heap Dump(堆转储文件)的生成和MAT的使用

内存泄漏是jvm老生常谈的问题,我们在处理Java内存泄漏问题的时候,我们需要分析JVM堆转储文件来进行定位。

 

JVM故障分析及性能优化系列之七:使用MAT的Histogram和Dominator Tree定位溢出源

使用MAT的Histogram和Dominator Tree两个视图,定位到内存溢出源,才能解决问题!

 

JVM调优实战,性能翻倍提升:

 

线上一次简单的 JVM 调优,性能提升了15%

笔者的项目是一个高 QPS 压力的 web 服务,单机 QPS 一直维持在 1.5K 以上,由于旧机器的”拖累”,配置的堆大小是 8G,其中 young 区是 4G,垃圾回收器用的是 parNew + CMS。这次对项目进行了一次性能优化,其中包括对 JVM 参数的调整,算是进行了一次简单的 JVM 调优,JVM 参数调整之后,服务的整体性能有 15% 左右的提升。

 

一次大量 JVM Native 内存泄露的排查分析(64M 问题)

笔者有一个线上的项目,刚启动完就占用了使用 top 命令查看 RES 占用了超过 1.5G,这明显不合理,经过排查发现绝大部分的内存申请都耗在了 Java_java_util_zip_Inflater_inflateBytes,jar 包本质就是一个 zip 包, 在读取 jar 包文件过程中大量使用了 jni 中的 cpp 代码来处理,这里面大量申请释放了内存。因为读取 jar 包这个 zip 文件导致的内存疯长,笔者直接把原 jar 包解压,然后用 java -cp . AppMain 来启动避免了这个问题。

 

JVM调优1个月,性能提升400倍!怎样做到的?

对于JVM垃圾回收,之前一直都是处于理论阶段,就知道新生代,老年代的晋升关系,这些知识仅够应付面试使用的。前一段时间,线上服务器的FullGC非常频繁,平均一天40多次,而且隔几天就有服务器自动重启了,这表明的服务器的状态已经非常不正常了,得到这么好的机会,当然要主动请求进行调优了。笔者将FullGC从40次/天优化到近10天才触发一次,而且YoungGC的时间也减少了一半以上。

 

彩蛋:

 

我要进大厂之JVM经典面试20问

这次的JVM性能优化从理论到实践,当然不能少了面试,这次这次主要选取了最经典的JVM面试题,小伙伴们赶快来查缺补漏吧!

 

更多问题大家可以在评论区留言,共同切磋!

点赞收藏
分类:标签:
堆堆

【HeapDump性能社区官方小编】各位堆友们,+微信号perfMa,可以联系上堆堆哦~

请先登录,查看2条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

【全网首发】一次想不到的 Bootstrap 类加载器带来的 Native 内存泄露分析

【全网首发】一次想不到的 Bootstrap 类加载器带来的 Native 内存泄露分析

记一次线上RPC超时故障排查及后续GC调优思路

记一次线上RPC超时故障排查及后续GC调优思路

解读JVM级别本地缓存Caffeine青出于蓝的要诀 —— 缘何会更强、如何去上手

解读JVM级别本地缓存Caffeine青出于蓝的要诀 —— 缘何会更强、如何去上手

【全网首发】一次疑似 JVM Native 内存泄露的问题分析

【全网首发】一次疑似 JVM Native 内存泄露的问题分析

解读JVM级别本地缓存Caffeine青出于蓝的要诀2 —— 弄清楚Caffeine的同步、异步回源方式

解读JVM级别本地缓存Caffeine青出于蓝的要诀2 —— 弄清楚Caffeine的同步、异步回源方式

【全网首发】从源码角度分析一次诡异的类被加载问题

【全网首发】从源码角度分析一次诡异的类被加载问题

5
2