摘要：本篇圖文將介紹追蹤區域的記憶體型別以及 NMT 無法追蹤的記憶體。
本文分享自華為雲社群《【技術剖析】17. Native Memory Tracking 詳解（3）追蹤區域分析(二)》，作者：畢昇小助手。
Compiler 就是 JIT 編譯器執行緒在編譯 code 時本身所使用的記憶體。檢視 NMT 詳情：
[0x0000ffff93e3acc0] Thread::allocate(unsigned long, bool, MemoryType)+0x348 [0x0000ffff9377a498] CompileBroker::make_compiler_thread(char const*, CompileQueue*, CompilerCounters*, AbstractCompiler*, Thread*)+0x120 [0x0000ffff9377ce98] CompileBroker::init_compiler_threads(int, int)+0x148 [0x0000ffff9377d400] CompileBroker::compilation_init()+0xc8 (malloc=37KB type=Thread #12)
跟蹤呼叫鏈路：InitializeJVM ->
Threads::create_vm ->
CompileBroker::compilation_init ->
CompileBroker::init_compiler_threads ->
CompileBroker::make_compiler_thread
發現最後 make_compiler_thread 的執行緒的個數是在 compilation_init() 中計算的：
# hotspot/src/share/vm/compiler/CompileBroker.cpp void CompileBroker::compilation_init() { ...... // No need to initialize compilation system if we do not use it. if (!UseCompiler) { return; } #ifndef SHARK // Set the interface to the current compiler(s). int c1_count = CompilationPolicy::policy()->compiler_count(CompLevel_simple); int c2_count = CompilationPolicy::policy()->compiler_count(CompLevel_full_optimization); ...... // Start the CompilerThreads init_compiler_threads(c1_count, c2_count); ...... }
追溯 c1_count、c2_count 的計算邏輯，首先在 JVM 初始化的時候（Threads::create_vm -> init_globals -> compilationPolicy_init）要設定編譯的策略 CompilationPolicy：
# hotspot/src/share/vm/runtime/arguments.cpp void Arguments::set_tiered_flags() { // With tiered, set default policy to AdvancedThresholdPolicy, which is 3. if (FLAG_IS_DEFAULT(CompilationPolicyChoice)) { FLAG_SET_DEFAULT(CompilationPolicyChoice, 3); } ...... } # hotspot/src/share/vm/runtime/compilationPolicy.cpp // Determine compilation policy based on command line argument void compilationPolicy_init() { CompilationPolicy::set_in_vm_startup(DelayCompilationDuringStartup); switch(CompilationPolicyChoice) { ...... case 3: #ifdef TIERED CompilationPolicy::set_policy(new AdvancedThresholdPolicy()); #else Unimplemented(); #endif break; ...... CompilationPolicy::policy()->initialize(); }
此時我們預設開啟了分層編譯，所以 CompilationPolicyChoice 為 3 ，編譯策略選用的是 AdvancedThresholdPolicy，檢視相關原始碼（compilationPolicy_init -> AdvancedThresholdPolicy::initialize）：
# hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp void AdvancedThresholdPolicy::initialize() { // Turn on ergonomic compiler count selection if (FLAG_IS_DEFAULT(CICompilerCountPerCPU) && FLAG_IS_DEFAULT(CICompilerCount)) { FLAG_SET_DEFAULT(CICompilerCountPerCPU, true); } int count = CICompilerCount; if (CICompilerCountPerCPU) { // Simple log n seems to grow too slowly for tiered, try something faster: log n * log log n int log_cpu = log2_int(os::active_processor_count()); int loglog_cpu = log2_int(MAX2(log_cpu, 1)); count = MAX2(log_cpu * loglog_cpu, 1) * 3 / 2; } set_c1_count(MAX2(count / 3, 1)); set_c2_count(MAX2(count - c1_count(), 1)); ...... }
我們可以發現，在未手動設定 -XX:CICompilerCountPerCPU 和 -XX:CICompilerCount 這兩個引數的時候，JVM 會啟動 CICompilerCountPerCPU ，啟動編譯執行緒的數目會根據 CPU 數重新計算而不再使用預設的 CICompilerCount 的值（3），計算公式通常情況下為 log n * log log n * 1.5（log 以 2 為底），此時筆者使用的機器有 64 個 CPU，經過計算得出編譯執行緒的數目為 18。計算出編譯執行緒的總數目之後，再按 1:2 的比例分別分配給 C1、C2，即我們上文所求的 c1_count、c2_count。
使用 jinfo -flag CICompilerCount 來驗證此時 JVM 程序的編譯執行緒數目：
jinfo -flag CICompilerCount -XX:CICompilerCount=18
所以我們可以通過顯式的設定 -XX:CICompilerCount 來控制 JVM 開啟編譯執行緒的數目，從而限制 Compiler 部分所使用的記憶體（當然這部分記憶體比較小）。
我們還可以通過 -XX:-TieredCompilation 關閉分層編譯來降低記憶體使用，當然是否關閉分層編譯取決於實際的業務需求，節省的這點記憶體實在微乎其微。
編譯執行緒也是執行緒，所以我們還可以通過 -XX:VMThreadStackSize 設定一個更小的值來節省此部分記憶體，但是削減虛擬機器器執行緒的堆疊大小是危險的操作，並不建議去因為此設定這個引數。
Internal 包含命令列解析器使用的記憶體、JVMTI、PerfData 以及 Unsafe 分配的記憶體等等。
其中命令列直譯器就是在初始化建立虛擬機器器時對 JVM 的命令列引數加以解析並執行相應的操作，如對引數 -XX:NativeMemoryTracking=detail 進行解析。
JVMTI（JVM Tool Interface）是開發和監視 JVM 所使用的程式設計介面。它提供了一些方法去檢查 JVM 狀態和控制 JVM 的執行，詳情可以檢視 JVMTI官方檔案 [1]。
PerfData 是 JVM 中用來記錄一些指標資料的檔案，如果開啟 -XX:+UsePerfData（預設開啟），JVM 會通過 mmap 的方式（即使用上文中提到的 os::reserve_memory 和 os::commit_memory）去對映到 {tmpdir}/hsperfdata_/pid 檔案中，jstat 通過讀取 PerfData 中的資料來展示 JVM 程序中的各種指標資訊.
需要注意的是， {tmpdir}/hsperfdata_/pid 與{tmpdir}/.java_pid 並不是一個東西，後者是在 Attach 機制中用來通訊的，類似一種 Unix Domain Socket 的思想，不過真正的 Unix Domain Socket（JEP380 [2]）在 JDK16 中才支援。
我們在操作 nio 時經常使用 ByteBuffer ，其中 ByteBuffer.allocateDirect / DirectByteBuffer 會通過 unsafe.allocateMemory 的方式來 malloc 分配 naive memory，雖然 DirectByteBuffer 本身還是存放於 Heap 堆中，但是它對應的 address 對映的卻是分配在堆外記憶體的 native memory，NMT 會將 Unsafe_AllocateMemory 方式分配的記憶體記錄在 Internal 之中（jstat 也是通過 ByteBuffer 的方式來使用 PerfData）。
需要注意的是，Unsafe_AllocateMemory 分配的記憶體在 JDK11之前，在 NMT 中都屬於 Internal，但是在 JDK11 之後被 NMT 歸屬到 Other 中。例如相同 ByteBuffer.allocateDirect 在 JDK11 中進行追蹤：[0x0000ffff8c0b4a60] Unsafe_AllocateMemory0+0x60[0x0000ffff6b822fbc] (malloc=393218KB type=Other #3)
簡單檢視下相關原始碼：
# ByteBuffer.java public static ByteBuffer allocateDirect(int capacity) { return new DirectByteBuffer(capacity); } # DirectByteBuffer.java DirectByteBuffer(int cap) { // package-private ...... long base = 0; try { base = unsafe.allocateMemory(size); } ...... # Unsafe.java public native long allocateMemory(long bytes); # hotspot/src/share/vm/prims/unsafe.cpp UNSAFE_ENTRY(jlong, Unsafe_AllocateMemory(JNIEnv *env, jobject unsafe, jlong size)) UnsafeWrapper("Unsafe_AllocateMemory"); size_t sz = (size_t)size; ...... sz = round_to(sz, HeapWordSize); void* x = os::malloc(sz, mtInternal); ...... UNSAFE_END
一般情況下，命令列直譯器、JVMTI等方式不會申請太大的記憶體，我們需要注意的是通過 Unsafe_AllocateMemory 方式申請的堆外記憶體（如業務使用了 Netty ），可以通過一個簡單的範例來進行驗證，這個範例的 JVM 啟動引數為：-Xmx1G -Xms1G -XX:+UseG1GC -XX:MaxMetaspaceSize=256M -XX:ReservedCodeCacheSize=256M -XX:NativeMemoryTracking=detail（去除了 -XX:MaxDirectMemorySize=256M 的限制）：
import java.nio.ByteBuffer; public class ByteBufferTest { private static int _1M = 1024 * 1024; private static ByteBuffer allocateBuffer_1 = ByteBuffer.allocateDirect(128 * _1M); private static ByteBuffer allocateBuffer_2 = ByteBuffer.allocateDirect(256 * _1M); public static void main(String[] args) throws Exception { System.out.println("MaxDirect memory: " + sun.misc.VM.maxDirectMemory() + " bytes"); System.out.println("Direct allocation: " + (allocateBuffer_1.capacity() + allocateBuffer_2.capacity()) + " bytes"); System.out.println("Native memory used: " + sun.misc.SharedSecrets.getJavaNioAccess().getDirectBufferPool().getMemoryUsed() + " bytes"); Thread.sleep(6000000); } }
檢視輸出：
MaxDirect memory: 1073741824 bytes Direct allocation: 402653184 bytes Native memory used: 402653184 bytes
檢視 NMT 詳情：
- Internal (reserved=405202KB, committed=405202KB) (malloc=405170KB #3605) (mmap: reserved=32KB, committed=32KB) ...... [0x0000ffffbb599190] Unsafe_AllocateMemory+0x1c0 [0x0000ffffa40157a8] (malloc=393216KB type=Internal #2) ...... [0x0000ffffbb04b3f8] GenericGrowableArray::raw_allocate(int)+0x188 [0x0000ffffbb4339d8] PerfDataManager::add_item(PerfData*, bool) [clone .constprop.16]+0x108 [0x0000ffffbb434118] PerfDataManager::create_string_variable(CounterNS, char const*, int, char const*, Thread*)+0x178 [0x0000ffffbae9d400] CompilerCounters::CompilerCounters(char const*, int, Thread*) [clone .part.78]+0xb0 (malloc=3KB type=Internal #1) ......
可以發現，我們在程式碼中使用 ByteBuffer.allocateDirect（內部也是使用 new DirectByteBuffer(capacity)）的方式，即 Unsafe_AllocateMemory 申請的堆外記憶體被 NMT 以 Internal 的方式記錄了下來：（128 M + 256 M）= 384 M = 393216 KB = 402653184 Bytes。
當然我們可以使用引數 -XX:MaxDirectMemorySize 來限制 Direct Buffer 申請的最大記憶體。
Symbol 為 JVM 中的符號表所使用的記憶體，HotSpot中符號表主要有兩種：SymbolTable 與 StringTable。
大家都知道 Java 的類在編譯之後會生成 Constant pool 常數池，常數池中會有很多的字串常數，HotSpot 出於節省記憶體的考慮，往往會將這些字串常數作為一個 Symbol 物件存入一個 HashTable 的表結構中即 SymbolTable，如果該字串可以在 SymbolTable 中 lookup（SymbolTable::lookup）到，那麼就會重用該字串，如果找不到才會建立新的 Symbol（SymbolTable::new_symbol）。
當然除了 SymbolTable，還有它的雙胞胎兄弟 StringTable（StringTable 結構與 SymbolTable 基本是一致的，都是 HashTable 的結構），即我們常說的字串常數池。平時做業務開發和 StringTable 打交道會更多一些，HotSpot 也是基於節省記憶體的考慮為我們提供了 StringTable，我們可以通過 String.intern 的方式將字串放入 StringTable 中來重用字串。
編寫一個簡單的範例：
public class StringTableTest { public static void main(String[] args) throws Exception { while (true){ String str = new String("StringTestData_" + System.currentTimeMillis()); str.intern(); } } }
啟動程式後我們可以使用 jcmd VM.native_memory baseline 來建立一個基線方便對比，稍作等待後再使用 jcmd VM.native_memory summary.diff/detail.diff 與建立的基線作對比，對比後我們可以發現：
Total: reserved=2831553KB +20095KB, committed=1515457KB +20095KB ...... - Symbol (reserved=18991KB +17144KB, committed=18991KB +17144KB) (malloc=18504KB +17144KB #2307 +2143) (arena=488KB #1) ...... [0x0000ffffa2aef4a8] BasicHashtable<(MemoryType)9>::new_entry(unsigned int)+0x1a0 [0x0000ffffa2aef558] Hashtable::new_entry(unsigned int, oopDesc*)+0x28 [0x0000ffffa2fbff78] StringTable::basic_add(int, Handle, unsigned short*, int, unsigned int, Thread*)+0xe0 [0x0000ffffa2fc0548] StringTable::intern(Handle, unsigned short*, int, Thread*)+0x1a0 (malloc=17592KB type=Symbol +17144KB #2199 +2143) ......
JVM 程序這段時間記憶體一共增長了 20095KB，其中絕大部分都是 Symbol 申請的記憶體（17144KB），檢視具體的申請資訊正是 StringTable::intern 在不斷的申請記憶體。
如果我們的程式錯誤的使用 String.intern() 或者 JDK intern 相關 BUG 導致了記憶體異常，可以通過這種方式輕鬆協助定位出來。
需要注意的是，虛擬機器器提供的引數 -XX:StringTableSize 並不是來限制 StringTable 最大申請的記憶體大小的，而是用來限制 StringTable 的表的長度的，我們加上 -XX:StringTableSize=10M 來重新啟動 JVM 程序，一段時間後檢視 NMT 追蹤情況：
- Symbol (reserved=100859KB +17416KB, committed=100859KB +17416KB) (malloc=100371KB +17416KB #2359 +2177) (arena=488KB #1) ...... [0x0000ffffa30c14a8] BasicHashtable<(MemoryType)9>::new_entry(unsigned int)+0x1a0 [0x0000ffffa30c1558] Hashtable::new_entry(unsigned int, oopDesc*)+0x28 [0x0000ffffa3591f78] StringTable::basic_add(int, Handle, unsigned short*, int, unsigned int, Thread*)+0xe0 [0x0000ffffa3592548] StringTable::intern(Handle, unsigned short*, int, Thread*)+0x1a0 (malloc=18008KB type=Symbol +17416KB #2251 +2177)
可以發現 StringTable 的大小是超過 10M 的，檢視該引數的作用：
# hotsopt/src/share/vm/classfile/symnolTable.hpp StringTable() : RehashableHashtable((int)StringTableSize, sizeof (HashtableEntry)) {} StringTable(HashtableBucket* t, int number_of_entries) : RehashableHashtable((int)StringTableSize, sizeof (HashtableEntry), t, number_of_entries) {}
因為 StringTable 在 HotSpot 中是以 HashTable 的形式儲存的，所以 -XX:StringTableSize 引數設定的其實是 HashTable 的長度，如果該值設定的過小的話，即使 HashTable 進行 rehash，hash 衝突也會十分頻繁，會造成效能劣化並有可能導致進入 SafePoint 的時間增長。如果發生這種情況，可以調大該值。
如果我們使用的是 JDK11 之後的 NMT，我們可以直接通過命令 jcmd VM.stringtable 與 jcmd VM.symboltable 來檢視兩者的使用情況：
StringTable statistics: Number of buckets : 16777216 = 134217728 bytes, each 8 Number of entries : 39703 = 635248 bytes, each 16 Number of literals : 39703 = 2849304 bytes, avg 71.765 Total footprsize_t : = 137702280 bytes Average bucket size : 0.002 Variance of bucket size : 0.002 Std. dev. of bucket size: 0.049 Maximum bucket size : 2 SymbolTable statistics: Number of buckets : 20011 = 160088 bytes, each 8 Number of entries : 20133 = 483192 bytes, each 24 Number of literals : 20133 = 753832 bytes, avg 37.443 Total footprint : = 1397112 bytes Average bucket size : 1.006 Variance of bucket size : 1.013 Std. dev. of bucket size: 1.006 Maximum bucket size : 9
Native Memory Tracking 使用的記憶體就是 JVM 程序開啟 NMT 功能後，NMT 功能自身所申請的記憶體。
檢視原始碼會發現，JVM 會在 MemTracker::init() 初始化的時候，使用 tracking_level() -> init_tracking_level() 獲取我們設定的 tracking_level 追蹤等級（如：summary、detail），然後將獲取到的 level 分別傳入 MallocTracker::initialize(level) 與 VirtualMemoryTracker::initialize(level) 進行判斷，只有 level >= summary 的情況下，虛擬機器器才會分配 NMT 自身所用到的記憶體，如：VirtualMemoryTracker、MallocMemorySummary、MallocSiteTable（detail 時才會建立） 等來記錄 NMT 追蹤的各種資料。
# /hotspot/src/share/vm/services/memTracker.cpp void MemTracker::init() { NMT_TrackingLevel level = tracking_level(); ...... } # /hotspot/src/share/vm/services/memTracker.hpp static inline NMT_TrackingLevel tracking_level() { if (_tracking_level == NMT_unknown) { // No fencing is needed here, since JVM is in single-threaded // mode. _tracking_level = init_tracking_level(); _cmdline_tracking_level = _tracking_level; } return _tracking_level; } # /hotspot/src/share/vm/services/memTracker.cpp NMT_TrackingLevel MemTracker::init_tracking_level() { NMT_TrackingLevel level = NMT_off; ...... if (os::getenv(buf, nmt_option, sizeof(nmt_option))) { if (strcmp(nmt_option, "summary") == 0) { level = NMT_summary; } else if (strcmp(nmt_option, "detail") == 0) { #if PLATFORM_NATIVE_STACK_WALKING_SUPPORTED level = NMT_detail; #else level = NMT_summary; #endif // PLATFORM_NATIVE_STACK_WALKING_SUPPORTED } ...... } ...... if (!MallocTracker::initialize(level) || !VirtualMemoryTracker::initialize(level)) { level = NMT_off; } return level; } # /hotspot/src/share/vm/services/memTracker.cpp bool MallocTracker::initialize(NMT_TrackingLevel level) { if (level >= NMT_summary) { MallocMemorySummary::initialize(); } if (level == NMT_detail) { return MallocSiteTable::initialize(); } return true; } void MallocMemorySummary::initialize() { assert(sizeof(_snapshot) >= sizeof(MallocMemorySnapshot), "Sanity Check"); // Uses placement new operator to initialize static area. ::new ((void*)_snapshot)MallocMemorySnapshot(); } # bool VirtualMemoryTracker::initialize(NMT_TrackingLevel level) { if (level >= NMT_summary) { VirtualMemorySummary::initialize(); } return true; }
我們執行的 jcmd VM.native_memory summary/detail 命令，就會使用 NMTDCmd::report 方法來根據等級的不同獲取不同的資料：
# hotspot/src/share/vm/services/nmtDCmd.cpp void NMTDCmd::execute(DCmdSource source, TRAPS) { ...... if (_summary.value()) { report(true, scale_unit); } else if (_detail.value()) { if (!check_detail_tracking_level(output())) { return; } report(false, scale_unit); } ...... } void NMTDCmd::report(bool summaryOnly, size_t scale_unit) { MemBaseline baseline; if (baseline.baseline(summaryOnly)) { if (summaryOnly) { MemSummaryReporter rpt(baseline, output(), scale_unit); rpt.report(); } else { MemDetailReporter rpt(baseline, output(), scale_unit); rpt.report(); } } }
一般 NMT 自身佔用的記憶體是比較小的，不需要太過關心。
Arena 是 JVM 分配的一些 Chunk（記憶體塊），當退出作用域或離開程式碼區域時，記憶體將從這些 Chunk 中釋放出來。然後這些 Chunk 就可以在其他子系統中重用. 需要注意的是，此時統計的 Arena 與 Chunk ，是 HotSpot 自己定義的 Arena、Chunk，而不是 Glibc 中相關的 Arena 與 Chunk 的概念。
我們會發現 NMT 詳情中會有很多關於 Arena Chunk 的分配資訊都是：
[0x0000ffff935906e0] ChunkPool::allocate(unsigned long, AllocFailStrategy::AllocFailEnum)+0x158 [0x0000ffff9358ec14] Arena::Arena(MemoryType, unsigned long)+0x18c ......
JVM 中通過 ChunkPool 來管理重用這些 Chunk，比如我們在建立執行緒時：
# /hotspot/src/share/vm/runtime/thread.cpp Thread::Thread() { ...... set_resource_area(new (mtThread)ResourceArea()); ...... set_handle_area(new (mtThread) HandleArea(NULL)); ......
其中 ResourceArea 屬於給執行緒分配的一個資源空間，一般 ResourceObj 都存放於此（如 C1/C2 優化時需要存取的執行時資訊）；HandleArea 則用來存放執行緒所持有的控制程式碼（handle），使用控制程式碼來關聯使用的物件。這兩者都會去申請 Arena，而 Arena 則會通過 ChunkPool::allocate 來申請一個新的 Chunk 記憶體塊。除此之外，JVM 程序用到 Arena 的地方還有非常多，比如 JMX、OopMap 等等一些相關的操作都會用到 ChunkPool。
眼尖的讀者可能會注意到上文中提到，通常情況下會通過 ChunkPool::allocate 的方式來申請 Chunk 記憶體塊。是的，其實除了 ChunkPool::allocate 的方式， JVM 中還存在另外一種申請 Arena Chunk 的方式，即直接藉助 Glibc 的 malloc 來申請記憶體，JVM 為我們提供了相關的控制引數 UseMallocOnly：
develop(bool, UseMallocOnly, false, \ "Use only malloc/free for allocation (no resource area/arena)")
我們可以發現這個引數是一個 develop 的引數，一般情況下我們是使用不到的，因為 VM option 'UseMallocOnly' is develop and is available only in debug version of VM，即我們只能在 debug 版本的 JVM 中才能開啟該引數。
這裡有的讀者可能會有一個疑問，即是不是可以通過使用引數 -XX:+IgnoreUnrecognizedVMOptions（該引數開啟之後可以允許 JVM 使用一些在 release 版本中不被允許使用的引數）的方式，在正常 release 版本的 JVM 中使用 UseMallocOnly 引數，很遺憾雖然我們可以通過這種方式開啟 UseMallocOnly，但是實際上 UseMallocOnly 卻不會生效，因為在原始碼中其邏輯如下：
# hotspot/src/share/vm/memory/allocation.hpp void* Amalloc(size_t x, AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { assert(is_power_of_2(ARENA_AMALLOC_ALIGNMENT) , "should be a power of 2"); x = ARENA_ALIGN(x); //debug 版本限制 debug_only(if (UseMallocOnly) return malloc(x);) if (!check_for_overflow(x, "Arena::Amalloc", alloc_failmode)) return NULL; NOT_PRODUCT(inc_bytes_allocated(x);) if (_hwm + x > _max) { return grow(x, alloc_failmode); } else { char *old = _hwm; _hwm += x; return old; } }
可以發現，即使我們成功開啟了 UseMallocOnly，也只有在 debug 版本（debug_only）的 JVM 中才能使用 malloc 的方式分配記憶體。
我們可以對比下，使用正常版本（release）的 JVM 新增 -XX:+IgnoreUnrecognizedVMOptions -XX:+UseMallocOnly 啟動引數的 NMT 相關紀錄檔與使用 debug（fastdebug/slowdebug）版本的 JVM 新增 -XX:+UseMallocOnly 啟動引數的 NMT 相關紀錄檔：
# 正常 JVM ，啟動引數新增：-XX:+IgnoreUnrecognizedVMOptions -XX:+UseMallocOnly ...... [0x0000ffffb7d16968] ChunkPool::allocate(unsigned long, AllocFailStrategy::AllocFailEnum)+0x158 [0x0000ffffb7d15f58] Arena::grow(unsigned long, AllocFailStrategy::AllocFailEnum)+0x50 [0x0000ffffb7fc4888] Dict::Dict(int (*)(void const*, void const*), int (*)(void const*), Arena*, int)+0x138 [0x0000ffffb85e5968] Type::Initialize_shared(Compile*)+0xb0 (malloc=32KB type=Arena Chunk #1) ...... # debug版本 JVM ，啟動引數新增：-XX:+UseMallocOnly ...... [0x0000ffff8dfae910] Arena::malloc(unsigned long)+0x74 [0x0000ffff8e2cb3b8] Arena::Amalloc_4(unsigned long, AllocFailStrategy::AllocFailEnum)+0x70 [0x0000ffff8e2c9d5c] Dict::Dict(int (*)(void const*, void const*), int (*)(void const*), Arena*, int)+0x19c [0x0000ffff8e97c3d0] Type::Initialize_shared(Compile*)+0x9c (malloc=5KB type=Arena Chunk #1) ......
我們可以清晰地觀察到呼叫鏈的不同，即前者還是使用 ChunkPool::allocate 的方式來申請記憶體，而後者則使用 Arena::malloc 的方式來申請記憶體，檢視 Arena::malloc 程式碼：
# hotspot/src/share/vm/memory/allocation.cpp void* Arena::malloc(size_t size) { assert(UseMallocOnly, "shouldn't call"); // use malloc, but save pointer in res. area for later freeing char** save = (char**)internal_malloc_4(sizeof(char*)); return (*save = (char*)os::malloc(size, mtChunk)); }
可以發現程式碼中通過 os::malloc 的方式來分配記憶體，同理釋放記憶體時直接通過 os::free 即可，如 UseMallocOnly 中釋放記憶體的相關程式碼：
# hotspot/src/share/vm/memory/allocation.cpp // debugging code inline void Arena::free_all(char** start, char** end) { for (char** p = start; p < end; p++) if (*p) os::free(*p); }
雖然 JVM 為我們提供了兩種方式來管理 Arena Chunk 的記憶體：
但是通常意義下我們只會用到第一種方式，並且一般 ChunkPool 管理的物件都比較小，整體來看 Arena Chunk 這塊記憶體的使用不會很多。
Unknown 則是下面幾種情況
需要注意的是，NMT 只能跟蹤 JVM 程式碼的記憶體分配情況，對於非 JVM 的記憶體分配是無法追蹤到的。
可以使用作業系統的記憶體工具等協助排查，或者使用 LD_PRELOAD malloc 函數的 hook/jemalloc/google-perftools(tcmalloc) 來代替 Glibc 的 malloc，協助追蹤記憶體的分配。
由於篇幅有限，將在下篇文章給大家分享「使用 NMT 協助排查記憶體問題的案例」，敬請期待！
歡迎加入Compiler SIG交流群與大家共同交流學習編譯技術相關內容，掃碼新增小助手微信邀請你進入Compiler SIG交流群。