今天从实战角度分析JVM源码，首先：
1、使用 SourceInsight 来查看 OpenJDK 源代码
如何查看可以见一下文档。工具使用的 SourceInsight
https://cloud.tencent.com/developer/article/1585224
这个会耗时久点，但是可以关联全部的。
2、应用分析场景、堆外内存默认是多大
如果我们没有通过 -XX:MaxDirectMemorySize 来指定最大的堆外内存，那么默认的最大堆外内存是多少呢？
一般来说，如果没有显示的设置 -XX:MaxDirectMemorySize 参数，通过 ByteBuffer 能够分配的直接内存空间大小就是堆的最大大小。
对应参数-Xmx，真的是这么样吗？
案例分析：
1、 VM参数配置：-XX:MaxDirectMemorySize=100m；
2、 VM参数配置：-XX:MaxDirectMemorySize=128m；
3、 VM参数配置：-Xmx128m；
这个地方居然报错了，果然童话里都是骗人的。
4、 VM参数配置：-Xmx135m-Xmn100m-XX:SurvivorRatio=8；
5、 VM参数配置：-Xmx138m-Xmn100m-XX:SurvivorRatio=8；
几个案例分析，我们得出以下结论：
没有显示的设置-XX:MaxDirectMemorySize 参数，通过 ByteBuffer 能够分配的直接内存空间大小就是堆的最大大小。 这句话是有问题的。 问题在哪里，应该是没有显示的设置-XX:MaxDirectMemorySize 参数，通过 ByteBuffer 能够分配的直接内存空间大小就是堆的最大的 可使用 的大小。
堆的最大的 可使用 的大小= 堆的最大值- 一个 Survivor 的大小(浪费的空间)，所以案例 4 为什么会 OOM！
堆的最大的可使用的大小=135-10m=125m ,不能分配 128M 的对象
所以案例 5 为什么不会 OOM！ 堆的最大的可使用的大小=138-10m=128m ,刚好可以分配 128M 的对象
6、源码分析
我们从代码出发，依次来找
7、 看到上面的代码之后不要误以为默认的最大值是64M？其实不是的；
说到这个值得从 java.lang.System 这个类的初始化说起 上 面 这 个 方 法 在 jvm 启 动 的 时 候 对 System 这 个 类 做 初 始 化 的 时 候 执 行 的 ， 因 此 执 行 时 间 非 常 早 ， 我 们 看 到 里 面 调 用 了
sun.misc.VM.saveAndRemoveProperties(props):
8、 这个地方是一个native方法，这个是一个本地方法，本地方法里面怎么实现的这个地方就需要看JVM的源码；
像这种本地方法，在 VM 的源码中一般都是会把包名加上，因为是给 java 用的所以前缀上还有一个 java。
大致推算出（其实已经知道了）是 JVM 的这个函数 ： Java_java_lang_Runtime_maxMemory
9、 这个容量其实就是每一个代的大小相加，比如YGen+OldGen之类；
10、 在这里可以看到，新生代的最大值=新生代的最大值-一个survivor的大小；
为什么会这样，因为在新生代采用复制回收算法，一个幸存者区域是浪费的，所以实际空间最大大小要减去一个交换器的大小。
而老年代是没有空间浪费的，所以还是全区域。 也得出我们设置的-Xmx 的值里减去一个 survivor 的大小就是默认的堆外内存的大小。
11、总结
读JVM 的源码确实可以解决不少问题，但读 JVM 的源码门槛很高（ C++ 的基础），同时 JVM 的源码体系非常大，如果想学源码的话，可以参考今天这个 场景，从场景切入（找几个简单的场景），读源码要有目的，这样才能做到有的放矢，才能真正的提高自己的技术水平。