性能文章>不起眼,但是足以让你收获的JVM内存案例>

不起眼,但是足以让你收获的JVM内存案例原创

2年前
815418

今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,我对奇怪现象一直充满好奇,所以你碰到些奇怪的问题也可以发给我,当然最好是JVM相关的

问题

因为编辑比较麻烦,直接以截图的方式发出来吧
image.png
image.png
image.png
另外附上测试源码:
image.png
这个问题描述其实还挺详细的,另外还附上了测试代码,我比较喜欢这种提问题的方式,可以简单模拟出问题来,这样也比较好分析,问题简化是很重要的一步,这样能节省很多时间,有些现象甚至都不用描述太多,很快就能抓住点

分析

简化程序

这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事,于是我不断简化他的代码,最终发现int[]对象的多少和线程run方法里的最后一个byte数组的创建有一定关系。

初步疑点

我觉得不应该啊,byte数组在内存里明明就是byte数组,和int数组也没半毛钱关系呀,当时突然灵光一闪,这估计是因为jmx通信导致的吧,因为jvisualvm和目标进程通信,传递一些数据也挺正常,因为当时比较忙,于是就回复他了,也许是jmx导致的,要它不要使用visualvm看了,jmx端口也关了,可以通过jmap -histo来确认下。

再次怀疑

今天突然又收到了该同学的邮件了,他也注意到了和那个byte数组有一定关系
image.png
image.png
同时他还发现个现象,也就是我要他确认的方式,发现jmap -histo执行的时候,int数组还是比较多,但是加了live参数之后,降下去了,降下去这个比较好解释,因为live参数会做一次fgc的动作,把某些死对象给回收掉了

再次分析

我于是拿它的demo又跑了跑,按照下面的步骤进行操作

  • 执行jmap -histo,发现int数组比较多
  • 再执行jmap -histo:live,发现int数组降下去了
  • 继续执行jmap -histo,int数组又多了点

执行到这里,我就开始怀疑jmap了,难道是因为jmap导致的?于是我开始check jmap的实现,包括JDK和JVM里的逻辑,我要找到哪里可能会创建int数组,JDK层面基本可以忽略,因为实在想不到会有啥逻辑可能会有int数组产生,只是发了个命令给JVM进程而已,于是我重点分析JVM层面的实现,当我们使用jmap做了一次dump的时候或者gc发生的时候都会走到下面的逻辑
image.png
因为GC或者内存dump,都必须对内存做一个遍历,因此必须先暂停这些Java线程,防止在遍历内存里的对象的时候进行内存分配,但是每个线程分配内存其实都是优先走tlab(每个线程独有的一块在eden里的小内存块)的,为了能快速遍历对象,而不存在不连续的内存,于是JVM会对tlab做一个填充,填充的正好是int数组对象(从上面代码得知),将剩下的没被分配的tlab内存给填满了,因此在系统运行过程中其实可能伴随着很多无用的对象产生,哈哈,看到这里你是不是豁然开朗?

你是否可以解释如下问题了?

  • 线程越多,int数组增长越快
  • 没有分配byte数组,int数组增长很慢,甚至不增长?
  • jmap其实也不是唯一的因素

这个案例还是非常有意思的,上述问题我抛出来给大家,大家可以到下面留言回答上面的问题,如果没人回答或者没有正确的答案,我到时到下面留言补充,看大家的热情度?欢迎大家转发给更多的人。

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

为你推荐

不起眼,但是足以让你有收获的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有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
谨防JDK8重复类定义造成的内存泄漏
概述 如今JDK8成了主流,大家都紧锣密鼓地进行着升级,享受着JDK8带来的各种便利,然而有时候升级并没有那么顺利?比如说今天要说的这个问题。我们都知道JDK8在内存模型上最大的改变是,放弃了Perm