4.6 Compiler

Compiler 就是 JIT 編譯器線程在編譯 code 時(shí)本身所使用的內(nèi)存。查看 NMT 詳情：

[0x0000ffff93e3acc0]Thread::allocate(unsignedlong,bool,MemoryType)+0x348
[0x0000ffff9377a498]CompileBroker::make_compiler_thread(charconst*,CompileQueue*,CompilerCounters*,AbstractCompiler*,Thread*)+0x120
[0x0000ffff9377ce98]CompileBroker::init_compiler_threads(int,int)+0x148
[0x0000ffff9377d400]CompileBroker::compilation_init()+0xc8
(malloc=37KBtype=Thread#12)

跟蹤調(diào)用鏈路：InitializeJVM ->
Threads::create_vm ->
CompileBroker::compilation_init ->
CompileBroker::init_compiler_threads ->
CompileBroker::make_compiler_thread

發(fā)現(xiàn)最后 make_compiler_thread 的線程的個(gè)數(shù)是在 compilation_init() 中計(jì)算的：

#hotspot/src/share/vm/compiler/CompileBroker.cpp

voidCompileBroker::compilation_init(){
......
//Noneedtoinitializecompilationsystemifwedonotuseit.
if(!UseCompiler){
return;
}
#ifndefSHARK
//Settheinterfacetothecurrentcompiler(s).
intc1_count=CompilationPolicy::policy()->compiler_count(CompLevel_simple);
intc2_count=CompilationPolicy::policy()->compiler_count(CompLevel_full_optimization);
......
//StarttheCompilerThreads
init_compiler_threads(c1_count,c2_count);
......
}

追溯 c1_count、c2_count 的計(jì)算邏輯，首先在 JVM 初始化的時(shí)候（Threads::create_vm -> init_globals -> compilationPolicy_init）要設(shè)置編譯的策略 CompilationPolicy：

#hotspot/src/share/vm/runtime/arguments.cpp

voidArguments::set_tiered_flags(){
//Withtiered,setdefaultpolicytoAdvancedThresholdPolicy,whichis3.
if(FLAG_IS_DEFAULT(CompilationPolicyChoice)){
FLAG_SET_DEFAULT(CompilationPolicyChoice,3);
}
......
}

#hotspot/src/share/vm/runtime/compilationPolicy.cpp

//Determinecompilationpolicybasedoncommandlineargument
voidcompilationPolicy_init(){
CompilationPolicy::set_in_vm_startup(DelayCompilationDuringStartup);

switch(CompilationPolicyChoice){
......
case3:
#ifdefTIERED
CompilationPolicy::set_policy(newAdvancedThresholdPolicy());
#else
Unimplemented();
#endif
break;
......
CompilationPolicy::policy()->initialize();
}

此時(shí)我們默認(rèn)開(kāi)啟了分層編譯，所以 CompilationPolicyChoice 為 3 ，編譯策略選用的是 AdvancedThresholdPolicy，查看相關(guān)源碼（compilationPolicy_init -> AdvancedThresholdPolicy::initialize）：

#hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp

voidAdvancedThresholdPolicy::initialize(){
//Turnonergonomiccompilercountselection
if(FLAG_IS_DEFAULT(CICompilerCountPerCPU)&&FLAG_IS_DEFAULT(CICompilerCount)){
FLAG_SET_DEFAULT(CICompilerCountPerCPU,true);
}
intcount=CICompilerCount;
if(CICompilerCountPerCPU){
//Simplelognseemstogrowtooslowlyfortiered,trysomethingfaster:logn*loglogn
intlog_cpu=log2_int(os::active_processor_count());
intloglog_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));
......
}

我們可以發(fā)現(xiàn)，在未手動(dòng)設(shè)置 -XX:CICompilerCountPerCPU 和 -XX:CICompilerCount 這兩個(gè)參數(shù)的時(shí)候，JVM 會(huì)啟動(dòng) CICompilerCountPerCPU ，啟動(dòng)編譯線程的數(shù)目會(huì)根據(jù) CPU 數(shù)重新計(jì)算而不再使用默認(rèn)的 CICompilerCount 的值（3），計(jì)算公式通常情況下為 log n * log log n * 1.5（log 以 2 為底），此時(shí)筆者使用的機(jī)器有 64 個(gè) CPU，經(jīng)過(guò)計(jì)算得出編譯線程的數(shù)目為 18。

計(jì)算出編譯線程的總數(shù)目之后，再按 1:2 的比例分別分配給 C1、C2，即我們上文所求的 c1_count、c2_count。

使用 jinfo -flag CICompilerCount 來(lái)驗(yàn)證此時(shí) JVM 進(jìn)程的編譯線程數(shù)目：

jinfo-flagCICompilerCount

-XX:CICompilerCount=18

所以我們可以通過(guò)顯式的設(shè)置 -XX:CICompilerCount 來(lái)控制 JVM 開(kāi)啟編譯線程的數(shù)目，從而限制 Compiler 部分所使用的內(nèi)存（當(dāng)然這部分內(nèi)存比較?。?。

我們還可以通過(guò) -XX:-TieredCompilation 關(guān)閉分層編譯來(lái)降低內(nèi)存使用，當(dāng)然是否關(guān)閉分層編譯取決于實(shí)際的業(yè)務(wù)需求，節(jié)省的這點(diǎn)內(nèi)存實(shí)在微乎其微。

編譯線程也是線程，所以我們還可以通過(guò) -XX:VMThreadStackSize 設(shè)置一個(gè)更小的值來(lái)節(jié)省此部分內(nèi)存，但是削減虛擬機(jī)線程的堆棧大小是危險(xiǎn)的操作，并不建議去因?yàn)榇嗽O(shè)置這個(gè)參數(shù)。

