堆外内存, JDK 1.4 nio引进了ByteBuffer.allocateDirect()分配堆外内存
ByteBuffer
public static ByteBuffer allocateDirect(int capacity) {
return new DirectByteBuffer(capacity);
}DirectByteBuffer
DirectByteBuffer(int cap) {// package-private
super(-1, 0, cap, cap);
boolean pa = VM.isDirectMemoryPageAligned();//内存是否按页分配对齐
int ps = Bits.pageSize();//获取每页内存大小
long size = Math.max(1L, (long)cap + (pa ? ps : 0));//分配内存的大小,如果是按页对齐方式,需要再加一页内存的容量
重点:分配内存和释放内存之前必须调用此方法
Bits.reserveMemory(size, cap);//用Bits类保存总分配内存(按页分配)的大小和实际内存的大小
long base = 0;
try {//在堆外内存的基地址,指定内存大小
base = unsafe.allocateMemory(size);//unsafe.cpp中调用os::malloc分配内存
} catch (OutOfMemoryError x) {
Bits.unreserveMemory(size, cap);
throw x;
}
unsafe.setMemory(base, size, (byte) 0);
if (pa && (base % ps != 0)) {//计算堆外内存的基地址
// Round up to page boundary
address = base + ps - (base & (ps - 1));
} else {
address = base;
}
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
att = null;
}Deallocator
private static class Deallocator implements Runnable
{
private static Unsafe unsafe = Unsafe.getUnsafe();
private long address;//基地址
private long size;//保存了堆外内存的数据(开始地址、大小和容量)
private int capacity;//保存了堆外内存的数据(开始地址、大小和容量)
private Deallocator(long address, long size, int capacity) {
assert (address != 0);
this.address = address;
this.size = size;
this.capacity = capacity;
}
public void run() {
if (address == 0) {
// Paranoia
return;
}
unsafe.freeMemory(address);//调用OS的方法释放地址,os::free
address = 0;
Bits.unreserveMemory(size, capacity);//统计堆外内存大小
}
}Cleaner
public class Cleaner extends PhantomReference<Object> {
private static final ReferenceQueue<Object> dummyQueue = new ReferenceQueue();//static数据
private static Cleaner first = null;//static数据
private Cleaner next = null;
private Cleaner prev = null;
private final Runnable thunk;//Deallocator对象,每个cleaner对象都保留了一个Deallocator对象,它里面有address基地址等
private static synchronized Cleaner add(Cleaner var0) {
if(first != null) {
var0.next = first;
first.prev = var0;
}
first = var0;
return var0;
}
private Cleaner(Object var1, Runnable var2) {
super(var1, dummyQueue);//var1 传的是DirectByteBuffer对象
this.thunk = var2;//Deallocator对象
}
public static Cleaner create(Object var0, Runnable var1) {
return var1 == null?null:add(new Cleaner(var0, var1));//var0传的是DirectByteBuffer对象
}Bits
// -- Direct memory management --
// A user-settable upper limit on the maximum amount of allocatable direct buffer memory.
// This value may be changed during VM initialization if it is launched with "-XX:MaxDirectMemorySize=<size>".
private static volatile long maxMemory = VM.maxDirectMemory();
private static volatile long reservedMemory;
private static volatile long totalCapacity;
private static volatile long count;
private static boolean memoryLimitSet = false;
// These methods should be called whenever direct memory is allocated or
// freed. They allow the user to control the amount of direct memory
// which a process may access. All sizes are specified in bytes.
static void reserveMemory(long size, int cap) {
synchronized (Bits.class) {
if (!memoryLimitSet && VM.isBooted()) {
maxMemory = VM.maxDirectMemory();// 67108864L == 64MB
memoryLimitSet = true;
}
// -XX:MaxDirectMemorySize limits the total capacity rather than the
// actual memory usage, which will differ when buffers are page aligned.
if (cap <= maxMemory - totalCapacity) {
reservedMemory += size;
totalCapacity += cap;
count++;
return;
}
}
System.gc();//内存不够了, try gc
try {
Thread.sleep(100);
} catch (InterruptedException x) {
// Restore interrupt status
Thread.currentThread().interrupt();
}
synchronized (Bits.class) {
if (totalCapacity + cap > maxMemory)
throw new OutOfMemoryError("Direct buffer memory");
reservedMemory += size;
totalCapacity += cap;
count++;
}
}
static synchronized void unreserveMemory(long size, int cap) {
if (reservedMemory > 0) {
reservedMemory -= size;
totalCapacity -= cap;
count--;
assert (reservedMemory > -1);
}
}-
DirectByteBuffer被回收
DirectByteBuffer对象在创建的时候关联了一个PhantomReference,说到PhantomReference它其实主要是用来跟踪对象何时被回收的,
它不能影响gc决策,但是gc过程中如果发现某个对象除了只有PhantomReference引用它之外,并没有其他的地方引用它了,
那将会把这个引用(Cleaner)放到java.lang.ref.Reference.pending队列里,
在gc完毕的时候通知ReferenceHandler这个守护线程去执行一些后置处理,
而DirectByteBuffer关联的PhantomReference是PhantomReference的一个子类,
在最终的处理里会通过Unsafe的free接口来释放DirectByteBuffer对应的堆外内存块 JDK里面的ReferenceHandler实现
private static class ReferenceHandler extends Thread {
ReferenceHandler(ThreadGroup g, String name) {
super(g, name);
}
public void run() {
for (;;) {
Reference r;
synchronized (lock) {
if (pending != null) {
r = pending;
Reference rn = r.next;
pending = (rn == r) ? null : rn;
r.next = r;
} else {
try {
lock.wait();
} catch (InterruptedException x) { }
continue;
}
}
// Fast path for cleaners
if (r instanceof Cleaner) {
((Cleaner)r).clean();//直接调用clean方法清理
continue;
}
ReferenceQueue q = r.queue;
if (q != ReferenceQueue.NULL) q.enqueue(r);
}
}
}-
简单流程梳理
- 堆外内存的申请
- ByteBuffer.allocateDirect()
- unsafe.allocateMemory()
- os::malloc()
- 堆外内存的释放
- cleaner.clean()
- 把自身从Clener链表删除,从而在下次GC时能够被回收
- 释放堆外内存
- unsafe.freeMemory()
- os::free()
- cleaner.clean()
- 堆外内存的申请
-
对象的引用关系
不过很多线上环境的JVM参数有-XX:+DisableExplicitGC,导致了System.gc()等于一个空函数,根本不会触发FGC,这一点在使用Netty框架时需要注意是否会出问题
-
关于直接内存默认值是否为64MB?
- java.lang.System
private static void initializeSystemClass() {//Initialize the system class. Called after thread initialization.
...
sun.misc.VM.saveAndRemoveProperties(props);
...
} - saveAndRemoveProperties(){
// Set the maximum amount of direct memory. This value is controlled
// by the vm option -XX:MaxDirectMemorySize=<size>.
// The maximum amount of allocatable direct buffer memory (in bytes)
// from the system property sun.nio.MaxDirectMemorySize set by the VM.
// The system property will be removed.
String s = (String)props.remove("sun.nio.MaxDirectMemorySize");
if (s != null) {
if (s.equals("-1")) {
// -XX:MaxDirectMemorySize not given, take default
directMemory = Runtime.getRuntime().maxMemory();
} else {
long l = Long.parseLong(s);
if (l > -1)
directMemory = l;
}
}} - 如果我们通过-Dsun.nio.MaxDirectMemorySize指定了这个属性,只要它不等于-1,那效果和加了-XX:MaxDirectMemorySize一样的,如果两个参数都没指定,那么最大堆外内存的值来自于directMemory = Runtime.getRuntime().maxMemory(),这是一个native方法
- Universe::heap()->max_capacity();
- 其中在我们使用CMS GC的情况下的实现如下,其实是新生代的最大值-一个survivor的大小+老生代的最大值,也就是我们设置的-Xmx的值里除去一个survivor的大小就是默认的堆外内存的大小了
- java.lang.System
如果发现某个对象除了只有PhantomReference引用它之外,并没有其他的地方引用它了,那将会把这个引用放到java.lang.ref.Reference.pending队列里,在gc完毕的时候通知ReferenceHandler这个守护线程去执行一些后置处理
可见如果pending为空的时候,会通过lock.wait()一直等在那里,其中唤醒的动作是在jvm里做的,当gc完成之后会调用如下的方法VM_GC_Operation::doit_epilogue(),在方法末尾会调用lock的notify操作,至于pending队列什么时候将引用放进去的,其实是在gc的引用处理逻辑中放进去的,针对引用的处理后面可以专门写篇文章来介绍
对于System.gc的实现,它会对新生代和老生代都会进行内存回收,这样会比较彻底地回收DirectByteBuffer对象以及他们关联的堆外内存,我们dump内存发现DirectByteBuffer对象本身其实是很小的,但是它后面可能关联了一个非常大的堆外内存,因此我们通常称之为『冰山对象』,我们做ygc的时候会将新生代里的不可达的DirectByteBuffer对象及其堆外内存回收了,但是无法对old里的DirectByteBuffer对象及其堆外内存进行回收,这也是我们通常碰到的最大的问题,如果有大量的DirectByteBuffer对象移到了old,但是又一直没有做cms gc或者full gc,而只进行ygc,那么我们的物理内存可能被慢慢耗光,但是我们还不知道发生了什么,因为heap明明剩余的内存还很多(前提是我们禁用了System.gc)。
我们通信过程中如果数据是在Heap里的,最终也还是会copy一份到堆外,然后再进行发送,所以为什么不直接使用堆外内存呢
gc机制与堆外内存的关系也说了,如果一直触发不了cms gc或者full gc,那么后果可能很严重
-
References