性能文章>一文了解off-heap堆外内存及性能优化>

一文了解off-heap堆外内存及性能优化转载

1月前
161511

导读


今天给大家聊一个很有意思的知识,就是 off-heap 堆外内存,平时出去面试,或者研究一些技术的时候,经常可能会遇到 off-heap 堆外内存这个东西,但是很多人可能还不知道 off-heap 堆外内存到底是什么,所以今天就给大家来深入的分析一下。

 

正文

on-heap 堆内内存是什么?

要说这个 off-heap 堆外内存,就得先说 on-heap 也就是堆内内存,这个 on-heap 堆内内存相信很多人应该都是熟悉的。

那就是咱们平时写好的 Java 系统其实运行起来就是一个 JVM 进程,这个 JVM 进程是有一块内存空间专门给他用的,这块内存空间就是堆内内存。

大概如下图所示:

11C42A79-A177-4644-A7E7-46A60DE82D8C.png

JVM 堆内存是如何去划分的?

那么这里通常会产生什么问题呢?一般来说没什么大问题,但是如果是遇到要把大量数据缓存在 JVM 堆内存里的时候,就可能会有问题了。

所谓的数据缓存,意思就是说,把很多数据存放在堆内存里,这些数据是要一直用的,所以一般来说不能把他回收掉,所以会导致可能很多数据一直停留在 JVM 的堆内存里。

如下图:

375849A4-4C35-4B34-8FCA-F38EBAF43457.png

那么下一个问题来了,这个 JVM 里的堆内存是有划分的,一块区域是年轻代,一块区域是老年代,像这种缓存数据,因为是长期存在堆内存里的,所以通常会在年轻代里待一段时间,然后因为没法垃圾回收,给放到老年代里去。

此时如下图:

C7980523-9D83-4C15-BDE1-C222D33297AD.png

JVM 堆内存满了后会怎么样?

但是这个老年代里如果放了太多缓存数据以后,就可能会导致他剩余的可用空间就会比较少了,此时可能会导致老年代经常会放一点别的数据就塞满了,一旦塞满了就会触发 JVM 的 Full GC,有一个垃圾回收线程会去回收老年代里的数据。

此时如下图:

DA94C03F-9D8C-4D0C-887D-9877328695DC.png

可是此时一般来说能回收的也就是除了缓存数据之外的一些空间,哪怕你回收了,但是缓存数据是要一直存在的,所以没法回收掉。

此时会导致每次你回收了一部分剩余空间之后,然后还是剩余了很多缓存数据,此时对于缓存数据来说会一直占据老年代的很大空间。

那么此时必然导致一个现象,那就是老年代会频繁的写一点数据就满了,写一点数据就满了,然后一会儿就得触发一下 Full GC。

每次 Full GC 都会导致 JVM 停止运行,没法处理外部请求,此时对外部来说,就会感觉你的系统性能经常抖动,一会卡一下,一会儿卡一下。

所以往往来说,把很多数据缓存在 JVM 内部,是很可能导致上述现象,就是老年代频繁塞满、频繁触发 Full GC、频繁导致系统停顿没法处理请求。

如下图:

9F44EB51-051C-424D-BE29-0212446FE959.png

基于堆外内存解决系统 GC 卡顿问题

所以针对这种情况,往往我们的优化手段,就是会把要缓存的数据,从 JVM 堆内存里转移到 offheap 堆外内存里去,那所以问题来了,啥叫做堆外内存呢?

就是顾名思义,不归 JVM 管的内存区域,OS 操作系统负责管理的一部分内存,叫做堆外内存。

所以我们其实可以选择把很多数据直接写入到堆外内存里去,这样的话,就不会占用 JVM 堆中的老年代空间了,也就不会导致老年代频繁塞满,频繁触发 Full GC,导致系统性能频繁抖动了。

如下图:

3255F539-88B4-4E20-816D-F0A2EC25A968.png

那既然这个堆外内存这么好,问题来了,他有什么缺点呢?

当然有了,因为如果你用的是 JVM 堆内的内存,你写入了很多数据以后,如果内存满了,此时 JVM 会自动进行垃圾回收,帮你释放掉一些内存空间,他是全自动的。