4.7 Internal

Internal 包含命令行解析器使用的內(nèi)存、JVMTI、PerfData 以及 Unsafe 分配的內(nèi)存等等。

其中命令行解釋器就是在初始化創(chuàng)建虛擬機(jī)時(shí)對(duì) JVM 的命令行參數(shù)加以解析并執(zhí)行相應(yīng)的操作，如對(duì)參數(shù) -XX:NativeMemoryTracking=detail 進(jìn)行解析。

JVMTI（JVM Tool Interface）是開(kāi)發(fā)和監(jiān)視 JVM 所使用的編程接口。它提供了一些方法去檢查 JVM 狀態(tài)和控制 JVM 的運(yùn)行，詳情可以查看 JVMTI官方文檔 [1]。

PerfData 是 JVM 中用來(lái)記錄一些指標(biāo)數(shù)據(jù)的文件，如果開(kāi)啟 -XX:+UsePerfData（默認(rèn)開(kāi)啟），JVM 會(huì)通過(guò) mmap 的方式（即使用上文中提到的 os::reserve_memory 和 os::commit_memory）去映射到 {tmpdir}/hsperfdata_/pid 文件中，jstat 通過(guò)讀取 PerfData 中的數(shù)據(jù)來(lái)展示 JVM 進(jìn)程中的各種指標(biāo)信息.

需要注意的是， {tmpdir}/hsperfdata_/pid 與{tmpdir}/.java_pid 并不是一個(gè)東西，后者是在 Attach 機(jī)制中用來(lái)通訊的，類似一種 Unix Domain Socket 的思想，不過(guò)真正的 Unix Domain Socket（JEP380 [2]）在 JDK16 中才支持。

我們?cè)诓僮?nio 時(shí)經(jīng)常使用 ByteBuffer ，其中 ByteBuffer.allocateDirect / DirectByteBuffer 會(huì)通過(guò) unsafe.allocateMemory 的方式來(lái) malloc 分配 naive memory，雖然 DirectByteBuffer 本身還是存放于 Heap 堆中，但是它對(duì)應(yīng)的 address 映射的卻是分配在堆外內(nèi)存的 native memory，NMT 會(huì)將 Unsafe_AllocateMemory 方式分配的內(nèi)存記錄在 Internal 之中（jstat 也是通過(guò) ByteBuffer 的方式來(lái)使用 PerfData）。

