博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
ByteBuffer中allocate 与allocatDirect 不同之处?
阅读量:6670 次
发布时间:2019-06-25

本文共 864 字,大约阅读时间需要 2 分钟。

在NIO中,使用ByteBuffer分配缓存区的方式有哪些?

一、创建Buffer对象的方式?

1、JVM堆中分配内存,

2、也可以OS本地内存中分配,由于本地缓冲区避免了缓冲区复制,在性能上相对堆缓冲区有一定优势,但同时也存在一些弊端。

二、两种缓冲区对应的API如下:

1、JVM堆缓冲区:ByteBuffer.allocate(size)

2、本地缓冲区:ByteBuffer.allocateDirect(size)//属于系统级的内存开销,就是操作系统直接分配的

三、ByteBuffer对象的垃圾回收策略?

1、从堆中分配的缓冲区为普通的Java对象,生命周期与普通的Java对象一样,当不再被引用时,Buffer对象会被回收。

2、直接缓冲区(DirectBuffer)为本地内存,并不在Java堆中,也不能被JVM垃圾回收。由于直接缓冲区在JVM里被包装进Java对象DirectByteBuffer中,当它的包装类被垃圾回收时,会调用相应的JNI方法释放本地内存,所以本地内存的释放也依赖于JVMDirectByteBuffer对象的回收。

 

由于垃圾回收本身成本较高,一般JVM在堆内存未耗尽时,不会进行垃圾回收操作。我们知道在32位机器上,每个进程的最大可用内存为4G,用户可用内存在大概为3G左右,如果为堆分配过大的内存时,本地内存可用空间就会相应减少。当我们为堆分配较多的内存时,JVM可能会在相当长的时间内不会进行垃圾回收操作,从而本地内存不断分配,无法释放,最终导致OutOfMemoryError

 

四、总结:

1、堆缓冲区的性能已经相当高,若无必要,使用堆缓冲区足矣。若确实有提升性能的必要时,再考虑使用本地缓冲区。

2、JVM分配堆内存时,并不是越大越好,堆内存越大,本地内存就越小,根据具体情况决定,主要针对32位机器,64位机器上不存在该问题。

本文转自故新51CTO博客,原文链接:http://blog.51cto.com/xingej/1967948 ,如需转载请自行联系原作者

你可能感兴趣的文章
全面剖析SharedPreferences
查看>>
0826 - 事情多到让人绝望啊
查看>>
Logback中使用TurboFilter实现日志级别等内容的动态修改
查看>>
Spring Boot中增强对MongoDB的配置(连接池等)
查看>>
网络安全-CSRF
查看>>
Andorid Studio NDK开发-Hello World
查看>>
IDEA中maven工程指定JDK版本
查看>>
Git 详细的操作指南笔记(从零开始)
查看>>
【手把手带你撸一个脚手架】第二步, 搭建开发环境
查看>>
JS专题之严格模式
查看>>
Python设计模式-装饰器模式
查看>>
前端每周清单第 30 期:WebVR 指南,Vue 代码分割范式,理想的 React 架构特性
查看>>
C 语言结构体内存布局问题
查看>>
js 数组排序
查看>>
iOS VIPER架构实践(一):从MVC到MVVM到VIPER
查看>>
Android鬼点子-近期项目总结(2)-日历
查看>>
是时候学习真正的 spark 技术了
查看>>
android开发怎么少的了后端(上)
查看>>
android应用检测更新
查看>>
从硅谷到杭州:一个海归的阿里故事
查看>>