12 | 外部内存接口：零拷贝的障碍还有多少？

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'); ...> } ...> for (int i = 0; i < 4; i++) { ...> System.out.println(MemoryAccess.getByteAtOffset(segment, i)); ...> } ...> } 65 65 65 65 jshell> MemorySegment segment; segment ==> null | 已创建 变量 segment : MemorySegment jshell> try (ResourceScope scope = ResourceScope.newConfinedScope()) { ...> segment = MemorySegment.allocateNative(4, scope); ...> for (int i = 0; i < 4; i++) { ...> MemoryAccess.setByteAtOffset(segment, i, (byte)'A'); ...> } ...> } jshell> for (int i = 0; i < 4; i++) { ...> System.out.println(MemoryAccess.getByteAtOffset(segment, i)); ...> } | 异常错误 java.lang.IllegalStateException：Already closed | at ConfinedScope.checkValidState (ConfinedScope.java:57) | at ScopedMemoryAccess.getByteInternal (ScopedMemoryAccess.java:480) | at ScopedMemoryAccess.getByte (ScopedMemoryAccess.java:470) | at MemoryAccessVarHandleByteHelper.get (MemoryAccessVarHandleByteHelper.java:114) | at MemoryAccess.getByteAtOffset (MemoryAccess.java:105) | at (#6:2) 在 try-with-resource 内阔以访问，否则报 IllegalStateException: Already closed。 如果更严谨些，阔以从 MemoryAddress 判断。

为什么ByteBuffer最大内存是2G？不应该是2^32/2^30=4GB的内存么，没有找到一个合适的解释

知道了大名鼎鼎的ByteBuffer有两个缺陷： 1. 没有资源释放的接口 2. 存储空间尺寸的限制。ByteBuffer 的存储空间的大小，是使用 Java 的整数来表示的。所以，它的存储空间，最多只有 2G。 虽然没有直接使用过ByteBuffer，但依然感觉很厉害的样子。 外部内存接口看起来更厉害啊！

老师，我看这两天Log4j2遇到的漏洞就跟JNI有关,可以大概讲一下吗,谢谢.

我看到外部内存接口在JDK18开启了第二阶段孵化,变化包括: * 在内存访问var句柄中支持更多的载体，例如booleanand MemoryAddress； * 更通用的取消引用 API，可在MemorySegment和MemoryAddress接口中使用； * 一个更简单的 API 来获取向下调用方法句柄，MethodType不再需要传递参数； * 一个更简单的 API 来管理资源范围之间的时间依赖性； * 用于将 Java 数组复制到内存段和从内存段复制的新 API。 到正式发布估计还要一段时间. 有个疑问,想请教一下老师,一般在业务系统中不推荐直接操作外部内存把? 另外还有个有意思的特性,JDK计划在后续版本中删除JDK中的所有finalize()方法.其中最著名的是: java.lang.Object.finalize(). 大概要经历下面的步骤: JDK 的未来版本可能包括以下部分或全部更改： 1. 在使用终结器时在运行时发出警告， 2. 默认情况下禁用终结，可以选择重新启用它， 3. 稍后，删除终结机制，同时保留不起作用的 API， 4. 最后，在迁移大部分代码后，删除上述最终弃用的方法，包括Object::finalize. 我觉得Python自带的IDLE像一个简单的代码编辑器,不清楚JDK后续是否会提供一个类似IDLE的工具.

https://blog.csdn.net/qq_43284469/article/details/126551473 该篇博客除作者名字变更，其他只字未动

说实话，jdk11的新特性都不太清楚有哪些，老师有没有这方面的资料

1.提个问题：为什么新的直接内存管理，将生命周期/数据承接/数据操作拆分成了3个类来实现？分成3个类也行，但使用方感知3个类是不是有点不合适？ java因为有jvm对对象做统一的生命周期管理，所以一般java的对象并不包含生命周期这块的逻辑。ResourceScope 的命名其实没有局限在直接内存，所以感觉这个可能是一个公用的独立做对象生命周期管理的玩意。如果是公用的，那么这个独立出来确实是合理的。但是数据承接和数据操作分两个类就有点看不懂了，行为跟着数据走，为啥要拆开？也许行为的实现相对独立，例如迭代器，单独类也合理。但暴露给使用方操作两个类就不合理了，因为操作可以也应该包在MemorySegment内部。或许是为了灵活组合不同操作？在可读性优先的前提下，有时保持愚钝的通过多个子类分隔逻辑，达到隔离场景的效果比灵活更有价值。 2.外部函数之间的数据传递问题，之前考虑过这个问题。服务网格边车模式依赖网络拦截重发实现两个进程间的交互。如果借助外部直接内存，是否可以实现同样的效果？感觉可以，而且可以不再占用网络资源。应该是挺大的提升。但马上又有问题冒出来了，进程间直接内存抢占怎么办？安全问题怎么办？

java和别的不同语言是不是用JNI和JNA？

理想的状况下，一份数据只需要一份内存空间，这就是我们常说的零拷贝。--记下来