需要注意的是，Unsafe_AllocateMemory 分配的內(nèi)存在 JDK11之前，在 NMT 中都屬于 Internal，但是在 JDK11 之后被 NMT 歸屬到 Other 中。例如相同 ByteBuffer.allocateDirect 在 JDK11 中進(jìn)行追蹤：[0x0000ffff8c0b4a60] Unsafe_AllocateMemory0+0x60[0x0000ffff6b822fbc] (malloc=393218KB type=Other #3)

簡(jiǎn)單查看下相關(guān)源碼：

#ByteBuffer.java
publicstaticByteBufferallocateDirect(intcapacity){
returnnewDirectByteBuffer(capacity);
}

#DirectByteBuffer.java
DirectByteBuffer(intcap){//package-private
......
longbase=0;
try{
base=unsafe.allocateMemory(size);
}
......

#Unsafe.java
publicnativelongallocateMemory(longbytes);

#hotspot/src/share/vm/prims/unsafe.cpp
UNSAFE_ENTRY(jlong,Unsafe_AllocateMemory(JNIEnv*env,jobjectunsafe,jlongsize))
UnsafeWrapper("Unsafe_AllocateMemory");
size_tsz=(size_t)size;
......
sz=round_to(sz,HeapWordSize);
void*x=os::malloc(sz,mtInternal);
......
UNSAFE_END

一般情況下，命令行解釋器、JVMTI等方式不會(huì)申請(qǐng)?zhí)蟮膬?nèi)存，我們需要注意的是通過(guò) Unsafe_AllocateMemory 方式申請(qǐng)的堆外內(nèi)存（如業(yè)務(wù)使用了 Netty ），可以通過(guò)一個(gè)簡(jiǎn)單的示例來(lái)進(jìn)行驗(yàn)證，這個(gè)示例的 JVM 啟動(dòng)參數(shù)為：-Xmx1G -Xms1G -XX:+UseG1GC -XX:MaxMetaspaceSize=256M -XX:ReservedCodeCacheSize=256M -XX:NativeMemoryTracking=detail（去除了 -XX:MaxDirectMemorySize=256M 的限制）：

importjava.nio.ByteBuffer;

publicclassByteBufferTest{

privatestaticint_1M=1024*1024;
privatestaticByteBufferallocateBuffer_1=ByteBuffer.allocateDirect(128*_1M);
privatestaticByteBufferallocateBuffer_2=ByteBuffer.allocateDirect(256*_1M);

publicstaticvoidmain(String[]args)throwsException{
System.out.println("MaxDirectmemory:"+sun.misc.VM.maxDirectMemory()+"bytes");
System.out.println("Directallocation:"+(allocateBuffer_1.capacity()+allocateBuffer_2.capacity())+"bytes");
System.out.println("Nativememoryused:"+sun.misc.SharedSecrets.getJavaNioAccess().getDirectBufferPool().getMemoryUsed()+"bytes");
Thread.sleep(6000000);
}
}

查看輸出：

MaxDirectmemory:1073741824bytes
Directallocation:402653184bytes
Nativememoryused:402653184bytes

查看 NMT 詳情：

