介绍追踪区域的其它内存类型以及NMT无法追踪的内存
4.6 compiler
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.cppvoid 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.cppvoid 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 argumentvoid 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.cppvoid 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 设置一个更小的值来节省此部分内存，但是削减虚拟机线程的堆栈大小是危险的操作，并不建议去因为此设置这个参数。
4.7 internal
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.cppunsafe_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 bytesdirect allocation: 402653184 bytesnative 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 申请的最大内存。
4.8 symbol
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::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::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 的时间增长。如果发生这种情况，可以调大该值。
-xx:stringtablesize 在 32 位系统默认为 1009、64 位默认为 60013 ：const int defaultstringtablesize = not_lp64(1009) lp64_only(60013); 。
g1中可以使用 -xx:+usestringdeduplication 参数来开启字符串自动去重功能（默认关闭），并使用 -xx:stringdeduplicationagethreshold 来控制字符串参与去重的 gc 年龄阈值。
与 -xx:stringtablesize 同理，我们可以通过 -xx:symboltablesize 来控制 symboltable 表的长度。
如果我们使用的是 jdk11 之后的 nmt，我们可以直接通过命令 jcmd vm.stringtable 与 jcmd vm.symboltable 来查看两者的使用情况：
stringtable statistics:number of buckets : 16777216 = 134217728 bytes, each 8number of entries : 39703 = 635248 bytes, each 16number of literals : 39703 = 2849304 bytes, avg 71.765total footprsize_t : = 137702280 bytesaverage bucket size : 0.002variance of bucket size : 0.002std. dev. of bucket size: 0.049maximum bucket size : 2symboltable statistics:number of buckets : 20011 = 160088 bytes, each 8number of entries : 20133 = 483192 bytes, each 24number of literals : 20133 = 753832 bytes, avg 37.443total footprint : = 1397112 bytesaverage bucket size : 1.006variance of bucket size : 1.013std. dev. of bucket size: 1.006maximum bucket size : 9
4.9 native memory tracking
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.cppvoid memtracker::init() { nmt_trackinglevel level = tracking_level(); ......}# /hotspot/src/share/vm/services/memtracker.hppstatic 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.cppnmt_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.cppbool 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 方法来根据等级的不同获取不同的数据：
summary 时使用 memsummaryreporter::report() 获取 virtualmemorytracker、mallocmemorysummary 等储存的数据；
detail 时使用 memdetailreporter::report() 获取 virtualmemorytracker、mallocmemorysummary、mallocsitetable 等储存的数据。
# 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 自身占用的内存是比较小的，不需要太过关心。
4.10 arena chunk
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.cppthread::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.hppvoid* 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.cppvoid* 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 codeinline void arena::free_all(char** start, char** end) { for (char** p = start; p < end; p++) if (*p) os::free(*p);}
虽然 jvm 为我们提供了两种方式来管理 arena chunk 的内存：
通过 chunkpool 池化交由 jvm 自己管理；
直接通过 glibc 的 malloc/free 来进行管理。
但是通常意义下我们只会用到第一种方式，并且一般 chunkpool 管理的对象都比较小，整体来看 arena chunk 这块内存的使用不会很多。
4.11 unknown
unknown 则是下面几种情况
当内存类别无法确定时；
当 arena 用作堆栈或值对象时；
当类型信息尚未到达时。
5.nmt 无法追踪的内存
需要注意的是，nmt 只能跟踪 jvm 代码的内存分配情况，对于非 jvm 的内存分配是无法追踪到的。
使用 jni 调用的一些第三方 native code 申请的内存，比如使用 system.loadlibrary 加载的一些库。
标准的 java class library，典型的，如文件流等相关操作（如：files.list、zipinputstream 和 directorystream 等）。
可以使用操作系统的内存工具等协助排查，或者使用 ld_preload malloc 函数的 hook/jemalloc/google-perftools(tcmalloc) 来代替 glibc 的 malloc，协助追踪内存的分配。
基于BMP的图像点阵获取原理及其应用?
“芯火课堂”来了！深圳微纳研究院免费开办微电子培训
基于LM386的低成本音频放大器电路图
安森美半导体推出高能效电机驱动器LV8702V
过载保护器的作用
介绍追踪区域的其它内存类型以及NMT无法追踪的内存
u-blox推出LARA-L6 LTE Cat4紧凑型蜂窝通信模块
App Annie最新发布了2020年度中国厂商的出海榜单
2020年上半年，歌尔股份继续坚持“零件+成品”的发展战略
盘点4家车企的自动驾驶技术
盘点那些“深藏功与名”的AI应用
矿井通风设备远程监控运维系统解决方案
redis几个认识误区
智能安防是智能家居最需要的吗
黑莓KEY2红色国行版发布 新PowerBeats防水耳机将推出
3.25日比特币行情分析三角区间即将告破，风云变幻
使用示波器探头的步骤、技巧和注意事项
Blynk入门指南
新疆5G建设加速 今年将投入20亿建5G基站
雷军发微博晒家乡小米广告牌，网友直呼，这波小米Note3广告打的可以！
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.cppvoid 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.cppvoid 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 argumentvoid 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.cppvoid 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 设置一个更小的值来节省此部分内存，但是削减虚拟机线程的堆栈大小是危险的操作，并不建议去因为此设置这个参数。
4.7 internal
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.cppunsafe_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 bytesdirect allocation: 402653184 bytesnative 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 申请的最大内存。
4.8 symbol
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::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::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 的时间增长。如果发生这种情况，可以调大该值。
-xx:stringtablesize 在 32 位系统默认为 1009、64 位默认为 60013 ：const int defaultstringtablesize = not_lp64(1009) lp64_only(60013); 。
g1中可以使用 -xx:+usestringdeduplication 参数来开启字符串自动去重功能（默认关闭），并使用 -xx:stringdeduplicationagethreshold 来控制字符串参与去重的 gc 年龄阈值。
与 -xx:stringtablesize 同理，我们可以通过 -xx:symboltablesize 来控制 symboltable 表的长度。
如果我们使用的是 jdk11 之后的 nmt，我们可以直接通过命令 jcmd vm.stringtable 与 jcmd vm.symboltable 来查看两者的使用情况：
stringtable statistics:number of buckets : 16777216 = 134217728 bytes, each 8number of entries : 39703 = 635248 bytes, each 16number of literals : 39703 = 2849304 bytes, avg 71.765total footprsize_t : = 137702280 bytesaverage bucket size : 0.002variance of bucket size : 0.002std. dev. of bucket size: 0.049maximum bucket size : 2symboltable statistics:number of buckets : 20011 = 160088 bytes, each 8number of entries : 20133 = 483192 bytes, each 24number of literals : 20133 = 753832 bytes, avg 37.443total footprint : = 1397112 bytesaverage bucket size : 1.006variance of bucket size : 1.013std. dev. of bucket size: 1.006maximum bucket size : 9
4.9 native memory tracking
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.cppvoid memtracker::init() { nmt_trackinglevel level = tracking_level(); ......}# /hotspot/src/share/vm/services/memtracker.hppstatic 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.cppnmt_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.cppbool 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 方法来根据等级的不同获取不同的数据：
summary 时使用 memsummaryreporter::report() 获取 virtualmemorytracker、mallocmemorysummary 等储存的数据；
detail 时使用 memdetailreporter::report() 获取 virtualmemorytracker、mallocmemorysummary、mallocsitetable 等储存的数据。
# 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 自身占用的内存是比较小的，不需要太过关心。
4.10 arena chunk
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.cppthread::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.hppvoid* 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.cppvoid* 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 codeinline void arena::free_all(char** start, char** end) { for (char** p = start; p < end; p++) if (*p) os::free(*p);}
虽然 jvm 为我们提供了两种方式来管理 arena chunk 的内存：
通过 chunkpool 池化交由 jvm 自己管理；
直接通过 glibc 的 malloc/free 来进行管理。
但是通常意义下我们只会用到第一种方式，并且一般 chunkpool 管理的对象都比较小，整体来看 arena chunk 这块内存的使用不会很多。
4.11 unknown
unknown 则是下面几种情况
当内存类别无法确定时；
当 arena 用作堆栈或值对象时；
当类型信息尚未到达时。
5.nmt 无法追踪的内存
需要注意的是，nmt 只能跟踪 jvm 代码的内存分配情况，对于非 jvm 的内存分配是无法追踪到的。
使用 jni 调用的一些第三方 native code 申请的内存，比如使用 system.loadlibrary 加载的一些库。
标准的 java class library，典型的，如文件流等相关操作（如：files.list、zipinputstream 和 directorystream 等）。
可以使用操作系统的内存工具等协助排查，或者使用 ld_preload malloc 函数的 hook/jemalloc/google-perftools(tcmalloc) 来代替 glibc 的 malloc，协助追踪内存的分配。
基于BMP的图像点阵获取原理及其应用?
“芯火课堂”来了！深圳微纳研究院免费开办微电子培训
基于LM386的低成本音频放大器电路图
安森美半导体推出高能效电机驱动器LV8702V
过载保护器的作用
介绍追踪区域的其它内存类型以及NMT无法追踪的内存
u-blox推出LARA-L6 LTE Cat4紧凑型蜂窝通信模块
App Annie最新发布了2020年度中国厂商的出海榜单
2020年上半年，歌尔股份继续坚持“零件+成品”的发展战略
盘点4家车企的自动驾驶技术
盘点那些“深藏功与名”的AI应用
矿井通风设备远程监控运维系统解决方案
redis几个认识误区
智能安防是智能家居最需要的吗
黑莓KEY2红色国行版发布 新PowerBeats防水耳机将推出
3.25日比特币行情分析三角区间即将告破，风云变幻
使用示波器探头的步骤、技巧和注意事项
Blynk入门指南
新疆5G建设加速 今年将投入20亿建5G基站
雷军发微博晒家乡小米广告牌，网友直呼，这波小米Note3广告打的可以！