DisableExplicitGC和Direct ByteBuffer研究

最新推荐文章于 2025-05-12 16:12:36 发布
转载 最新推荐文章于 2025-05-12 16:12:36 发布 · 1.5k 阅读 · 1
文章标签：

#jvm #堆外内存 #DirectByteBuffer

本文探讨了DisableExplicitGC标志如何影响System.gc()调用，防止其触发full GC，以及在Oracle/Sun JDK中DirectByteBuffer的内存管理机制。强调了在使用DirectByteBuffer时，DisableExplicitGC可能导致的direct memory OOM问题，并提供了相应的解决方案。

目录：

1. DisableExplicitGC介绍

2. Direct  ByteBuffer介绍

 

一，DisableExplicitGC介绍

-XX:+DisableExplicitGC标志自动将System.gc()调用转换成一个空操作，就是应用中调用System.gc()会变成一个空操作。最主要的原因是为了防止某些手贱的同学在代码里到处写System.gc()的调用而干扰了程序的正常运行吧。有些应用程序本来可能正常跑一天也不会出一次full GC，但就是因为有人在代码里调用了System.gc()而不得不间歇性被暂停。

应用中调用System.gc()会有啥影响？

在Oracle/Sun JDK这个具体实现上，System.gc()的默认效果是引发一次stop-the-world的full GC，对整个GC堆做收集，对于应用的影响可想而知。

DisableExplicitGC这个设置了会有啥坑？

其中一种情况是下述三个条件同时满足时会发生的： 

1、应用本身在GC堆内的对象行为良好，正常情况下很久都不发生full GC； 

2、应用大量使用了NIO的direct memory，经常、反复的申请DirectByteBuffer 

3、使用了-XX:+DisableExplicitGC 

二，Direct  ByteBuffer介绍

注意事项：

1、DirectByteBuffer没有finalizer，它的native memory的清理工作是通过sun.misc.Cleaner自动完成的。 

2、sun.misc.Cleaner是一种基于PhantomReference的清理工具，比普通的finalizer轻量些。

做full GC的话会对old gen做reference processing，进而能触发Cleaner对已死的DirectByteBuffer对象做清理工作。

而如果很长一段时间里没做过GC或者只做了young GC的话则不会在old gen触发Cleaner的工作，

那么就可能让本来已经死了的、但已经晋升到old gen的DirectByteBuffer关联的native memory得不到及时释放。

3、为DirectByteBuffer分配空间过程中会显式调用System.gc()，以期通过full GC来强迫已经无用的DirectByteBuffer对象释放掉它们关联的native memory： 

这几个实现特征使得Oracle/Sun JDK 6依赖于System.gc()触发GC来保证DirectByteMemory的清理工作能及时完成。

如果打开了-XX:+DisableExplicitGC，清理工作就可能得不到及时完成，于是就有机会见到direct memory的OOM。

 

使用了Direct  ByteBuffer应该咋处理？

如果你在使用Oracle/Sun JDK 6，应用里有任何地方用了direct memory，那么使用-XX:+DisableExplicitGC要小心。

如果用了该参数而且遇到direct memory的OOM，可以尝试去掉该参数看是否能避开这种OOM。

如果担心System.gc()调用造成full GC频繁，可以尝试下面提到 -XX:+ExplicitGCInvokesConcurrent 参数 

（ -XX:+ExplicitGCInvokesConcurrent  System.gc()和应用程序并发执行，就是不stop-the-world）

-XX:+ExplicitGCInvokesConcurrent 或 -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses 

这两个参数也是用来改变System.gc()的默认行为用的；不同的是这两个参数只能配合CMS使用（-XX:+UseConcMarkSweepGC），

而且System.gc()还是会触发GC的，只不过不是触发一个完全stop-the-world的full GC，而是一次并发GC周期。 

CMS GC周期中也会做reference processing。

所以如果用这两个参数的其中一个，而不是用-XX:+DisableExplicitGC的话，就避开了由full GC带来的长GC pause，

同时NIO direct memory的OOM也不会那么容易发生。

 

MaxDirectMemorySize 与 NIO direct memory 的默认上限 

-XX:MaxDirectMemorySize 是用来配置NIO direct memory上限用的VM参数。

 MaxDirectMemorySize没显式配置的时候，NIO direct memory可申请的空间的上限就是-Xmx减去一个survivor space的预留大小。 

