内存heap
Java正在成为新的C / C ++,它被广泛用于开发高性能系统。 对像我这样的数百万Java开发人员来说非常好!
在这个博客中,我将分享我可以用Java完成的不同类型的内存分配的实验,以及从中获得什么好处。
Java中的内存分配
Java为内存分配提供哪种类型的支持:
–堆内存
我不必解释这一点,所有Java应用程序都以此开头。 使用“ new”关键字分配的所有对象都在“堆内存”下
–非直接字节缓冲区
它是字节数组的包装,只是堆内存的味道。
ByteBuffer.allocate()可用于创建这种类型的对象,如果要处理字节而不是对象,则非常有用。
–直接字节缓冲区
这是Java自JDK 1.4起添加的真实内容。
基于Java Doc的Direct ByteBuffer的描述
“可以通过调用此类的allocateDirect工厂方法来创建直接字节缓冲区。 这种方法返回的缓冲区通常比非直接缓冲区具有更高的分配和释放成本。 直接缓冲区的内容可能驻留在普通垃圾回收堆的外部,因此它们对应用程序内存占用的影响可能并不明显。 因此,建议直接缓冲区主要分配给大型,寿命长的缓冲区,这些缓冲区要受基础系统的本机I / O操作的约束。 通常,最好仅在直接缓冲区产生可观的程序性能提升时才分配它们。”
关于直接缓冲区要注意的重要事项是
- 它在JVM之外
- 远离垃圾收集器。
如果您关心性能,这些都是非常重要的事情。
MemoryMapped文件也具有Direct字节缓冲区的风格,我在以下博客中与我分享了一些发现:
堆或直接内存
这几乎与Direct ByteBuffer相同,但是几乎没有什么不同,它可以由unsafe.allocateMemory分配,因为它是直接内存,因此不会产生GC开销。 这种类型的内存必须手动释放。
从理论上讲,不允许Java程序员进行这种分配,我认为原因可能是
- 操作这种类型的内存很复杂,因为您只处理字节而不是对象
- C / C ++社区不会喜欢它
让我们深入研究内存分配
对于内存分配测试,我将使用13字节的消息,并将其分解为
- int – 4字节
- 长– 8字节
- 字节– 1字节
我只会测试写入/读取性能,而不会测试内存消耗/分配速度。
写性能
X轴 –没有读数
Y轴 -运算/秒(百万)
使用4种分配类型写入500万个13字节对象。
- 在这种情况下,最好使用Direct ByteBuffer和Off Heap,吞吐量接近
- 3.5亿/秒
- 普通的ByteBuffer非常慢,TP仅为8500万/秒
- Direct / Off堆比堆快1.5倍
我对5000万个对象进行了相同的测试,以检查其缩放比例,以下是相同的图形。
X轴 –没有读数 Y轴 -运算/秒(百万) 数字几乎等于500万。
阅读表现
让我们看一下阅读性能
X轴 –没有读数 Y轴 -运算/秒(百万) 这个数字很有趣,OFF堆正在为12,000 Mills / Sec快速吞吐。 HEAP读取仅接近一次,比OFF Heap慢6倍左右。 看一下Direct ByteBuffer,它的传输速度仅为4亿/秒,不知道为什么会这样。
让我们看看5000万个对象的数量
X轴 –没有读数 Y轴 -运算/秒(百万) 没有太大的不同。
结论
通过Unsafe进行的堆外业务以330/11200百万/秒的速度快速燃烧。
所有其他类型的分配的性能对读取或写入均有利,而所有分配均不适用于两者。
关于ByteBuffer的特别说明,可悲的是,我确定看到这样的数字后您将不会使用它。 DirectBytebuffer的读取速度很慢,我不确定为什么它这么慢。
因此,如果内存读/写正在成为您系统中的瓶颈,那么肯定要走“堆外”方式,请记住这是高速公路,因此请谨慎驾驶。
代码可用@ git hub
翻译自: https://www.javacodegeeks.com/2013/08/which-memory-is-faster-heap-or-bytebuffer-or-direct.html
内存heap