JVM知識專欄JVM-火種，持續更新，喜歡請關注😍
一個同學在perfam社區提問：“分析dump文件，發現內存中存在很多代碼無關的int[]數組？我點進去看了很久，沒有發現有任何對象引用此類對象。同時我也仔細查了代碼，並沒有任何地方顯示創建這些數組”。
分析
這個問題說白了，就是說有些int[]對象不知道是哪裏來的，於是我拿他的例子跑了跑，好像還真有這麼回事。點該 dump 文件詳情，查看相關的 int[] 數組，點該對象的“被引用對象”，發現所有的對象都是待回收的狀態，即也沒有被任何對象引用，確實很蹊蹺。看了他的例子確實沒有任何地方有 new int[] 的地方。
柳暗花明
由於內存 dump 文件通過 jmap 獲取，於是自然就開始懷疑jmap了，難道是因爲jmap導致的？所以我開始check jmap的實現，包括JDK和JVM裏的邏輯，我要找到哪裏可能會創建int數組，JDK層面基本可以忽略，因爲實在想不到會有啥邏輯可能會有int數組產生，只是發了個命令給JVM進程而已，於是我重點分析JVM層面的實現，當我們使用jmap做了一次dump的時候或者gc發生的時候都會走到下面的邏輯，代碼位置：hotspot/src/share/vm/gc_interface/collectedHeap.cpp
因爲GC或者內存dump，都必須對內存做一個遍歷，因此必須先暫停這些Java線程，防止在遍歷內存裏的對象的時候進行內存分配，但是每個線程分配內存其實都是優先走tlab(每個線程獨有的一塊在eden裏的小內存塊)的，爲了能快速遍歷對象，而不存在不連續的內存，於是JVM會對tlab做一個填充，填充的正好是int數組對象(從上面代碼得知)，將剩下的沒被分配的tlab內存給填滿了，因此在系統運行過程中其實可能伴隨着很多無用的對象產生，哈哈，看到這裏你是不是豁然開朗？
你是否可以解釋如下問題了？
- 線程越多，int數組增長越快
- 沒有分配byte數組，int數組增長很慢，甚至不增長？
- jmap其實也不是唯一的因素
