個(gè)人認(rèn)為rocket兩個(gè)核心技術(shù)一個(gè)是網(wǎng)絡(luò)io涕俗，一個(gè)是文件io材鹦〉看到MappedByteBuffer的時(shí)候?qū)?nèi)存映射的釋放邏輯產(chǎn)生了疑惑
基礎(chǔ)知識(shí)
- java中mmap過程如下，最終的mappedByteBuffer實(shí)際是一個(gè)DirectByteBuffer對象
File file = new File("xxx");
FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel();
MappedByteBuffer mappedByteBuffer = fileChannel.map(MapMode.READ_WRITE, 0, 4096);
- 看一下DirectByteBuffer構(gòu)建源碼缓待，可以看到每一個(gè)DirectByteBuffer都會(huì)包含一個(gè)Cleaner實(shí)例(視圖viewer沒有)
image.png
- Cleaner里面是利用的虛引用蚓耽，當(dāng)DirectByteBuffer對象被垃圾回收時(shí)，會(huì)調(diào)用構(gòu)造Cleaner時(shí)傳入的回調(diào)方法旋炒，對MappedByteBuffer來說就是執(zhí)行unmap步悠，具體邏輯在FileChannelImpl的內(nèi)部類Unmapper。對普通DirectByteBuffer來說就是Deallocator中的unsafe.freeMemory()
所以根據(jù)Cleaner的工作原理就能夠理解瘫镇，為什么網(wǎng)上那么多資料說直接內(nèi)存會(huì)隨著gc被回收鼎兽，有些人甚至在需要主動(dòng)回收直接內(nèi)存時(shí)直接調(diào)用System.gc()
- 當(dāng)我們想要主動(dòng)釋放內(nèi)存映射時(shí)，最簡單的辦法就是直接調(diào)用
((DirectBuffer) mappedByteBuffer).cleaner().clean()
進(jìn)階部分
- 后來了解到Cleaner類在java9前后的包是不一樣的铣除，所以如果代碼里持有Cleaner的對象谚咬，就不能在所有jdk中編譯了，當(dāng)然直接調(diào)用
((DirectBuffer) mappedByteBuffer).cleaner().clean()肯定沒有問題
java9前:sun.misc.Cleaner
java9后:java.lang.ref.Cleaner
- 聯(lián)想到netty是直接內(nèi)存使用大戶尚粘，看下netty中的做法序宦。netty中有兩個(gè)類CleanerJava6、CleanerJava9對應(yīng)不同的jdk版本分別使用
CleanerJava6根據(jù)jdk是否有Unsafe類決定通過Unsafe方法還是反射，調(diào)用DirectByteBuffer中Cleaner屬性的clean()方法
image.png
CleanerJava9直接通過反射調(diào)用Unsafe的invokeCleaner()方法(invokeCleaner在java9后才有)互捌，內(nèi)部也是調(diào)用的DirectByteBuffer中Cleaner屬性的clean()方法
image.png
rocket中的做法
- 在rocket中unmap的邏輯如下潘明，也是通過反射調(diào)用clean()方法，和我之前就關(guān)注的一個(gè)同學(xué)的博客做法完全一致秕噪，希望以后面基 :)
image.png
疑惑思考
- 為啥大家都非要用反射來調(diào)用clean呢钳降？
((DirectBuffer) mappedByteBuffer).cleaner().clean()簡單粗暴不香嗎？還有就是viewed()方法中的viewedBuffer是什么腌巾，沒看到有這個(gè)名字的方法八焯睢？
相當(dāng)于用hotspot編譯之后再openjdk上運(yùn)行澈蝙，就會(huì)報(bào)錯(cuò) https://stackoverflow.com/questions/54323645/apache-spark-method-not-found-sun-nio-ch-directbuffer-cleanerlsun-misc-cleaner
