ByteBuffer

最新推荐文章于 2023-12-21 17:59:08 发布

weixin_34150224

最新推荐文章于 2023-12-21 17:59:08 发布

阅读量43

点赞数

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/YDDMAX/p/5403267.html

1、堆内：HeapByteBuffer，在java的堆内创建。

缺点：可能引起堆的不断gc

写文件的时候需要先将堆的buffer写进直接buffer里，然后再写入文件

2、堆外：DirectByteBuffer 在堆外创建

优点：写文件不像HeapByteBuffer那样需要先写到直接buffer再写文件。

不会引起频繁的堆gc

缺点：在full gc回收堆外内存的时候可能如果超时可能引起OOM

堆外Buffer的回收是在full gc的时候回收的

3、Netty采取的池化ByteBuffer，性能提高了23倍

http://calvin1978.blogcn.com/articles/directbytebuffer.html

Java的堆外内存本来是高贵而神秘的东西，只在一些缓存方案的收费企业版里出现。但自从用了Netty，就变成了天天打交道的事情，毕竟堆外内存能减少IO时的内存复制，不需要堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中；而且也没了烦人的GC。

好在，Netty所用的堆外内存只是Java NIO的 DirectByteBuffer类，通读一次很快。还有一些sun.misc.*的类木有源码，要自己跑去OpenJdk那看个明白。

1. 堆外内存的创建

在DirectByteBuffer中，首先向Bits类申请额度，Bits类有一个全局的 totalCapacity变量，记录着全部DirectByteBuffer的总大小，每次申请，都先看看是否超限 -- 堆外内存的限额默认与堆内内存(由-XMX 设定)相仿，可用 -XX:MaxDirectMemorySize 重新设定。

如果已经超限，会主动执行Sytem.gc()，期待能主动回收一点堆外内存。然后休眠一百毫秒，看看totalCapacity降下来没有，如果内存还是不足，就抛出大家最头痛的OOM异常。

如果额度被批准，就调用大名鼎鼎的sun.misc.Unsafe去分配内存，返回内存基地址，Unsafe的C++实现在此，标准的malloc。然后再调一次Unsafe把这段内存给清零。跑个题，Unsafe的名字是提醒大家这个类只给Sun自家用的，你们别用，不然哪天Sun把它藏起来了你们就哭死。果然，JDK9里就Oracle可能动手哦。

JDK7开始，DirectByteBuffer分配内存时默认已不做分页对齐，不会再每次分配并清零实际需要＋分页大小(4k)的内存，这对性能应有较大提升，所以Oracle专门写在了Enhancements in Java I/O里。

最后，创建一个Cleaner，并把代表清理动作的Deallocator类绑定 -- 降低Bits里的totalCapacity，并调用Unsafe调free去释放内存。Cleaner的触发机制后面再说。

2. 堆外内存基于GC的回收

存在于堆内的DirectByteBuffer对象很小，只存着基地址和大小等几个属性，和一个Cleaner，但它代表着后面所分配的一大段内存，是所谓的冰山对象。通过前面说的Cleaner，堆内的DirectByteBuffer对象被GC时，它背后的堆外内存也会被回收。

快速回顾一下堆内的GC机制，当新生代满了，就会发生young gc；如果此时对象还没失效，就不会被回收；撑过几次young gc后，对象被迁移到老生代；当老生代也满了，就会发生full gc。

这里可以看到一种尴尬的情况，因为DirectByteBuffer本身的个头很小，只要熬过了young gc，即使已经失效了也能在老生代里舒服的呆着，不容易把老生代撑爆触发full gc，如果没有别的大块头进入老生代触发full gc，就一直在那耗着，占着一大片堆外内存不释放。

这时，就只能靠前面提到的申请额度超限时触发的system.gc()来救场了。但这道最后的保险其实也不很好，首先它会中断整个进程，然后它让当前线程睡了整整一百毫秒，而且如果gc没在一百毫秒内完成，它仍然会无情的抛出OOM异常。还有，万一，万一大家迷信某个调优指南设置了-DisableExplicitGC禁止了system.gc()，那就不好玩了。

所以，堆外内存还是自己主动点回收更好，比如Netty就是这么做的。

3. 堆外内存的主动回收

对于Sun的JDK这其实很简单，只要从DirectByteBuffer里取出那个sun.misc.Cleaner，然后调用它的clean()就行。

前面说的，clean()执行时实际调用的是被绑定的Deallocator类，这个类可被重复执行，释放过了就不再释放。所以GC时再被动执行一次clean()也没所谓。

在Netty里，因为不确定跑在Sun的JDK里(比如安卓)，所以多废了些功夫来确定Cleaner的存在。

4. Cleaner如何与GC相关联？

涨知识的时间到了，原来JDK除了StrongReference，SoftReference 和 WeakReference之外，还有一种PhantomReference，Phantom是幻影的意思，Cleaner就是PhantomReference的子类。

当GC时发现它除了PhantomReference外已不可达（持有它的DirectByteBuffer失效了），就会把它放进 Reference类pending list静态变量里。然后另有一条ReferenceHandler线程，名字叫 "Reference Handler"的，关注着这个pending list，如果看到有对象类型是Cleaner，就会执行它的clean()，其他类型就放入应用构造Reference时传入的ReferenceQueue中，这样应用的代码可以从Queue里拖出这些理论上已死的对象，做爱做的事情——这是一种比finalizer更轻量更好的机制。

5. 其实

专家们说，OpenJDK没有接受jemalloc(redis们在用)的补丁，直接用malloc在OS里申请一段内存，比在已申请好的JVM堆内内存里划一块出来要慢，所以我们在Netty一般用池化的 PooledDirectByteBuf 对DirectByteBuffer进行重用，《Netty权威指南》说性能提升了23倍，所以基本不需要头痛堆外内存的释放，顺便还告别了大数据流量下的频繁GC。

转载于:https://www.cnblogs.com/YDDMAX/p/5403267.html