一图解千愁，jvm内存从来没有这么简单过！
原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。
看到这张图的同学，千万不要到处分享。我们仅限于小范围讨论，因为这张图威力很大，是我花了10年时间才画出来的！
了解了这张图，会让你对JVM内存的划分有更深入的理解，而不仅限于什么虚拟机栈、程序计数器等比较浅显的认知。
那么这张图有什么用呢？在进行内存排查的时候，我们需要了解到底是哪一个部分除了问题。如果你找不对地方，肯定切入就比较困难，这会耗费你大量的精力。
一台4GB的机器，一般使用Xmx分配给JVM的，肯定不能太多。比如3.5GB之类的。这就太贪婪了，很容易造成JVM异常死亡。这是为什么呢？
这个比较好理解，因为在操作系统上，运行的不仅仅你的JVM应用，还会有其他一些守护进程，比如各种日志收集工具、监控工具、安全工具等。它们虽然占用的内存不是很多，但累加起来还是比较可观的。JVM内存和操作系统的剩余内存是一个此消彼长的关系，这些小内存挤占了JVM的发挥空间，就容易出问题。
JVM是我们的主体，所以要把它放在主人公的位置。这种划分方式，就可以把整个内存搞成JVM内存、操作系统物理内存、SWAP三个部分。
当JVM和其他程序占满了物理内存，接着占满了SWAP内存（交换分区一般不开，这个一会在说），当在需要申请内存空间的时候，操作系统发现：完蛋了，没有可用的内存空间了。
这个时候，Linux会启动oom-killer，杀死占用内存最大的进程，这个时候大概率是你可爱的JVM宝贝进程。
这里的oom，指的是操作系统的，而不是JVM的。所以你会发现：你的java进程死了，但是什么都没有留下。就这么静悄悄的去了。
这些信息，只能通过dmesg命令找到，属于操作系统范畴。
那么接下来，我们就上一下最主要的一张图，然后解释一下这十几部分都是干什么的。
我们依然把内存分为上面的三部分，但是对JVM的进程内存进行更细致的划分。
首先，对于JVM的内存，有堆内内存和堆外内存之分。
对于堆内内存，是我们平常打交道最多的地方，因为我们大部分Java对象，都是在堆上分配的。一旦有溢出问题，使用jmap + mat等一系列猛如虎的操作，就可以方便快捷的发现问题。
这是一个Java好手都能掌握的技能。
关键就是堆外内存那一部分，就十分的蛋疼了。因为杂七杂八的东西都在这里，很容易搞混。
可以看到，对于这部分的内存问题，即使是JVM界最权威的周老师的书籍，依然也有相关的错误。
这段代码的运行结果其实是错误的，这里的unsafe，并不是直接内存。
那我们就盘点一下里面都有些啥。
第一，元空间
元空间是jdk8以后才加入的，用来替换原来的永久代。也就是说，原perm区（永久代）中的方法区，也在这里。从它原来的名字就可以看出来，永久代指的就是那些变动很少的数据，稳定为主。比如我们在jvm启动时，加载的那些class文件；以及在运行时，动态生成的代理类。
比较坑的是，元空间的大小，默认是没有上限的。极端情况下，会一直挤占操作系统的剩余内存。
第二、CodeCache
很多文章对着一部分的介绍非常少，但其实这也是非常重要的一个非堆区域。因为JIT是JVM一个非常重要的特性，CodeCahe存放的，就是即时编译器所生成的二进制代码。当然，JNI的代码也是放在这里的。
这个空间在不同的平台，大小都是不一样的，但一般够用了。也有同学手贱把这个区域调的非常的小，这种情况下，JVM不会溢出，这个区域也不会溢出，但是会退化成解释型执行模式，速度和JIT不可同日而语，慢个数量级也是可能的。
本地内存
其实，在聊天的时候，我们相互谈到的堆外内存，大部分指的是这里，大部分出问题的，也是这里。它有更细致的划分。
（1）网络内存
网络连接也是要占用很多内存的。这个连接就非常有意思，你可以认为它是操作系统内核所占用的内存，也可以认为是JVM进程占用的内存。
如果你的系统并发非常高，这部分内存的占用也是比较多的。因为连接一般对应着网卡的数据缓冲区，还有文件句柄的耗费。
（2）线程内存
同样的，如果你造的线程非常多，JVM除了占用Thread对象本身很小的一部分堆内存，大部分是以轻量级进程的方式存在于操作系统。
这同样是一个积少成多的内存区域，但一般不会发生问题。
（3）JNI内存
上面谈到CodeCache存放的JNI代码，JNI内存就是指的这部分代码所malloc的具体内存。
比如Java的zip库，就不是在JVM的堆里完成的，而是开辟了一个堆外的缓冲池进行运算。
（4）直接内存
直接内存，指的是使用了Java的直接内存API，进行操作的内存。这部分内存可以受到JVM的管控，比如ByteBuffer类所做的事情。
ByteBuffer底层是用的unsafe,但unsafe是不受直接内存的管控的，它们不是一个东西。
上面提到的书中直接使用unsafe程序，并不会造成JVM直接内存溢出，反而会造成操作系统内存溢出。
那这些内存我们如何看到呢？
linux下有一个命令lsof，可以看到JVM进程所关联的所有句柄信息，一般可作为参考。
近一步，使用pmap函数，即可观测到具体的内存分布。但是不要怕，有很多是共享内存。
这个具体的过程，可以参见之前写的一篇堆外内存排查的文章。
如果你了解了图中这些内存划分，就会很容易了解，为什么NMT工具无法显示JNI内存的统计。
接下来，我们总结一下，这些内存区域，哪些参数能够控制它们。
堆 -Xmx-Xms元空间 -XX:MaxMetaspaceSize-XX:MetaspaceSize栈 -Xss直接内存 -XX:MaxDirectMemorySizeJIT编译后代码存放 -XX:ReservedCodeCacheSize其他堆外内存 无法控制！随缘吧。
可以看到，堆外内存的占用，其实还是比较多的。如果你太贪婪，整个内存很容易就玩玩。
一般的，我们使用操作系统的2/3作为堆空间，是比较合理的。这是一个经验值。比如6GB的内存，你分配给JVM的，最好不要超过4GB。
还有，我们上面谈到的swap交换分区，在高并发应用中，一般是关掉的。因为它会造成频繁的页交换，在GC的时候，会引起严重的卡顿。
但要辩证的思维看待问题。对于低频的，对内存大小有非常大的依赖的情况下，SWAP不仅要开，还要开的大一些。
作者简介：小姐姐味道 (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流。
近期热门文章
《传统企业的人才们，先别忙着跳“互联网”！》
对2B和2C的一些思考
《Serverless，会将工程师带入“不归路”！》
介绍Serverless，以及一些展望
《必看！java后端，亮剑诛仙》
后端技术索引，中肯火爆。全网转载上百次。
《学完这100多技术，能当架构师么？（非广告）》
精准点评100多框架，帮你选型