我们常见的ByteBuffer是通过java的代码申请的,而且是有引用的在堆里的。所以并算不上不完全不受gc的影响。他的申请这些操作底层控制的内存,确实是gc并不能回收,假如我们申请了ByteBuffer,但是没有释放,那岂不是内存泄露了,所以java的gc这时候发挥作用了,在堆中的对象没有引用了,gc的时候可以回收java的对象,但是这个对象相当于直接内存的代表,当代表可以被gc的时候,他也会调用java的代码去释放这块内存,最终达到释放的目的,避免影响。
下面是java释放的代码。
他申请不到会带来fullgc—System.gc
由此我们可以看出,这个空间的其实间接受到gc的影响,但也不是不受。
少一层拷贝
虽然很多人拿直接内存和0拷贝在一起讨论,这个也不是一回事,0拷贝算是系统的特性的部分了,直接内存顶多是少一层考虑,正常文件读取到堆,需要文件到系统内存,系统内存然后通过jni把数据拷贝到堆里。如果用直接内存去读取文件的数据,只要不是用来做处理,那么他是不需要拷贝到堆的,当然如果说,你要用来做处理,那么他本身也没什么优势了。
小结
直接内存和堆外内存不一样
直接内存本身不受gc的影响,但是由于有对象在堆引用这这块内存,那么受到gc的间接影响,典型的是java的代码里有system.gc去回收。
直接内存也和0拷贝不是一回事。
直接内存其实是jvm定义的空间,可以说堆,元数据区算在同一层次。