深入理解JVM虚拟机（六）

目录：

（1）直接内存

（2）直接内存-基本使用

（3）直接内存-内存溢出

（4）直接内存-释放原理

（5）直接内存-禁用显示回收对直接内存的影响

---

（1）直接内存

直接内存并不属于java虚拟机的内存管理，而是属于系统内存，是操作系统的内存

NIO里有一个叫byteBuffer它所分配和使用的内存就是直接内存，不属于java虚拟机来管理，属于操作系统内存

 

使用了直接内存，大文件的读写效率较高 

 （2）直接内存-基本使用

文件的读写过程，java代码并不具备磁盘读写的能力，必须调用操作系统提供的函数，涉及到CPU的运行状态从用户态转到内核态，内存这边，由cpu的函数读取磁盘文件的内容，读入到系统缓冲区， 系统缓冲区java代码不能运行的，java这边会在堆这边分配一个java的缓冲区，必须通过 把系统缓冲区的读取到java缓冲区，才能进行java代码读取

有两个缓冲区，需要读取两次，效率不是很高

 

分一块直接内存，把磁盘文件读入到直接内存，java代码也可以访问直接内存，比上面少了一次缓冲区操作。

 

 

（3）直接内存-内存溢出

直接内存不受jvm内存管理，JAVA虚拟机做垃圾回收时不会去释放直接内存分配的内存

 

 （4）直接内存-释放原理

直接内存不受JVM的管理，直接内存所分配的内存会不会被正确回收，底层是怎么实现的呢？

分配完以后， 不能用java的检测工具去检测，因为java工具只能去检测有java工具只能看到java管理的堆内存，元空间呀，但是直接内存不受java程序管理，我们要看多出来的一个G需要看任务管理器看这个java进程堆内存的占用情况

 

前面说过直接内存不受垃圾回收管里， 上面的垃圾回收是否导致直接内存的释放吗？直接内存是由于其他的

 

 运行后：多出来占用内存

 回车释放内存：

直接内存的释放是由于unsafe的来管理的，垃圾回收只能释放java的内存，java回收对无用的对象，回收是自动的不需要我们调用任何的方法，而直接内存不同必须主动调用freeMemary方法完成内存的释放 

 

 

 

 

 cleaner：虚引用类型

 

Clender ：当ByteBuffer被垃圾回收回收掉时，就会触发Clender中的clean方法，就会执行任务对象的run方法，执行任务对象Deallocator他不是在主线程中执行的，

 

 所以直接内存的释放啊借助到了java中的虚引用的机制

（5）直接内存-禁用显示回收对直接内存的影响

 

通过设置虚拟机参数，+DisableExplicitGC：禁用显示的垃圾回收：

运行：发现这个内存最后没有回收，虽然调用了System.gc（），因为设置了虚拟机参数了

 没有触发java中的垃圾回收，byteBuffer对象虽然没有人引用它，，但是由于内存还充足，ByteBuffer还在存活着，它所对应的那块直接内存也没有被回收掉，当设置了这个参数，对直接内存有影响的，ByteBuffer只能等到真正的垃圾回收时才能被清理，从而对应的直接内存才能释放，这样就导致了对应的直接内存占用较大，尝尝得不到释放

System.gc（）是一种Full GC 是一种比较影响性能的垃圾回收，不仅要回收新生代，还要回收老年代

如果去去掉了这个虚拟机参数的设置，但是有情况可能有些别的代码，显示的调用System.gc，也会导致垃圾回收，垃圾回收对性能产生影响，可以用到，我们不用java的垃圾回收，可以使用unsafe对象直接调用freeMemory（）的方式，来释放直接内存，这是手动的管理直接内存