HeapDump位置问题

-XX:+HeapDumpBeforeFullGC、-XX:+HeapDumpAfterFullGC、-XX:+HeapDumpOnOutOfMemoryError 这几个参数可以在不同条件下做出HPROF格式的heap dump。

如果不想费神去摸索到底各种环境被配置成什么样、“working directory”到底在哪里的话，就在VM启动参数

 

DisableExplicitGC和Direct ByteBuffer
iamzhongyong的专栏
12-07 384
      如果在JVM 的配置中添加了DisableExplicitGC这个配置，但是同时应用中有用到了Direct ByteBuffer（例如用到了NIO框架mina），此时会由于内存问题导致OOM，之前有所了解，但是没有仔细看过，最近同事排查了一个这种问题，然后决定扫盲一下，期间重点参照撒迦（不得不佩服他在JVM上的权威​）的这篇Topic（http://hllvm.group.iteye...
一次堆外OOM问题排查
蜗牛的专栏
07-22 6662
线上服务有一台机器访问不通（一个管理平台),在公司的服务治理平台上查看服务的状况是正常的，说明进程还在。进程并没有完全crash掉。去线上查看机器日志，发现了大量
jvm参数
匣与桔
05-22 622
参数 默认值 使用介绍 DisableExplicitGC 默认关闭 忽略来自System.gc()方法触发的垃圾收集 ExplicitGCInvokes Concurrent 默认关闭 当收到来自System.gc()方法提交的垃圾收集申请时，使用CMS收集器进行收集 UseSerialGC Client模式的虚拟机默认开启，其他模式关闭 ...
System.gc()和-XX:+DisableExplicitGC启动参数，以及DirectByteBuffer的内存释放
weixin_30922589的博客
11-07 540
首先我们修改下JVM的启动参数，重新运行之前博客中的代码。JVM启动参数和测试代码如下： -verbose:gc -XX:+PrintGCDetails -XX:+DisableExplicitGC -XX:MaxDirectMemorySize=40Mimport java.nio.ByteBuffer; public class TestDirectByteBuffer{ // -verbo...
-XX:+DisableExplicitGC弊端
yygr的博客
12-27 1389
总结： 如果jvm参数中设置了-XX:+DisableExplicitGC，那么代码中手动调用System.gc()就不会生效。而有些框架中因为是使用的堆外内存，必须手动调用System.gc()来释放。如果禁用掉就会导致堆外内存使用一直增长，造成内存泄露。 详解： 直接内存与System.gc() System.gc()默认会触发一次Full GC,如果在代码中不小心调用了System.gc()会导致JVM间歇性的暂停,但有些NIO框架 比如Netty框架经常会使用DirectByteBuffer来分配堆
【Java核心-基础】DirectBuffer 和 MappedByteBuffer
一个被IT搞的
01-10 1722
. 简述 Java NIO 中提供了 DirectBuffer、MappedByteBuffer 以提高IO效率。 DirectBuffer DirectBuffer 占用的是 堆外内存。JVM 会在 DirectBuffer 上直接使用 “本地IO操作”（Native I/O Operations）。 Buffer 的地址对“本地IO操作”非常关键。所以在操作 堆...
Java直接内存(Direct Memory)深度解析
记录学习的过程
05-12 760
直接内存（Direct Memory）是Java中一种特殊的内存分配方式，由开发者直接向操作系统申请，位于JVM堆外，因此也称为堆外内存。与堆内存相比，直接内存具有绕过JVM堆、零拷贝、大内存支持、手动管理和高性能等特点。其底层通过java.nio包中的ByteBuffer类实现，核心类为DirectByteBuffer，通过JNI调用操作系统的内存分配函数。直接内存的零拷贝机制减少了数据在堆内外复制的开销，适用于大规模数据处理、高性能网络编程、内存数据库和游戏开发等场景。尽管直接内存性能优越，但需要手动管
Java网络编程(三) 堆外内存DirectByteBuffer
MALE_2的博客
12-12 495
DirectByteBuffer 堆外内存(DirectByteBuffer)，JVM有自己的内存模型，DirectByteBuffer是分配在非JVM内存中的内存。 下面我们带着三个问题去探讨: 1、堆外内存的作用是什么 2、堆外内存是如何分配与回收的，与JVM有什么关系 3、堆外内存使用原因以及会...
深入理解DirectBuffer
云袭的专栏
04-22 9020
介绍    最近在工作中使用到了DirectBuffer来进行临时数据的存放，由于使用的是堆外内存，省去了数据到内核的拷贝，因此效率比用ByteBuffer要高不少。之前看过许多介绍DirectBuffer的文章，在这里从源码的角度上来看一下DirectBuffer的原理。用户态和内核态    Intel的 X86架构下，为了实现外部应用程序与操作系统运行时的隔离，分为了Ring0-Ring3四种...
推荐在JVM参数模版中加上-XX:+DisableExplicitGC
硅脂味咖啡的博客
10-07 3524
-XX:+DisableExplicitGC：禁止显式执行GC，不允许通过代码来触发GC。 使用原因 避免开发工程师使用System.gc()来主动触发GC，如果调用System.gc()的方法并发度不高还好，要是并发度高，就会长时间一直调用System.gc()，STW的短暂停顿效果就被强化成了长时间停顿甚至对外展示效果就是服务不响应，所以为避免开发工程师好心办坏事，建议在JVM参数模版中加上【-XX:+DisableExplicitGC】参数。 ...
java nio 和 jvm 虚拟机参数的 XX:+DisableExplicitGC 的潜规则
gg的专栏
09-24 1万+
有段时间应用总是出现jvm所管理的内存没有发生溢出的情况，而是使用的直接内存区域发生溢出的行为。后来经过分析情况如下： 是由于应用中使用netty,netty 使用的nio 和 jvm 中的 XX:+DisableExplicitGC配置的冲突导致的， 具体经过：nio 使用直接内存区域  Direct Memory内存回收和其他内存回收有点区别。Java堆内放置的是direct memory
JVM学习-常用参数(七)
加油，努力，认真
05-02 1745
目录1. 内存监控1.1. -XX:+PrintGC1.2. -verbose:gc1.3. XX:+DisableExplicitGC1.4. -XX:MaxTenuringThreshold1.5. -XX:+PrintGCDetails1.6. -XX:+PrintGCTimeStamps1.7. -XX:+TraceClassLoading1.8. -XX:+PrintClassHistogram1.9. -XX:+PrintHeapAtGC1.10. -Xloggc1.11. -XX:+
JAVA虚拟机实战篇之GC调优[2](解决GC问题的手段)
缘友一世的博客
03-28 1274
【代码】JAVA虚拟机实战篇之GC调优[2](解决GC问题的手段)
JVM常用调优参数 ——JVM篇
热门推荐
YING—country的博客
03-18 2万+
JVM常用性能调优参数详解 ​ 在学习完整个JVM内容后，其实目标不仅是学习了解整个JVM的基础知识，而是为了进行JVM性能调优做准备，所以以下的内容就是来说说JVM性能调优的知识。 一、性能调优 ​ 性能调优包含多个层次，比如：架构调优、代码调优、JVM调优、数据库调优、操作系统调优等等。 ​ 架构调优和代码调优是JVM调优的基础，其中架构调优是对系统影响最大的。 性能调优基本上按照以下步骤进行： 明确优化目标 发现性能瓶颈 性能调优 通过监控及数据统计工具获得数据 确认是否达到目标 二、何时进
JVM相关 - 深入理解 System.gc()
BASK2312的博客
01-07 688
我们经常在面试中询问究竟会不会触发，网上也有很多人给出了答案，但是这些答案都有些过时了。本文基于最新的 Java 的下一个即将发布的 LTS 版本 Java 17（ea）的源代码，深入解析 System.gc() 背后的故事。
Java堆外内存之三：堆外内存回收方法
weixin_34198797的博客
11-22 3532
一、JVM内存的分配及垃圾回收 　　对于JVM的内存规则，应该是老生常谈的东西了，这里我就简单的说下： 　　新生代：一般来说新创建的对象都分配在这里。 　　年老代：经过几次垃圾回收，新生代的对象就会放在年老代里面。年老代中的对象保存的时间更久。 　　永久代：这里面存放的是class相关的信息，一般是不会进行垃圾回收的。 JVM垃圾回收 　　由于JVM会替我们执行垃圾回收，因此开发者根本...
高并发-JVM优化-设置JVM参数
吉他程序员的博客
03-04 1556
下面是我们生产环境的JVM启动参数： -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true -Dcache_enable=true -Xmx4g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepG...
JVM实战：调优案例分析
小识的博客
03-11 928
请求延迟导致内存溢出 堆外内存溢出 -XX:+DisableExplicitGC 导致System.gc()不生效
byteBuffer 如何重置 position 和 cap
最新发布
07-02
<think>我们正在讨论Java NIO中的ByteBuffer。用户的问题是如何重置ByteBuffer的position和设置capacity。首先，我们需要明确：ByteBuffer的capacity在创建后通常是固定的（除了通过slice()、duplicate()等方法创建视图，或者使用asReadOnlyBuffer()等，但这些方法不会改变底层数组的capacity）。如果要改变容量，通常需要创建一个新的ByteBuffer。但是，我们可以重置position（即设置position为0）以及调整limit等。另外，compact()方法可以压缩缓冲区，将position到limit之间的数据移动到缓冲区的开头，然后将position设置为剩余数据的末尾，limit设置为capacity。这样，我们就可以继续向缓冲区写入数据，而不会覆盖未读的数据。根据引用[3]：在HeapByteBuffer中的compact实现，它通过System.arraycopy将position到limit的数据复制到缓冲区的开头，然后设置position为剩余数据的数量（remaining()），设置limit为capacity。用户的问题包含两个部分：1.重置position：我们可以使用position(intnewPosition)方法设置position，或者使用rewind()方法将position设置为0（同时清除mark）。2.设置capacity：实际上，ByteBuffer的capacity在创建后不能改变。但是，我们可以通过创建一个新的ByteBuffer并复制数据来改变容量。因此，我们可以这样操作：重置position：-使用`buffer.position(0);`将position设置为0。-或者使用`buffer.rewind();`将position设置为0，同时limit不变（通常用于重新读取数据）。改变capacity：-如果我们需要更大的容量，可以创建一个新的ByteBuffer（可以是HeapByteBuffer或DirectByteBuffer），然后将原缓冲区中的数据复制到新缓冲区中。-复制数据时，我们可以使用`put`方法，但要注意先重置原缓冲区的位置（使用rewind()），然后读取原缓冲区的数据（从0到limit）写入新缓冲区。另外，引用[1]提到：mark()方法可以标记当前位置，然后通过reset()方法可以回到标记的位置。但是，重置position和设置capacity并不直接依赖于mark。步骤：1.重置position（不改变capacity）：-使用`buffer.rewind();`：将position设置为0，limit保持不变，mark被丢弃。这适用于重新读取缓冲区。-使用`buffer.clear();`：将position设置为0，limit设置为capacity，mark被丢弃。这适用于重新写入缓冲区。2.改变capacity（需要创建新缓冲区）：-创建一个新的ByteBuffer，指定新的容量。-将原缓冲区中的数据复制到新缓冲区。复制前，需要调整原缓冲区的position和limit（例如，使用`flip()`或`rewind()`）以便读取全部或部分数据。示例代码：重置position： ```javaByteBufferbuffer =...;buffer.rewind();//将position设置为0，limit不变//或者buffer.clear();//将position设置为0，limit设置为capacity```改变capacity（扩大或缩小）： ```java//假设我们需要将容量扩大到newCapacityintnewCapacity= ...; ByteBuffer newBuffer =ByteBuffer.allocate(newCapacity); //或者allocateDirect//将原缓冲区切换到读模式buffer.flip();//设置limit为当前position，position为0（这样读取的数据就是之前写入的数据） //或者如果原缓冲区已经处于读模式，我们可以使用rewind()，但要注意不要读取超过limit//将原缓冲区的数据复制到新缓冲区newBuffer.put(buffer);//现在newBuffer包含了原缓冲区的数据，并且position指向最后写入的位置，limit为capacity//如果我们需要读取新缓冲区的数据，需要调用flip()newBuffer.flip(); ```注意：如果原缓冲区是直接缓冲区，新缓冲区可以是直接缓冲区或堆缓冲区，反之亦然。另外，如果原缓冲区中的数据量大于新容量，那么复制时会抛出BufferOverflowException。因此，在复制前需要确保新容量足够。另外，引用[5]提到：getByte(intindex)方法可以从指定位置读取，而不改变position。但是，我们这里不涉及。总结：重置position：使用`rewind()`或`clear()`，或者使用`position(0)`。改变capacity：需要创建新的ByteBuffer并复制数据。因此，回答用户的问题：如何在JavaNIO中重置ByteBuffer的position和capacity？重置position：直接调用`rewind()`或`clear()`或`position(0)`。改变capacity：不能直接改变，需要创建新的ByteBuffer并复制数据。下面给出完整代码示例。</think>### Java NIO ByteBuffer 的 position 重置与 capacity 设置 在 Java NIO 中，`ByteBuffer` 的 **position** 和 **capacity** 是两个核心属性： - **position**：当前读写位置指针 - **capacity**：缓冲区的最大容量（创建后固定不变） #### 1. 重置 position 的三种方法 ```java ByteBuffer buffer = ByteBuffer.allocate(1024); // 方法1：rewind() - 重置position到0，limit保持不变 buffer.rewind(); // position=0, limit不变 // 方法2：clear() - 重置position到0，limit=capacity buffer.clear(); // position=0, limit=capacity // 方法3：position() - 精确设置position值 buffer.position(0); // 手动设置position=0 ``` #### 2. "改变 capacity" 的实际操作 由于 `capacity` 在创建后不可修改，要实现类似效果需创建新缓冲区并复制数据： ```java // 原始缓冲区 ByteBuffer original = ByteBuffer.allocate(256); original.put("Hello".getBytes()); original.flip(); // 准备读取 position=0, limit=5 // 创建更大容量的新缓冲区 int newCapacity = 512; ByteBuffer newBuffer = ByteBuffer.allocate(newCapacity); // 复制数据（使用绝对位置操作避免改变position） for (int i = 0; i < original.limit(); i++) { newBuffer.put(i, original.get(i)); // get(i)不改变position[^5] } // 设置新缓冲区的读写位置 newBuffer.position(original.position()); newBuffer.limit(original.limit()); ``` #### 3. 高效数据迁移方法 使用 `compact()` 压缩数据并重置位置（适合重用缓冲区）： ```java ByteBuffer buffer = ByteBuffer.allocate(100); buffer.put("Data".getBytes()); buffer.flip(); // 压缩缓冲区：将未读数据移到头部 buffer.compact(); // position=剩余空间起始位, limit=capacity[^3] // 继续写入新数据 buffer.put("Append".getBytes()); buffer.flip(); // 准备读取 ``` #### 4. 关键概念说明 | 方法 | 作用 | position变化 | limit变化 | |------------|-------------------------------|-------------|----------| | `rewind()` | 重置position到0 | 0 | 不变 | | `clear()` | 重置position到0，limit=capacity | 0 | capacity | | `flip()` | limit=position, position=0 | 0 | 原position | | `compact()`| 压缩未读数据到缓冲区头部 | 剩余数据长度 | capacity | #### 5. 最佳实践建议 1. **读取后重置**： ```java buffer.mark(); // 标记当前位置[^1] buffer.get(); // 读取1字节（position自增） buffer.reset(); // 回到标记位置 ``` 2. **批量复制**： ```java ByteBuffer[] buffers = new ByteBuffer[3]; // ...初始化buffers... channel.read(buffers); // 分散读取[^4] ``` 3. **直接缓冲区**（高性能场景）： ```java ByteBuffer directBuffer = ByteBuffer.allocateDirect(1024); ``` 4. **容量检查**： ```java if (buffer.remaining() < requiredSize) { // 创建新缓冲区并迁移数据 } ``` > **重要限制**：`capacity` 在 `ByteBuffer` 实例创建后不可修改，这是由底层数组的固定性决定的[^2]。需要"改变容量"时，必须创建新实例并复制数据。 ### 应用场景示例 **网络数据包重组**： ```java ByteBuffer packetBuffer = ByteBuffer.allocate(2048); // 接收数据片段 while (channel.read(packetBuffer) > 0) { packetBuffer.flip(); // 处理完整数据包 while (packetBuffer.remaining() >= PACKET_SIZE) { processPacket(packetBuffer); } // 压缩剩余数据 packetBuffer.compact(); // 未读数据移到头部 } ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值