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;
        }
    }

}

 

 

 

上一篇:effective解读-第八条 避免使用finalizer和Cleaner


下一篇:一款满足mac系统维护需求的一站式解决方案