松松2021-12-10jshell> 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 判断。展开作者回复: 像是范例，谢谢！
6
小飞同学2021-12-14为什么ByteBuffer最大内存是2G？不应该是2^32/2^30=4GB的内存么，没有找到一个合适的解释作者回复: 有一位要留给符号，所以只有31位。
2
aoe2021-12-10知道了大名鼎鼎的ByteBuffer有两个缺陷： 1. 没有资源释放的接口 2. 存储空间尺寸的限制。ByteBuffer 的存储空间的大小，是使用 Java 的整数来表示的。所以，它的存储空间，最多只有 2G。 虽然没有直接使用过ByteBuffer，但依然感觉很厉害的样子。 外部内存接口看起来更厉害啊！作者回复: 虽然还在孵化期，还是值得期待的。
2
ABC2021-12-13老师，我看这两天Log4j2遇到的漏洞就跟JNI有关,可以大概讲一下吗,谢谢.作者回复: 这几天太忙了，没顾上看细节。 等我忙过了这一段时间，看看能不能了解一下这个漏洞的技术细节。
1- ABC2021-12-12我看到外部内存接口在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的工具.展开
作者回复: “第二阶段孵化”，接口会越来越简单。孵化期的接口，验证可行性是一个重要的目标。 “一般在业务系统中不推荐直接操作外部内存吧？”， 这个问题，看我们怎么定义业务系统。一般情况下，会有一层封装，隐藏起来实现的细节。 IDLE这样的工具，很难出现在JDK里。市面已经有非常出色的IDE了，比如IDEA，不再需要另起炉灶了。JDK要解决的，主要还是编程语言和标准类库，其他的事情，应该交给社区和生态来做。
1 
周周周文阳 ...2022-12-18 来自美国https://blog.csdn.net/qq_43284469/article/details/126551473 该篇博客除作者名字变更，其他只字未动作者回复: 哈哈，这个喜欢吃黄桃的阿昌作者还是一个超级搬运工，把这个专栏的文章搬的差不多了。
发光如星2022-01-14说实话，jdk11的新特性都不太清楚有哪些，老师有没有这方面的资料作者回复: 看JDK 11的release notes
Jxin2021-12-141.提个问题：为什么新的直接内存管理，将生命周期/数据承接/数据操作拆分成了3个类来实现？分成3个类也行，但使用方感知3个类是不是有点不合适？ java因为有jvm对对象做统一的生命周期管理，所以一般java的对象并不包含生命周期这块的逻辑。ResourceScope 的命名其实没有局限在直接内存，所以感觉这个可能是一个公用的独立做对象生命周期管理的玩意。如果是公用的，那么这个独立出来确实是合理的。但是数据承接和数据操作分两个类就有点看不懂了，行为跟着数据走，为啥要拆开？也许行为的实现相对独立，例如迭代器，单独类也合理。但暴露给使用方操作两个类就不合理了，因为操作可以也应该包在MemorySegment内部。或许是为了灵活组合不同操作？在可读性优先的前提下，有时保持愚钝的通过多个子类分隔逻辑，达到隔离场景的效果比灵活更有价值。 2.外部函数之间的数据传递问题，之前考虑过这个问题。服务网格边车模式依赖网络拦截重发实现两个进程间的交互。如果借助外部直接内存，是否可以实现同样的效果？感觉可以，而且可以不再占用网络资源。应该是挺大的提升。但马上又有问题冒出来了，进程间直接内存抢占怎么办？安全问题怎么办？展开作者回复: 第一个问题，虽然我觉得数据和操作拆分各有利弊，现在我还看不到拆分成两个类的优势。也许是为了操作的可扩展性/灵活性，但是现在的设计还没有体现出来需要这样的灵活性。孵化期的API，离最终定版还有很大的一段距离。 第二个问题，这些资源竞争和安全的问题，都可以通过实现细节屏蔽起来。这也是我能想到的第一个问题里类拆分的一个可能性，但是我还没有看到朝着个方向走的样子。
共 2 条评论
Ankhetsin2021-12-12java和别的不同语言是不是用JNI和JNA？作者回复: JNI就是我们说的本地接口。
共 2 条评论
ifelse
2022-10-12 来自浙江理想的状况下，一份数据只需要一份内存空间，这就是我们常说的零拷贝。--记下来