但是如果你用的是堆外内存,那可没有 JVM 来帮你管理了,此时你必须自己管理那块内存空间。

也就是说,你写入了数据以后,到了需要的时候,你得自己注意把部分内存进行释放,所以这就导致了堆外内存虽然不会导致你的 JVM 频繁 GC,但是他可能会导致你的代码管理难度变高。

如下图:

2C026486-062A-41C9-866E-B683CEF457E2.png

那么这个堆外内存一般来说我们用 Java 代码是如何申请的呢?

看下面的代码,一般类似 Netty、RocketMQ 等中间件因为就是要管理大量的内存数据,所以都会选择申请一块堆外内存,把数据放在里面,自己进行精细化的管理。

 

// 定义好要申请的堆外内存的大小,这里是1GB
int memorySize = 1024 * 1024 * 1024;
// 用Java里的ByteBuffer.allocateDirect方法就可以申请一块堆外内存
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(memorySize);
// 把数据写入到堆外内存里去
byte[] bytes = "hello world".getBytes();
byteBuffer.put(bytes);
// 从堆外内存里读取数据
byteBuffer.flip();
byte[] readBytes = new byte[bytes.length];
byteBuffer.get(readBytes, 0, bytes.length);

那大家通过这块代码看到了我们如何申请堆外内存,以及如何往堆外内存里写入数据和如何读取数据之后,现在思考一下,堆外内存我们应该如何进行释放呢?

是这样的,这个堆外内存其实是被 JVM 堆内的一个 ByteBuffer 对象来引用的,所以如果要是 JVM 堆内的 ByteBuffer 对象被回收了,那他关联的堆外内存就会被释放了。

如下图:

F7965D39-75DB-4B68-AB24-36159BA8AD91.png

好了,今天的知识点就分享到这里了,相信大家看完之后应该对堆外内存这个概念有了一个较为清晰的认识了。

请先登录,查看1条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

记一次 Java 服务性能优化
背景前段时间我们的服务遇到了性能瓶颈,由于前期需求太急没有注意这方面的优化,到了要还技术债的时候就非常痛苦了。在很低的 QPS 压力下服务器 load 就能达到 10-20,CPU 使用率 60% 以
代码优化日记 ——火焰图找问题代码
一、问题背景- 排序服务,用于推荐item分数预测,详细项目背景及排序请求执行逻辑可参考之前的一篇文章 :《[性能优化:线程资源回收](https://heapdump.cn/user/708
再聊 TCP backlog
这篇文章我们以 backlog 参数来深入研究一下建连的过程。通过阅读这篇文章,你会了解到下面这些知识:- backlog、半连接队列、全连接队列是什么- linux 内核是如何计算半连接队列、全连接
在被线上大量日志输出导致性能瓶颈毒打了很多次之后总结出的经验
由于线上业务量级比较大(日请求上亿,日活用户几十万),同时业务涉及逻辑很复杂,线上日志级别我们采用的是 info 级别,导致线上日志量非常庞大,经常遇到因为日志写入太慢导致的性能瓶颈(各微服务每小时日
收藏:一些比较好的Redis 性能优化思路总结
在一些网络服务的系统中,Redis 的性能,可能是比 MySQL 等硬盘数据库的性能更重要的课题。比如微博,把热点微博[1],最新的用户关系[2],都存储在 Redis 中,大量的查询击中 Redis
记一次线程池调优经历
原文链接:https://www.cnblogs.com/superfj/p/8313469.html作者:Janti 背景最近的一个项目需要用到招标,临时加了给我们的系统增加了一个性能需求,多少呢?
近期业务大量突增微服务性能优化总结-4.增加对于同步微服务的 HTTP 请求等待队列的监控
最近,业务增长的很迅猛,对于我们后台这块也是一个不小的挑战,这次遇到的核心业务接口的性能瓶颈,并不是单独的一个问题导致的,而是几个问题揉在一起:我们解决一个之后,发上线,之后发现还有另一个的性能瓶颈问
Java性能优化之影响性能的那些细节
 CRUD麻木了吗?被xxx吐槽系统慢吗?你真的了解你的代码吗?今天聊聊一些关于java性能的细节。