前言 对于堆外内存,使用 System.gc() 是不靠谱的,依赖老年代 FGC 也是不靠谱的,而且大部分调优指南都设置了 -DisableExplicitGC 禁用 System.gc().所以主动回收比较靠谱, JDK 在 DirectByteBuffer 中提供了 Cleaner 用来主动释放内存.同时还有 Unsafe 的 freeMemory 方法也可以. 下面看看他是怎么做的.这里以非池化创建直接内存为例. UnpooledByteBufAllocator newDirectBuff

上篇文章介绍了Netty内存模型原理,由于Netty在使用不当会导致堆外内存泄漏,网上关于这方面的资料比较少,所以写下这篇文章,专门介绍排查Netty堆外内存相关的知识点,诊断工具,以及排查思路提供参考 现象 堆外内存泄漏的现象主要是,进程占用的内存较高(Linux下可以用top命令查看),但Java堆内存占用并不高(jmap命令查看),常见的使用堆外内存除了Netty,还有基于java.nio下相关接口申请堆外内存,JNI调用等,下面侧重介绍Netty堆外内存泄漏问题排查 堆外内存释放底层实现

JVM调优 GC调优是最后要做的工作,GC调优的目的可以总结为下面两点: 减少对象晋升到老年代的数量 减少FullGC的执行时间 通过监控排查问题及验证优化结果,可以分为: 命令监控:jps.jinfo.jstack.jmap.jstat.jhat 图形化监控:JConsole和VisualVM 阿里巴巴开源的 Java 诊断工具:Arthas(阿尔萨斯): 如果GC执行时间满足下列所有条件,就没有必要进行GC优化了: Minor GC执行非常迅速(50ms以内) Minor GC没有频繁执行(

1. 写在前面 | 本文主要针对 Hotspot VM 中"CMS + ParNew"组合的一些使用场景进行总结.重点通过部分源码对根因进行分析以及对排查方法进行总结,排查过程会省略较多,另外本文专业术语较多,有一定的阅读门槛,如未介绍清楚,还请自行查阅相关材料. | 总字数 2 万左右(不包含代码片段),整体阅读时间约 30min ,文章较长,可以选择你感兴趣的场景进行研究. 1.1 引言 自 Sun 发布 Java 语言以来,开始使用 GC 技术来进行内存自动管理,避免了手动管理带

首先我们修改下JVM的启动参数,重新运行之前博客中的代码.JVM启动参数和测试代码如下: -verbose:gc -XX:+PrintGCDetails -XX:+DisableExplicitGC -XX:MaxDirectMemorySize=40Mimport java.nio.ByteBuffer; public class TestDirectByteBuffer{ // -verbose:gc -XX:+PrintGCDetails -XX:MaxDirectMemorySize=4

由于HeapByteBuffer和DirectByteBuffer类都是default类型的,所以你无法字节访问到,你只能通过ByteBuffer间接访问到它,因为JVM不想让你访问到它. 分配HeapByteBuffer的方法是: ByteBuffer.allocate(int capacity);参数大小为字节的数量 分配DirectByteBuffer的方法是: ByteBuffer.allocateDirect(int capacity);//可以看到分配内存是通过unsafe.allo

参考资料:http://www.maljob.com/pages/newsDetail.html?id=394 参考资料:http://www.blogjava.net/liuguly/archive/2014/05/03/413172.html 1.为什么要有引用计数器 Netty里四种主力的ByteBuf, 其中UnpooledHeapByteBuf 底下的byte[]能够依赖JVM GC自然回收:而UnpooledDirectByteBuf底下是DirectByteBuffer,如Java

介绍 最近在工作中使用到了DirectBuffer来进行临时数据的存放,由于使用的是堆外内存,省去了数据到内核的拷贝,因此效率比用ByteBuffer要高不少.之前看过许多介绍DirectBuffer的文章,在这里从源码的角度上来看一下DirectBuffer的原理. 用户态和内核态 Intel的 X86架构下,为了实现外部应用程序与操作系统运行时的隔离,分为了Ring0-Ring3四种级别的运行模式.Linux/Unix只使用了Ring0和Ring3两个级别.Ring0被称为用户态,Ring3

Netty本身在内存分配上支持堆内存和直接内存,我们一般选用直接内存,这也是默认的配置.所以要理解Netty内存的释放我们得先看下直接内存的释放. Java直接内存释放 我们先来看下直接内存是怎么使用的 ByteBuffer.allocateDirect(capacity) 申请的过程是其实就是创建一个DirectByteBuffer对象的过程,DirectByteBuffer对象只相当于一个holder,包含一个address,这个是直接内存的指针. 调用native方法申请内存 初始化cle

一.结论 DirectByteBuffer 与 ByteBuffer 最大区别就在于缓冲区内存管理的方式.ByteBuffer使用的是堆内存,DirectByteBuffer 使用的是堆外内存,堆外内存的优点就是在执行I/O操作时数据拷贝的次数相对较少,因此也获得了较高的性能.凡事总有但是,由于将缓冲区分配在堆外内存也引入一系列与内存分配和回收的问题,所幸JDK提供了一系列方案来解决问题,这些也是本文所要阐述的重点. 二.ByteBuffer 的缺点 I/O基本上可以视为一系列倒腾数据的操作.举

ByteBuf内存分配和释放由具体实现负责,抽象类型只定义的内存分配和释放的时机. 内存分配分两个阶段: 第一阶段,初始化时分配内存.第二阶段: 内存不够用时分配新的内存.ByteBuf抽象层没有定义第一阶段的行为,但定义了第二阶段的方法: public abstract ByteBuf capacity(int newCapacity) 这个方法负责分配一个长度为newCapacity的新内存. 内存释放的抽象实现在AbstractReferenceCountedByteBuf中实现,这个类实

在Java中当我们要对数据进行更底层的操作时,一般是操作数据的字节(byte)形式,这时经常会用到ByteBuffer这样一个类. ByteBuffer提供了两种静态实例方式: public static ByteBuffer allocate(int capacity) public static ByteBuffer allocateDirect(int capacity) 为什么要提供两种方式呢?这与Java的内存使用机制有关. 第一种分配方式产生的内存开销是在JVM中的,而另外一种的分配

概述 使用了nio框架的应用,比如服务框架,利用nio建立长连接通信,他们会使用DirectByteBuffer来分配堆外内存,也就是本地直接内存,这个内存的回收不由gc直接维护,我们通常所说的gc,只回收jvm的堆.方法区.本地内存如果没有用jvm启动参数手动指定,它会根据主机的剩余可用内存进行分配,如果说一个机器的8G内存的,其中,我们手动指定的jvm堆.方法区内存为2048 + 256,那么,除了其他进程占用的内存,剩余的可用内存可能是较大的.如果你的主机有内存使用量监控(不是jvm级的内

本文转载自JDK源码阅读-DirectByteBuffer 导语 在文章JDK源码阅读-ByteBuffer中,我们学习了ByteBuffer的设计.但是他是一个抽象类,真正的实现分为两类:HeapByteBuffer与DirectByteBuffer.HeapByteBuffer是堆内ByteBuffer,使用byte[]存储数据,是对数组的封装,比较简单.DirectByteBuffer是堆外ByteBuffer,直接使用堆外内存空间存储数据,是NIO高性能的核心设计之一.本文来分析一下Di

作者:Grey 原文地址:Java IO学习笔记二:DirectByteBuffer与HeapByteBuffer ByteBuffer.allocate()与ByteBuffer.allocateDirect()的基本使用 这两个API封装了一个统一的ByteBuffer返回值,在使用上是无差别的. import java.nio.ByteBuffer; public class TestByteBuffer { public static void main(String[] args) {

PhantomReference虚引用 在分析堆外内存回收之前,先了解下PhantomReference虚引用. PhantomReference需要与ReferenceQueue引用队列结合使用,在GC进行垃圾回收的时候,如果发现一个对象只有虚引用在引用它,则认为该对象需要被回收,会将引用该对象的虚引用加入到与其关联的ReferenceQueue队列中,开发者可以通过ReferenceQueue获取需要被回收的对象,然后做一些清理操作,从队列中获取过的元素会从队列中清除,之后GC就可以对该对象

上篇博客稍微介绍了一下AQS,下面我们来关注下AQS的所获取和锁释放. AQS锁获取 AQS包含如下几个方法: acquire(int arg):以独占模式获取对象,忽略中断. acquireInterruptibly(int arg): 以独占模式获取对象,如果被中断则中止. acquireShared(int arg): 以共享模式获取对象,忽略中断. acquireSharedInterruptibly(int arg)以共享模式获取对象,如果被中断则中止. tryAcquire(int

最近有个同事在调用一个类库中的方法时遇到了一个问题,异常信息如下: 尝试释放正在使用的RCW,活动线程或其他线程上正在使用该 RCW,释放正在使用的 RCW 的尝试会导致损坏或数据丢失. 该方法中对word文件进行相关了操作,因为我之前也在多线程环境下调用过该方法,并且没遇到这个问题,所以同事让我过去看看怎么回事.这个方法在对文件进行相关操作后,会调用另外一个方法释放word对象,部分代码如下: Word._Application t = oWord as Word._Application;

1.ActivityTwo.finish(); 在你的activity动作完成的时候,或者Activity需要关闭的时候,调用此方法.当你调用此方法的时候,系统只是将最上面的Activity移出了栈,并没有及时的调用onDestory()方法,其占用的资源也没有被及时释放.因为移出了栈,所以当你点击手机上面的“back”按键的时候,也不会再找到这个Activity; 2.activityTwo.onDestroy(); 系统销毁了这个Activity的实例在内存中占据的空间.在Activity的

清理yum缓存 清理yum缓存使用yum clean 命令,yum clean 的参数有headers, packages, metadata, dbcache, plugins, expire-cache, rpmdb, all yum clean headers #清理/var/cache/yum的headers yum clean packages #清理/var/cache/yum下的软件包 yum clean metadata ... Linux释放内存 释放网页缓存(To free