Java堆外内存
作者：互联网
1.为啥需要堆外内存？
1.在Java中NIO数据传输的时候使用了堆外内存，为啥要使用呢？堆内内存咋了嘛？一个很大的原因，可能是堆内内存不够会产生GC，导致一定程度的传输速率下降，因此出现其他性能问题。
2.但是有个疑问，那数据传输使用堆外内存，不是堆内内存-->堆外内存--> 内核socket缓冲区(网卡省略)，那堆内拷贝到堆外不是也有可能发生GC吗？这里涉及到safe point, GC只会发生在代码进入到safe point的时候，而堆内拷贝到堆外不可能进入到safe point，而直接堆内--> 内核socket缓冲区(网卡省略)涉及内核和用户态的切换，是一个safe point。
3.因此需要堆外内存。还有一点可能令人困惑的是，我们的NIO不是可以利用send file零拷贝机制吗(先不谈Linux更高版本socket的gather机制优化)？数据不会出现在虚拟空间中的堆内内存中呀？零拷贝是指直接从磁盘DMA读到内核缓冲区，内核缓冲区copy到内核socket(优化后甚至省去)，发送网卡。其中数据不会流向堆中。==> 所以一般情况下，不涉及数据操作的，就使用零拷贝完事，如果涉及数据操作，没办法就要用堆外内存。
4.总结：当NIO数据传输的时候，在需要进行数据的操作，然后再传输的情况下，由于GC的限制，堆内内存需要将数据拷贝到堆外内存再进行传输。
2.Java堆外内存的控制类？
//看这毫无掩饰的构造函数
//unsafe分配内存空间
//cleaner为后续清理堆外内存准备，那么可以看看Deallocator的清理工作是咋样的。
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);
long base = 0;
try {
base = unsafe.allocateMemory(size);
} 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;
}//Cleaner代码不贴了，反正就是Cleaner.clean()调用了这个线程run方法。。
//问题变成什么时候，调用Cleaner.clean方法了。
//我们手动调当然可以，但是jvm也会自动帮你处理。可以往下看
private static class Deallocator
implements Runnable
{
public void run() {
if (address == 0) {
// Paranoia
return;
}
//清理分配的堆外内存空间
unsafe.freeMemory(address);
address = 0;
Bits.unreserveMemory(size, capacity);
}
}//啥时候调用Cleaner.clean呢？从前面DirectByteBuffer知道，var1就是指这类型的一个对象。
//当这个对象由于线程结束，栈帧结束，那么就不会指向这个对象，那么对象在gc的时候就会呗回收。
//这对象回收后呢，由于我们的Cleaner虚引用对象指向这个对象，一个只被jvm操作的线程，就会让这个虚引用对象进入到引用队列中。
//Reference$ReferenceHandler类中可以看到，会轮询处理这个引用对象。看下面代码
public class Cleaner extends PhantomReference<Object> {
private Cleaner(Object var1, Runnable var2) {
super(var1, dummyQueue);
this.thunk = var2;
}
}
public abstract class Reference<T> {
//这个内部类继承线程呀，某个static方法中，就会开启这个线程，run方法会死循环执行 tryHandlePending方法.
//不管其他，看c.clean()就可以知道，会自动帮你释放堆外内存了
private static class ReferenceHandler extends Thread {
static boolean tryHandlePending(boolean waitForNotify) {
Reference<Object> r;
Cleaner c;
try {
synchronized (lock) {
if (pending != null) {
r = pending;
// 'instanceof' might throw OutOfMemoryError sometimes
// so do this before un-linking 'r' from the 'pending' chain...
c = r instanceof Cleaner ? (Cleaner) r : null;
// unlink 'r' from 'pending' chain
pending = r.discovered;
r.discovered = null;
} else {
// The waiting on the lock may cause an OutOfMemoryError
// because it may try to allocate exception objects.
if (waitForNotify) {
lock.wait();
}
// retry if waited
return waitForNotify;
}
}
} catch (OutOfMemoryError x) {
// Give other threads CPU time so they hopefully drop some live references
// and GC reclaims some space.
// Also prevent CPU intensive spinning in case 'r instanceof Cleaner' above
// persistently throws OOME for some time...
Thread.yield();
// retry
return true;
} catch (InterruptedException x) {
// retry
return true;
}
// Fast path for cleaners
if (c != null) {
c.clean();
return true;
}
ReferenceQueue<? super Object> q = r.queue;
if (q != ReferenceQueue.NULL) q.enqueue(r);
return true;
}
}
}
标签：Cleaner,Java,堆外,cap,base,内存,size 来源： https://blog.csdn.net/qq_23669881/article/details/113794411