你好，我是范学雷。今天，我们来讨论Java的外部内存接口。
Java的外部内存接口这个新特性，现在还在孵化期，还没有发布预览版。我之所以选取了这样一个还处于孵化期的技术，主要是因为这个技术太重要了。我们需要提前认识它；然后在这项技术出来的时候，尽早地使用它。
我们从阅读案例开始，看一看Java在没有外部内存接口的时候，是怎么支持本地内存的；然后，我们再看看外部内存接口能够给我们的代码带来什么样的变化。
在我们讨论代码性能的时候，内存的使用效率是一个绕不开的话题。像TensorFlow、 Ignite、 Flink以及Netty这样的类库，往往对性能有着偏执的追求。为了避免Java垃圾收集器不可预测的行为以及额外的性能开销，这些产品一般倾向于使用JVM之外的内存来存储和管理数据。这样的数据，就是我们常说的堆外数据（off-heap data）。
使用堆外存储最常用的办法，就是使用ByteBuffer这个类来分配直接存储空间（direct buffer）。JVM虚拟机会尽最大努力直接在直接存储空间上执行IO操作，避免数据在本地和JVM之间的拷贝。
由于频繁的内存拷贝是性能的主要障碍之一。所以为了极致的性能，应用程序通常也会尽量避免内存的拷贝。理想的状况下，一份数据只需要一份内存空间，这就是我们常说的零拷贝。
下面的这段代码，就是用ByteBuffer这个类来分配直接存储空间的方法。
public static ByteBuffer allocateDirect(int capacity);
ByteBuffer所在的Java包是java.nio。从这个Java包的命名我们就能感受到，ByteBuffer设计的初衷是用于非阻塞编程的。的确，ByteBuffer是异步编程和非阻塞编程的核心类，几乎所有的Java异步模式或者非阻塞模式的代码，都要直接或者间接地使用ByteBuffer来管理数据。
非阻塞和异步编程模式的出现，起始于对于阻塞式文件描述符（File descriptor）（包括网络套接字）读取性能的不满。而诞生于2002年的ByteBuffer，最初的设想也主要是用来解决当时文件描述符的读写性能的。所以，它的设计也不能跳脱出当时的客观需求。
如果站在现在的角度重新审视这个类的设计，我们会发现它主要有两个缺陷。
第一个缺陷是没有资源释放的接口。一旦一个ByteBuffer实例化，它占用了内存的释放，就会完全依赖JVM的垃圾回收机制。使用直接存储空间的应用，往往需要把所有潜在的性能都挤压出来。依赖于垃圾回收机制的资源回收方式，并不能满足像Netty这样的类库的理想需求。
第二个缺陷是存储空间尺寸的限制。ByteBuffer的存储空间的大小，是使用Java的整数来表示的。所以，它的存储空间，最多只有2G。这是一个无意带来的缺陷。在网络编程的环境下，这并不是一个问题。可是，超过2G的文件，一定会越来越多；2G以上的文件，映射到ByteBuffer上的时候，就会出现文件过大的问题。而像Memcahed这样的分布式内存，也会让应用程序需要控制的内存超越2G的界限。
这两个缺陷，也是横隔在“零拷贝”这个理想路上的两个主要设计障碍。
对于第一个缺陷，我们还可以在ByteBuffer的基础上修改，并且保持这个类的优雅。但是第二个缺陷，由于ByteBuffer类里到处都在使用的整数类型，我们就很难找到办法既保持这个类的优雅，又能够突破存储空间的尺寸限制了。
一个合理的改进，就是重新建造一个轮子。这个新的轮子，就是外部内存接口。
外部内存接口沿袭了ByteBuffer的设计思路，但是使用了全新的接口布局。我们先来看看使用外部内存接口的代码看起来是什么样子的。下面的这段代码，要分配一段外部内存，并且存放4个字母A。
try (ResourceScope scope = ResourceScope.newConfinedScope()) {MemorySegment segment = MemorySegment.allocateNative(4, scope);for (int i = 0; i < 4; i++) {MemoryAccess.setByteAtOffset(segment, i, (byte)'A');}}
现在，我们通过这个小例子，来看看外部内存接口的布局。
第一行的ResourceScope这个类，定义了内存资源的生命周期管理机制。这是一个实现了AutoCloseable的接口。我们就可以使用try-with-resource这样的语句，及时地释放掉它管理的内存了。这样的设计，就解决了ByteBuffer的第一个缺陷。
第二行的MemorySegment这个类，定义和模拟了一段连续的内存区域。第三行的MemoryAccess这个类，定义了可以对MemorySegment执行读写操作。在ByteBuffer的设计里，内存的表达和操作，是在ByteBuffer这一个类里完成的。在外部内存接口的设计里，把对象表达和对象的操作，拆分成了两个类。这两类的寻址数据类型，使用的是长整形（long）。这样，长整形的寻址类型，就解决了ByteBuffer的第二个缺陷。
无论是在我们生活的现实世界里，还是在软件的虚拟世界里，只要我们超前迈出了第一步，后续的发展往往会超出我们的预料。外部内存接口的出现，虽然还处在孵化期，也带来了远远超出预期的精彩局面。
在计算机的世界里，代码主要和两类计算资源打交道。一类是负责控制和运算的处理器；一类是临时存放运算数据的存储器。表现到编程语言的层面，就是函数和内存。函数之间的数据传递，也是用过内存的形式进行的。
现在，外部内存接口为我们提供了一个统一的内存操作接口。对应地，外部函数之间的数据传递问题也就有了思路。既然能够解决函数之间的数据传递问题，那么，不同语言间的函数调用能不能变得更简单、更有效率呢？
这个问题，就是我们下一次要讨论的内容。如果说，设计外部内存接口的最初动力是为了解决ByteBuffer的两个缺陷。那研发的持续推进，则给外部内存接口赋予了更大的责任和能量。
好，到这里，我来做个小结。前面，我们讨论了Java的外部内存接口这个尚处于孵化阶段的新特性，对外部内存接口这个新特性有了一个初始的印象。
设计外部内存接口的最初动力，是为了解决ByteBuffer的两个缺陷。也就是ByteBuffer占用的资源不能及时释放，以及它的寻址空间太小这两个问题。但是外部内存接口的更大使命，是和外部函数接口联系在一起的。我们下一次再讨论这个更大的使命。
如果外部内存接口正式发布出来，现在使用ByteBuffer的类库（比如Flink和Netty，甚至JDK本身），应该可以考虑切换到外部内存接口来获取性能的提升。
这一次学习的主要目的，就是让你对外部内存接口有一个基本的印象。由于外部内存接口尚处于孵化阶段，现在我们还不需要学习它的API。只要知道Java有这个发展方向，能够了解ByteBuffer的这两个缺陷能够给你的程序带来的影响就足够了。
如果面试中聊到了ByteBuffer，你应该可以聊一聊零拷贝，以及ByteBuffer的这两个缺陷，还有未来的Java要做的改进。
其实，今天的这个新特性，也是练习使用JShell快速学习新技术的一个好机会。我们在前面的讨论里，分析了下面的这段代码。为了方便你阅读，我把这段代码重新拷贝到下面了。
try (ResourceScope scope = ResourceScope.newConfinedScope()) {MemorySegment segment = MemorySegment.allocateNative(4, scope);for (int i = 0; i < 4; i++) {MemoryAccess.setByteAtOffset(segment, i, (byte)'A');}}
虽然我们提到了使用try-with-resource这样的语句，可以及时地释放掉它管理的内存。但是，我们并没有验证这一说法。你能不能使用JShell，快速地验证它的资源释放效果呢？
需要注意的是，要想使用孵化期的JDK技术，需要在JShell里导入孵化期的JDK模块。就像下面的例子这样。
$ jshell --add-modules jdk.incubator.foreign -v| Welcome to JShell -- Version 17| For an introduction type: /help introjshell> import jdk.incubator.foreign.*;
欢迎你在留言区留言、讨论，分享你的阅读体验以及你的设计和代码。我们下节课见！
注：本文使用的完整的代码可以从GitHub下载，你可以通过修改GitHub上review template代码，完成这次的思考题。如果你想要分享你的修改或者想听听评审的意见，请提交一个 GitHub的拉取请求（Pull Request），并把拉取请求的地址贴到留言里。这一小节的拉取请求代码，请在外部内存接口专用的代码评审目录下，建一个以你的名字命名的子目录，代码放到你专有的子目录里。比如，我的代码，就放在memory/review/xuelei的目录下面。