-Internal(reserved=405202KB,committed=405202KB)
(malloc=405170KB#3605)
(mmap:reserved=32KB,committed=32KB)
......
[0x0000ffffbb599190]Unsafe_AllocateMemory+0x1c0
[0x0000ffffa40157a8]
(malloc=393216KBtype=Internal#2)
......
[0x0000ffffbb04b3f8]GenericGrowableArray::raw_allocate(int)+0x188
[0x0000ffffbb4339d8]PerfDataManager::add_item(PerfData*,bool)[clone.constprop.16]+0x108
[0x0000ffffbb434118]PerfDataManager::create_string_variable(CounterNS,charconst*,int,charconst*,Thread*)+0x178
[0x0000ffffbae9d400]CompilerCounters::CompilerCounters(charconst*,int,Thread*)[clone.part.78]+0xb0
(malloc=3KBtype=Internal#1)
......

可以發(fā)現(xiàn)，我們?cè)诖a中使用 ByteBuffer.allocateDirect（內(nèi)部也是使用 new DirectByteBuffer(capacity)）的方式，即 Unsafe_AllocateMemory 申請(qǐng)的堆外內(nèi)存被 NMT 以 Internal 的方式記錄了下來(lái)：（128 M + 256 M）= 384 M = 393216 KB = 402653184 Bytes。

當(dāng)然我們可以使用參數(shù) -XX:MaxDirectMemorySize 來(lái)限制 Direct Buffer 申請(qǐng)的最大內(nèi)存。

4.8 Symbol

Symbol 為 JVM 中的符號(hào)表所使用的內(nèi)存，HotSpot中符號(hào)表主要有兩種：SymbolTable 與 StringTable。

大家都知道 Java 的類在編譯之后會(huì)生成 Constant pool 常量池，常量池中會(huì)有很多的字符串常量，HotSpot 出于節(jié)省內(nèi)存的考慮，往往會(huì)將這些字符串常量作為一個(gè) Symbol 對(duì)象存入一個(gè) HashTable 的表結(jié)構(gòu)中即 SymbolTable，如果該字符串可以在 SymbolTable 中 lookup（SymbolTable::lookup）到，那么就會(huì)重用該字符串，如果找不到才會(huì)創(chuàng)建新的 Symbol（SymbolTable::new_symbol）。

當(dāng)然除了 SymbolTable，還有它的雙胞胎兄弟 StringTable（StringTable 結(jié)構(gòu)與 SymbolTable 基本是一致的，都是 HashTable 的結(jié)構(gòu)），即我們常說(shuō)的字符串常量池。

平時(shí)做業(yè)務(wù)開(kāi)發(fā)和 StringTable 打交道會(huì)更多一些，HotSpot 也是基于節(jié)省內(nèi)存的考慮為我們提供了 StringTable，我們可以通過(guò) String.intern 的方式將字符串放入 StringTable 中來(lái)重用字符串。

編寫(xiě)一個(gè)簡(jiǎn)單的示例：

publicclassStringTableTest{
publicstaticvoidmain(String[]args)throwsException{
while(true){
Stringstr=newString("StringTestData_"+System.currentTimeMillis());
str.intern();
}
}
}

啟動(dòng)程序后我們可以使用 jcmd VM.native_memory baseline 來(lái)創(chuàng)建一個(gè)基線方便對(duì)比，稍作等待后再使用 jcmd VM.native_memory summary.diff/detail.diff 與創(chuàng)建的基線作對(duì)比，對(duì)比后我們可以發(fā)現(xiàn)：

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(unsignedint)+0x1a0
[0x0000ffffa2aef558]Hashtable::new_entry(unsignedint,oopDesc*)+0x28
[0x0000ffffa2fbff78]StringTable::basic_add(int,Handle,unsignedshort*,int,unsignedint,Thread*)+0xe0
[0x0000ffffa2fc0548]StringTable::intern(Handle,unsignedshort*,int,Thread*)+0x1a0
(malloc=17592KBtype=Symbol+17144KB#2199+2143)
......

JVM 進(jìn)程這段時(shí)間內(nèi)存一共增長(zhǎng)了 20095KB，其中絕大部分都是 Symbol 申請(qǐng)的內(nèi)存（17144KB），查看具體的申請(qǐng)信息正是 StringTable::intern 在不斷的申請(qǐng)內(nèi)存。

如果我們的程序錯(cuò)誤的使用 String.intern() 或者 JDK intern 相關(guān) BUG 導(dǎo)致了內(nèi)存異常，可以通過(guò)這種方式輕松協(xié)助定位出來(lái)。

需要注意的是，虛擬機(jī)提供的參數(shù) -XX:StringTableSize 并不是來(lái)限制 StringTable 最大申請(qǐng)的內(nèi)存大小的，而是用來(lái)限制 StringTable 的表的長(zhǎng)度的，我們加上 -XX:StringTableSize=10M 來(lái)重新啟動(dòng) JVM 進(jìn)程，一段時(shí)間后查看 NMT 追蹤情況：

-Symbol(reserved=100859KB+17416KB,committed=100859KB+17416KB)
(malloc=100371KB+17416KB#2359+2177)
(arena=488KB#1)
......
[0x0000ffffa30c14a8]BasicHashtable<(MemoryType)9>::new_entry(unsignedint)+0x1a0
[0x0000ffffa30c1558]Hashtable::new_entry(unsignedint,oopDesc*)+0x28
[0x0000ffffa3591f78]StringTable::basic_add(int,Handle,unsignedshort*,int,unsignedint,Thread*)+0xe0
[0x0000ffffa3592548]StringTable::intern(Handle,unsignedshort*,int,Thread*)+0x1a0
(malloc=18008KBtype=Symbol+17416KB#2251+2177)

可以發(fā)現(xiàn) StringTable 的大小是超過(guò) 10M 的，查看該參數(shù)的作用：

#hotsopt/src/share/vm/classfile/symnolTable.hpp

StringTable():RehashableHashtable((int)StringTableSize,
sizeof(HashtableEntry)){}

StringTable(HashtableBucket*t,intnumber_of_entries)
:RehashableHashtable((int)StringTableSize,sizeof(HashtableEntry),t,
number_of_entries){}

因?yàn)?StringTable 在 HotSpot 中是以 HashTable 的形式存儲(chǔ)的，所以 -XX:StringTableSize 參數(shù)設(shè)置的其實(shí)是 HashTable 的長(zhǎng)度，如果該值設(shè)置的過(guò)小的話，即使 HashTable 進(jìn)行 rehash，hash 沖突也會(huì)十分頻繁，會(huì)造成性能劣化并有可能導(dǎo)致進(jìn)入 SafePoint 的時(shí)間增長(zhǎng)。如果發(fā)生這種情況，可以調(diào)大該值。

-XX:StringTableSize 在 32 位系統(tǒng)默認(rèn)為 1009、64 位默認(rèn)為 60013 ：const int defaultStringTableSize = NOT_LP64(1009) LP64_ONLY(60013); 。

G1中可以使用 -XX:+UseStringDeduplication 參數(shù)來(lái)開(kāi)啟字符串自動(dòng)去重功能（默認(rèn)關(guān)閉），并使用 -XX:StringDeduplicationAgeThreshold 來(lái)控制字符串參與去重的 GC 年齡閾值。

與 -XX:StringTableSize 同理，我們可以通過(guò) -XX:SymbolTableSize 來(lái)控制 SymbolTable 表的長(zhǎng)度。

如果我們使用的是 JDK11 之后的 NMT，我們可以直接通過(guò)命令 jcmd VM.stringtable 與 jcmd VM.symboltable 來(lái)查看兩者的使用情況：

StringTablestatistics:
Numberofbuckets:16777216=134217728bytes,each8
Numberofentries:39703=635248bytes,each16
Numberofliterals:39703=2849304bytes,avg71.765
Totalfootprsize_t:=137702280bytes
Averagebucketsize:0.002
Varianceofbucketsize:0.002
Std.dev.ofbucketsize:0.049
Maximumbucketsize:2

SymbolTablestatistics:
Numberofbuckets:20011=160088bytes,each8
Numberofentries:20133=483192bytes,each24
Numberofliterals:20133=753832bytes,avg37.443
Totalfootprint:=1397112bytes
Averagebucketsize:1.006
Varianceofbucketsize:1.013
Std.dev.ofbucketsize:1.006
Maximumbucketsize:9

4.9 Native Memory Tracking

Native Memory Tracking 使用的內(nèi)存就是 JVM 進(jìn)程開(kāi)啟 NMT 功能后，NMT 功能自身所申請(qǐng)的內(nèi)存。

查看源碼會(huì)發(fā)現(xiàn)，JVM 會(huì)在 MemTracker::init() 初始化的時(shí)候，使用 tracking_level() -> init_tracking_level() 獲取我們?cè)O(shè)定的 tracking_level 追蹤等級(jí)（如：summary、detail），然后將獲取到的 level 分別傳入 MallocTracker::initialize(level) 與 VirtualMemoryTracker::initialize(level) 進(jìn)行判斷，只有 level >= summary 的情況下，虛擬機(jī)才會(huì)分配 NMT 自身所用到的內(nèi)存，如：VirtualMemoryTracker、MallocMemorySummary、MallocSiteTable（detail 時(shí)才會(huì)創(chuàng)建） 等來(lái)記錄 NMT 追蹤的各種數(shù)據(jù)。

#/hotspot/src/share/vm/services/memTracker.cpp
voidMemTracker::init(){
NMT_TrackingLevellevel=tracking_level();
......
}

#/hotspot/src/share/vm/services/memTracker.hpp
staticinlineNMT_TrackingLeveltracking_level(){
if(_tracking_level==NMT_unknown){
//Nofencingisneededhere,sinceJVMisinsingle-threaded
//mode.
_tracking_level=init_tracking_level();
_cmdline_tracking_level=_tracking_level;
}
return_tracking_level;
}

#/hotspot/src/share/vm/services/memTracker.cpp
NMT_TrackingLevelMemTracker::init_tracking_level(){
NMT_TrackingLevellevel=NMT_off;
......
if(os::getenv(buf,nmt_option,sizeof(nmt_option))){
if(strcmp(nmt_option,"summary")==0){
level=NMT_summary;
}elseif(strcmp(nmt_option,"detail")==0){
#ifPLATFORM_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;
}
returnlevel;
}

#/hotspot/src/share/vm/services/memTracker.cpp
boolMallocTracker::initialize(NMT_TrackingLevellevel){
if(level>=NMT_summary){
MallocMemorySummary::initialize();
}

if(level==NMT_detail){
returnMallocSiteTable::initialize();
}
returntrue;
}
voidMallocMemorySummary::initialize(){
assert(sizeof(_snapshot)>=sizeof(MallocMemorySnapshot),"SanityCheck");
//Usesplacementnewoperatortoinitializestaticarea.
::new((void*)_snapshot)MallocMemorySnapshot();
}

#
boolVirtualMemoryTracker::initialize(NMT_TrackingLevellevel){
if(level>=NMT_summary){
VirtualMemorySummary::initialize();
}
returntrue;
}

我們執(zhí)行的 jcmd VM.native_memory summary/detail 命令，就會(huì)使用 NMTDCmd::report 方法來(lái)根據(jù)等級(jí)的不同獲取不同的數(shù)據(jù)：

summary 時(shí)使用 MemSummaryReporter::report() 獲取 VirtualMemoryTracker、MallocMemorySummary 等儲(chǔ)存的數(shù)據(jù)；

detail 時(shí)使用 MemDetailReporter::report() 獲取 VirtualMemoryTracker、MallocMemorySummary、MallocSiteTable 等儲(chǔ)存的數(shù)據(jù)。

#hotspot/src/share/vm/services/nmtDCmd.cpp

voidNMTDCmd::execute(DCmdSourcesource,TRAPS){
......
if(_summary.value()){
report(true,scale_unit);
}elseif(_detail.value()){
if(!check_detail_tracking_level(output())){
return;
}
report(false,scale_unit);
}
......
}

voidNMTDCmd::report(boolsummaryOnly,size_tscale_unit){
MemBaselinebaseline;
if(baseline.baseline(summaryOnly)){
if(summaryOnly){
MemSummaryReporterrpt(baseline,output(),scale_unit);
rpt.report();
}else{
MemDetailReporterrpt(baseline,output(),scale_unit);
rpt.report();
}
}
}

一般 NMT 自身占用的內(nèi)存是比較小的，不需要太過(guò)關(guān)心。

4.10 Arena Chunk

Arena 是 JVM 分配的一些 Chunk（內(nèi)存塊），當(dāng)退出作用域或離開(kāi)代碼區(qū)域時(shí)，內(nèi)存將從這些 Chunk 中釋放出來(lái)。

然后這些 Chunk 就可以在其他子系統(tǒng)中重用. 需要注意的是，此時(shí)統(tǒng)計(jì)的 Arena 與 Chunk ，是 HotSpot 自己定義的 Arena、Chunk，而不是 Glibc 中相關(guān)的 Arena 與 Chunk 的概念。

我們會(huì)發(fā)現(xiàn) NMT 詳情中會(huì)有很多關(guān)于 Arena Chunk 的分配信息都是：

[0x0000ffff935906e0] ChunkPool::allocate(unsigned long, AllocFailStrategy::AllocFailEnum)+0x158
[0x0000ffff9358ec14]Arena::Arena(MemoryType,unsignedlong)+0x18c
......

JVM 中通過(guò) ChunkPool 來(lái)管理重用這些 Chunk，比如我們?cè)趧?chuàng)建線程時(shí)：

#/hotspot/src/share/vm/runtime/thread.cpp

Thread::Thread(){
......
set_resource_area(new(mtThread)ResourceArea());
......
set_handle_area(new(mtThread)HandleArea(NULL));
......

其中 ResourceArea 屬于給線程分配的一個(gè)資源空間，一般 ResourceObj 都存放于此（如 C1/C2 優(yōu)化時(shí)需要訪問(wèn)的運(yùn)行時(shí)信息）；HandleArea 則用來(lái)存放線程所持有的句柄（handle），使用句柄來(lái)關(guān)聯(lián)使用的對(duì)象。這兩者都會(huì)去申請(qǐng)

Arena，而 Arena 則會(huì)通過(guò) ChunkPool::allocate 來(lái)申請(qǐng)一個(gè)新的 Chunk 內(nèi)存塊。除此之外，JVM 進(jìn)程用到 Arena 的地方還有非常多，比如 JMX、OopMap 等等一些相關(guān)的操作都會(huì)用到 ChunkPool。

眼尖的讀者可能會(huì)注意到上文中提到，通常情況下會(huì)通過(guò) ChunkPool::allocate 的方式來(lái)申請(qǐng) Chunk 內(nèi)存塊。

是的，其實(shí)除了 ChunkPool::allocate 的方式， JVM 中還存在另外一種申請(qǐng) Arena Chunk 的方式，即直接借助 Glibc 的 malloc 來(lái)申請(qǐng)內(nèi)存，JVM 為我們提供了相關(guān)的控制參數(shù) UseMallocOnly：

develop(bool,UseMallocOnly,false,
"Useonlymalloc/freeforallocation(noresourcearea/arena)")

我們可以發(fā)現(xiàn)這個(gè)參數(shù)是一個(gè) develop 的參數(shù)，一般情況下我們是使用不到的，因?yàn)閂M option 'UseMallocOnly' is develop and is available only in debug version of VM，即我們只能在 debug 版本的 JVM 中才能開(kāi)啟該參數(shù)。

這里有的讀者可能會(huì)有一個(gè)疑問(wèn)，即是不是可以通過(guò)使用參數(shù) -XX:+IgnoreUnrecognizedVMOptions（該參數(shù)開(kāi)啟之后可以允許 JVM 使用一些在 release 版本中不被允許使用的參數(shù)）的方式，在正常 release 版本的 JVM 中使用 UseMallocOnly 參數(shù)，很遺憾雖然我們可以通過(guò)這種方式開(kāi)啟 UseMallocOnly，但是實(shí)際上 UseMallocOnly 卻不會(huì)生效，因?yàn)樵谠创a中其邏輯如下：

#hotspot/src/share/vm/memory/allocation.hpp

void*Amalloc(size_tx,AllocFailTypealloc_failmode=AllocFailStrategy::EXIT_OOM){
assert(is_power_of_2(ARENA_AMALLOC_ALIGNMENT),"shouldbeapowerof2");
x=ARENA_ALIGN(x);
//debug版本限制
debug_only(if(UseMallocOnly)returnmalloc(x);)
if(!check_for_overflow(x,"Arena::Amalloc",alloc_failmode))
returnNULL;
NOT_PRODUCT(inc_bytes_allocated(x);)
if(_hwm+x>_max){
returngrow(x,alloc_failmode);
}else{
char*old=_hwm;
_hwm+=x;
returnold;
}
}

可以發(fā)現(xiàn)，即使我們成功開(kāi)啟了 UseMallocOnly，也只有在 debug 版本（debug_only）的 JVM 中才能使用 malloc 的方式分配內(nèi)存。

我們可以對(duì)比下，使用正常版本（release）的 JVM 添加-XX:+IgnoreUnrecognizedVMOptions -XX:+UseMallocOnly啟動(dòng)參數(shù)的 NMT 相關(guān)日志與使用 debug（fastdebug/slowdebug）版本的 JVM 添加-XX:+UseMallocOnly啟動(dòng)參數(shù)的 NMT 相關(guān)日志：

#正常 JVM ，啟動(dòng)參數(shù)添加：-XX:+IgnoreUnrecognizedVMOptions -XX:+UseMallocOnly
......
[0x0000ffffb7d16968]ChunkPool::allocate(unsignedlong,AllocFailStrategy::AllocFailEnum)+0x158
[0x0000ffffb7d15f58]Arena::grow(unsignedlong,AllocFailStrategy::AllocFailEnum)+0x50
[0x0000ffffb7fc4888]Dict::Dict(int(*)(voidconst*,voidconst*),int(*)(voidconst*),Arena*,int)+0x138
[0x0000ffffb85e5968]Type::Initialize_shared(Compile*)+0xb0
(malloc=32KBtype=ArenaChunk#1)
......

# debug版本 JVM ，啟動(dòng)參數(shù)添加：-XX:+UseMallocOnly
......
[0x0000ffff8dfae910]Arena::malloc(unsignedlong)+0x74
[0x0000ffff8e2cb3b8]Arena::Amalloc_4(unsignedlong,AllocFailStrategy::AllocFailEnum)+0x70
[0x0000ffff8e2c9d5c]Dict::Dict(int(*)(voidconst*,voidconst*),int(*)(voidconst*),Arena*,int)+0x19c
[0x0000ffff8e97c3d0]Type::Initialize_shared(Compile*)+0x9c
(malloc=5KBtype=ArenaChunk#1)
......

我們可以清晰地觀察到調(diào)用鏈的不同，即前者還是使用 ChunkPool::allocate 的方式來(lái)申請(qǐng)內(nèi)存，而后者則使用 Arena::malloc 的方式來(lái)申請(qǐng)內(nèi)存，查看 Arena::malloc 代碼：

#hotspot/src/share/vm/memory/allocation.cpp

void*Arena::malloc(size_tsize){
assert(UseMallocOnly,"shouldn'tcall");
//usemalloc,butsavepointerinres.areaforlaterfreeing
char**save=(char**)internal_malloc_4(sizeof(char*));
return(*save=(char*)os::malloc(size,mtChunk));
}

可以發(fā)現(xiàn)代碼中通過(guò)os::malloc的方式來(lái)分配內(nèi)存，同理釋放內(nèi)存時(shí)直接通過(guò)os::free即可，如 UseMallocOnly 中釋放內(nèi)存的相關(guān)代碼：

#hotspot/src/share/vm/memory/allocation.cpp

//debuggingcode
inlinevoidArena::free_all(char**start,char**end){
for(char**p=start;p

	

	雖然 JVM 為我們提供了兩種方式來(lái)管理 Arena Chunk 的內(nèi)存：

	通過(guò) ChunkPool 池化交由 JVM 自己管理；

	直接通過(guò) Glibc 的 malloc/free 來(lái)進(jìn)行管理。

	但是通常意義下我們只會(huì)用到第一種方式，并且一般 ChunkPool 管理的對(duì)象都比較小，整體來(lái)看 Arena Chunk 這塊內(nèi)存的使用不會(huì)很多。

	4.11 Unknown

	Unknown則是下面幾種情況

	當(dāng)內(nèi)存類別無(wú)法確定時(shí)；

	當(dāng) Arena 用作堆棧或值對(duì)象時(shí)；

	當(dāng)類型信息尚未到達(dá)時(shí)。

	5.NMT 無(wú)法追蹤的內(nèi)存

	需要注意的是，NMT 只能跟蹤 JVM 代碼的內(nèi)存分配情況，對(duì)于非 JVM 的內(nèi)存分配是無(wú)法追蹤到的。

	使用 JNI 調(diào)用的一些第三方 native code 申請(qǐng)的內(nèi)存，比如使用 System.Loadlibrary 加載的一些庫(kù)。

	標(biāo)準(zhǔn)的 Java Class Library，典型的，如文件流等相關(guān)操作（如：Files.list、ZipInputStream 和 DirectoryStream 等）。

	可以使用操作系統(tǒng)的內(nèi)存工具等協(xié)助排查，或者使用 LD_PRELOAD malloc 函數(shù)的 hook/jemalloc/google-perftools(tcmalloc) 來(lái)代替 Glibc 的 malloc，協(xié)助追蹤內(nèi)存的分配。

	




	審核編輯：劉清