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

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

https://a.perfma.net/img/3110416
1月前
202824

 

程序在上线前的测试或运行中有时会出现一些大大小小的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面试题,小伙伴们赶快来查缺补漏吧!

 

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

分类:
标签:
请先登录,再评论

👍

1月前

收藏!

11月前

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得