最近突然得知自己的基礎(chǔ)差霞怀，與精英的標(biāo)準(zhǔn)相距甚遠(yuǎn)褥实。的確呀狼，平時(shí)的工作中，有太多機(jī)會允許我運(yùn)用“基礎(chǔ)”以外的東西去完成损离。讓我對“基礎(chǔ)”沒有很重視哥艇，所以決定了馬上亡羊補(bǔ)牢。就先從自己最看重的異步編程開刀吧僻澎，翻閱起了《Netty權(quán)威指南》貌踏。大部分內(nèi)容與看之前的道聽途說、自行猜想沒差多少窟勃。突如其來的如下代碼祖乳，讓我產(chǎn)生了警覺：

1.png

代碼中，由于手動(dòng)打開了本地文件秉氧，所以在flush操作后眷昆，手動(dòng)關(guān)閉了文件。但netty作為一個(gè)異步框架汁咏，總覺得不太可能需要寫出這種同步樣式的代碼亚斋。
我的疑問有兩點(diǎn)：1、flush方法返回時(shí)攘滩，可以確保數(shù)據(jù)write完畢帅刊？2、netty沒有提供用于編寫收尾邏輯的回調(diào)接口漂问？
弄清疑問一：
嘗試在互聯(lián)網(wǎng)上搜索赖瞒，發(fā)現(xiàn)并沒有關(guān)于這點(diǎn)的描述，所以干脆自己下載了源碼自己看蚤假。
ChannelHandlerContext接口栏饮，對flush的描述：

2.png

AbstractChannelHandlerContext抽象類中的具體實(shí)現(xiàn)：

3.png

意思應(yīng)該是將pipeline中的ChannelOutboundHandler依次調(diào)一遍，參照findContextOutbound的實(shí)現(xiàn)：

4.png

可以得知磷仰，ChannelOutboundHandler是從后向前依次調(diào)用的袍嬉。最后一個(gè)調(diào)用的為默認(rèn)的HeadContext：

5.png

HeadContext的flush，調(diào)用的是DefaultChannelPipeline.channel().unsafe().flush():

6.png

7.png

以書中的示例代碼使用的NioServerSocketChannel為例芒划，當(dāng)接收到客戶端請求時(shí)冬竟，創(chuàng)建了NioSocketChannel：

8.png

8+.png

NioSocketChannel中unsafe().flush()的調(diào)用鏈為：
unsafe()[繼承自：AbstractNioByteChannel欧穴、AbstractNioChannel] >>> AbstractChannel.unsafe()
AbstractChannel.unsafe()返回的結(jié)果來自：
NioSocketChannel.newUnsafe()

9.png

NioSocketChannelUnsafe的flush方法[繼承自：NioByteUnsafe、AbstractNioUnsafe泵殴、AbstractUnsafe]：

10.png

調(diào)用的flush0方法：
flush0()[繼承自：NioByteUnsafe涮帘、AbstractNioUnsafe] >>> AbstractUnsafe.flush0()

11.png

調(diào)用的NioSocketChannel.doWrite方法:

12.png

針對示例中的FileRegion，調(diào)用了父類doWrite方法：

13.png

14.png

其中確實(shí)存在針對write未完畢的處理笑诅，調(diào)用用incompleteWrite(true) >>> setOpWrite():

15.png

將SelectionKey.OP_WRITE注冊到selector中调缨，并在寫操作完成后，由selector再觸發(fā)一次flush（NioEventLoop代碼）:

16.png

總上吆你，flush方法返回時(shí)弦叶，不保證數(shù)據(jù)write完畢。
弄清疑問二：
DefaultFileRegion的API說明:
Default FileRegion implementation which transfer data from a FileChannel or File. Be aware that the FileChannel will be automatically closed once AbstractReferenceCounted.refCnt() returns 0.
DefaultFileRegion類實(shí)現(xiàn)了FileRegion接口妇多，繼承了AbstractReferenceCounted類伤哺。創(chuàng)建DefaultFileRegion實(shí)例時(shí)可以傳入一個(gè)FileChannel實(shí)現(xiàn)或一個(gè)File實(shí)例，而且在這里使用FileChannel不需要手動(dòng)close者祖。
上文的AbstractNioByteChannel.doWrite方法中立莉，完畢時(shí)調(diào)用了ChannelOutboundBuffer.remove()：

17.png

這正是用來釋放ReferenceCounted對象的邏輯。
DefaultFileRegion中也存在關(guān)閉FileChannel的邏輯：

18.png

但RandomAccessFile方法中七问，不只有關(guān)閉FileChannel的邏輯：

19.png

因此RandomAccessFile.close()方法還是需要手動(dòng)調(diào)用的蜓耻。
總終方案：
編寫DefaultFileRegion子類，重寫deallocate方法械巡，額外關(guān)閉RandomAccessFile對象刹淌。（代碼略）

探究感想：
為了論證自己的猜測，確實(shí)花費(fèi)了不少精力讥耗。最大的困難在于本次的論點(diǎn)有勾，沒有被廣大程序員關(guān)注，而且錯(cuò)誤的代碼遍布各種書籍葛账、網(wǎng)站柠衅，讓人直覺上認(rèn)為那些就是對的皮仁。這正讓我聯(lián)想到之前美團(tuán)的招聘細(xì)則中不要“信中醫(yī)的”籍琳。中醫(yī)這里代表的是廣泛留傳下來的傳統(tǒng)中醫(yī)理論知識，不單只運(yùn)用了現(xiàn)代科學(xué)醫(yī)藥手段驗(yàn)證過的中醫(yī)贷祈。中醫(yī)與軟件理論趋急，都十分龐大、且充滿糟粕势誊。對待中醫(yī)和軟件知識呜达，都應(yīng)該持有一種警覺態(tài)度，那些被記載粟耻、流傳下來的手段查近、方案眉踱，真的是正確的嗎？適用在你的場景中依然有效霜威？的確谈喳，實(shí)際運(yùn)用中會有眾多因素，制約著你無法透徹的去驗(yàn)證戈泼。但你的知識獲取方法婿禽，只能是聽信他人嗎。1753年英國海軍軍醫(yī)倫達(dá)大猛，經(jīng)試驗(yàn)得出結(jié)論：檸檬汁可用來治療和預(yù)防壞血病扭倾。這種的結(jié)論，對于航海而言就足夠了挽绩，不需要知道其根本是維生素C的作用膛壹。中醫(yī)知識通過大量隨機(jī)雙盲對照試驗(yàn)來驗(yàn)證。軟件知識唉堪，歸根到底就是代碼恢筝，真有什么不明白的，看一看巨坊、運(yùn)行一下撬槽。你能了解到什么程度，首先由你想了解到什么程度決定趾撵。